Auteur : Nicolas Tallet

Statut : corrigé

[DHTML vaut pour Dynamic HyperText Markup Language.] [NL]

J’hésite à qualifier le DHTML de norme. En tout cas, ce n’en est pas une selon le W3C, mais bien une pratique mise en place à partir de trois normes distinctes : (X)HTML, CSS et DOM, par l’intermédiaire de JavaScript ou ECMAScript.

Dans la mesure où ce JavaScript est codé selon le DOM W3C, DHTML peut effectivement se révéler fonctionnel et utilisable sur toutes les plateformes, mais puisque 99 % du DHTML qu’on retrouve sur le Web est codé pour répondre aux exigences syntaxiques propriétaires des navigateurs les plus populaires (notamment document.all de MSIE et document.layers de Netscape), on fait souvent face à un DHTML très lourd du type « usine à gaz », qui exclut d’office tous les autres navigateurs.

Toutefois, même lorsqu’il est conforme au DOM W3 (donc plus léger et portable sur tous les agents utilisateurs récents), DHTML posera toujours un grave problème d’accessibilité pour ceux qui ne supportent pas JavaScript pour une raison ou une autre (environ 8 % des internautes en 2005).

Parmi ceux-ci, notons les gens qui le désactivent volontairement, ceux qui utilisent un navigateur texte ou encore les personnes handicapées qui utilisent une technologie alternative en « sur couche » de leur navigateur et qui, dès lors, sont incapables de supporter correctement le DOM, peu importe sa saveur.

Certaines études ont d’ailleurs tendance à mettre en doute la pertinence de DHTML pour concevoir des menus déroulants et offrent plusieurs niveaux de navigation simultanée. Du simple point de vue de l’utilisabilité et de l’ergonomie, il apparaît que l’utilisateur moyen est souvent perdu dans ce dédale « navigationnel ». Surprenant et difficile à croire pour des gens comme nous, qui sommes habitués à ce genre de techniques de tous les jours, n’est-ce pas? 🙂

Est-ce à dire que DHTML devrait être mis de côté? Ça dépend probablement des goûts, mais en ce qui me concerne, je l’utilise le moins souvent possible maintenant (j’en ai beaucoup abusé par le passé). J’ai réalisé avec le temps qu’une bonne analyse et une bonne architecture de navigation permettent toujours d’éviter le recours au DHTML.

Lorsque je l’utiliserai à l’avenir, ce sera de manière intrinsèquement reliée au backend pour que le dynamisme soit assuré par un langage de programmation côté serveur, pas côté client (je peux vivre avec les rafraîchissements d’écrans, mais pas avec les utilisateurs qui ne peuvent naviguer dans mes sites).

J’ignore toutefois si on peut parler de DHTML. Si on en traite, le dynamisme en backend par contre…

Quant à faire tomber de la neige dans l’écran, faire brasser la fenêtre du navigateur ou autres inutilités du genre, je préfère me passer de commentaires. 😉 Évidemment, ces opinions n’engagent que moi.

Source : Denis Boudreau [ CYBERcodeur.net ]
Contributeur W3Québec et OpenWeb lien(s) utile(s) : http://www.commentcamarche.net/dhtml/dhtmlintro.php3 (http://www.commentcamarche.net/dhtml/dhtmlintro.php3)
http://membres.lycos.fr/web2k/DhtmlAni.htm (http://membres.lycos.fr/web2k/DhtmlAni.htm)