<C²: webløg />

Courriel - email address

Avatar Denis

dimanche 23 novembre 2003
par Denis Boudreau

Ma position actuelle sur DHTML

C'est avec plaisir que je réalise qu'il y a de plus en plus d'inscrits sur la liste de diffusion de W3Québec. C'est donc dire que notre collectif suscite de plus en plus d'intérêt ! Ainsi donc, quelqu'un réagissait aujourd'hui à un truc que j'écrivais plus tôt à propos de DHMTL, et qui allait comme suit :

DHTML commence à sérieusement perdre de son intérêt, pour des considérations statistiques, ergonomiques et fonctionnelles.

Ainsi, au passage, cette personne en profitait pour poser la question suivante, à laquelle je me suis empressé de répondre, avec beaucoup trop de mots bien entendu ;\

La question de johpa

Donc, qu'en est-il de ce standard offrant à la fois du gadget, mais aussi des fonctions utiles ?

Ma réponse à sa question

J'hésite à qualifier 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 ou ce JavaScript est codé selon le DOM W3C, DHTML peut effectivement s'avérer fonctionnel et utilisable sur toutes les plateformes, mais comme 99% du DHTML que l'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 est souvent en face d'un DHTML très lourd du type 'usine à gaz', qui exclut d'office tous les navigateurs alternatifs.

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 (13% des internautes) pour une raison ou une autre.

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 surcouche 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 les menus qui explosent et offrent plusieurs niveaux de navigation simultanés. D'un simple point de vue d'utilisabilité et d'ergonomie, il appert 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 à 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 navigationnelle arrivent toujours à permettre d'éviter DHTML.

Lorsque je l'utiliserai à l'avenir, ce sera d'une manière intrinsèquement reliée au backend de sorte 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...

Et pour ce qui est de faire tomber de la neige dans l'écran, de faire brasser la fenêtre du navigateur ou tout autre inutilités du genre, je préfère me passer de commentaires.

Évidemment, ces opinions n'engagent que moi.

Et vous, qu'est-ce que vous en pensez ? DHTML est-il aussi mort à vos yeux qu'il l'est aux miens ?

Denis Boudreau | 2003.11.23 @ 18:13

Alors, qu'en pensez-vous ?

Voici ce que vous aviez à en dire... vos impressions, recueillies à vif.

2003.11.24 @ 00:14 par Bleizig

Absolument pas ...

Je suis tout a fait d'accord avec toi qu'un site ne doit pas entierement reposer sur Javascript afin de ne pas refuser l'entree aux 13% d'utilisateurs qui ne le supportent pas, mais il peut se rendre tres utile et ameliorer l'experience de l'utilisateur pourvu que le codeur sache l'utiliser a bon escient.
L'utilisation la plus repandue est bien sur la verification de formulaires. Javascript permet quasi instantanement de valider une addresse de courriel, une date ou n'importe quel autre champ. Cela permet d'eviter un aller retour client-serveur inutile qui peut prendre beaucoup de precieuses secondes et qui gaspille inutilement la bande passante. Il faut bien sur ne pas reposer entierement sur cette verification client et faire en sorte que le serveur procede aux memes verifications pour ceux qui passeront au travers car ils ont Javascript desactive.
Il est aussi possible d'utiliser ce language pour donner a l'utilisateur des indices supplementaires sur l'utilisation du site: je pense notemment au champ de recherche situe en haut a droite de cette page qui contient la legende 'Mots cles' qui disparait des que l'utilisateur decide d'entrer des elements de recherche. Je suis aussi tombe sur plusieurs sites qui utilisaient un systeme de bulles pour guider l'utilisateur champ apres champ.
Il existe aussi plusieurs sites qui utilisent des menus et changeurs de style Javascript avec toujours une alternative serveur.

Enfin, je pense qu'il ne faut pas oublier que les sites publics ne representent pas la totalite de l'utilisation des technologies de l'internet, il existe aussi de nombreux sites intranets, extranets et autres applications basees sur le web. Dans ces cadre la, il est beaucoup plus aise d'exiger de l'utilisateur une configuration precise. J'ai eu le plaisir de travailler sur plusieurs grosses applications et elles faisaient toutes un usage tres intense de Javascript afin notemment de reduire les temps d'attentes des utilisateurs au maximum.

Ainsi je pense que Javascript est tres loin d'etre mort.

Haut retour au début de la page

2003.11.24 @ 00:56 par Fabrice Bonny

Non, JS n'est pas mort! :-)

Le tout est de l'utiliser intelligement, c'est-à-dire qu'il apporte une plus-value sans être indispensable. Un exemple: sur un site, j'ai une carte dont les points mènent à un élément d'un liste détaillant le point, donc avec des allers-retours dans la page (plutôt longue) entre la liste et la carte. Avec DOM + Ecmascript, j'ai fait en sorte que la liste disparaisse et que le survol d'un point fasse apparaître la description en 'bulle'.

Par contre, le fait de faire disparaître les éléments de la liste en JS les fait disparaître à l'impression. J'ai donc dû injecter des règles dans la CSS dédiée à l'écran via insertRule (et addRule pour MSIE). Cela fonctionne donc partout, NC4 et les navigateurs texte ayant la version carte + liste.

Bref, du grand art utile et accessible. :-)

Haut retour au début de la page

2003.11.24 @ 02:02 par s t e f

Je suis en train de préparer un site pour des copains qui s'appuie lourdement sur du dhtml: une liste d'images qui scrolle horizontalement.

J'interviens sur le site alors que le design est déjà finalisé depuis un an, et le design prévoyait déjà ce côté ludique.

On peut imaginer --et c'est d'ailleurs de cette manière que je vais l'implémenter-- une zone où toutes les imags sont posées en vrac pour les navigateurs non-DOM et ceux qui n'ont pas activé le JS, et seulement du DHTML pour les DOM qui ont le JS.

Ça n'est pas éliminatoire, le DHTML. Il faut juste, à mon humble avis, prendre bien le temps de le rendre furtif, et surtout prendre bien en compte les cas où pour une raison ou pour une autre il ne s'exécutera pas.

Haut retour au début de la page

2003.11.24 @ 02:05 par s t e f

J'oubliais : sur les 13% de 'visiteurs' qu'on compte dans les logs des sites comme n'ayant pas le JS, il faut aussi penser qu'une bonne proportion de ces visites revient aux robots, spiders et crawlers.

Je n'ignore pas que certaines entreprises désactivent le JS par sécurité sur les navigateurs de leurs employés, ni que certains paranos dans mon genre désactivent le JS avant d'aller sur certains sites pour éviter les mauvaises surprises.

Mais il convient de penser qu'en réalité la proportion réelle de gens qui n'ont pas le JS activé est moins grosse que ce que nous ressassons tous.

(en particulier le grand public ne sait même pas ce que navigateur veut dire, alors 'désactiver le JS', n'en parlons pas...)

Haut retour au début de la page

2003.11.24 @ 02:30 par YoGi

Je pense qu'il ne faut pas confondre DHTML et Javascript. En outre, vous avancez tous la vérification des formulaires, mais celle-ci ne fait intervenir, en général, que JS et DOM. Et n'intervient en aucun cas dans le visuel proprement dit de la page.

Pour moi, le DHTML c'est clairement plus quelque chose du type HierMenus (http://www.webreference.c...) qui peut etre, moyennement un poil de script client, avantageusement remplacé par un menu XHTML+CSS.

Toujours pour moi, autant le DHTML est sur le point de disparaitre (tout du moins je l'espère), autant le javascript à de l'avenir (ou quelconque alternative de scripting client).

Et non, le dynamisme coté serveur ça n'est aucunement du DHTML, puisque ne requiert pas de langage de script coté client..

Haut retour au début de la page

2003.11.24 @ 06:56 par Goldoraf

Pour ma part, autant j'aime utiliser Javascript pour une meilleure utilisation des formulaires, autant j'ai toujours considéré le DHTML comme un gadget inutile.. Un simple exemple : récemment j'ai assuré la refonte d'un intranet dans lequel le développeur avait jugé bon de placer des menus déroulants (bien sûr avec les fonctions de Dreamweaver... no comment). Le simple fait de virer ce truc là en le remplaçant par de simples listes de liens (et au passage en refaisant les pages de manière conforme à nos chers standards) a divisé le poids des pages par 10 ! (et je peux vous dire que les admins ont bien senti la différence au niveau du trafic sur le réseau) Aucun utilisateur ne s'est plaint, au contraire. Enfin, je considère que le HTML pur, avec ou sans Javascript, n'est pas fait pour faire des menus déroulants ou des fenêtres déplaçables, il n'a jamais été conçu pour ça. Pour cela il y a SVG ou bien... Flash ! (aîe non pas la tête :)

Haut retour au début de la page

2003.11.24 @ 08:22 par Olivier

Je pense que les tentatives d'enrichir les contrôles (menus, tabs, etc.) dans les pages web ont échouées - c'est lent à exécuter, long à coder, et il n'y a aucune cohérence d'un site à un autre - et que les browsers vont être moins dominants à cause de ça. On va voir arriver de plus en plus d'applications alternatives accédant au web, un peu comme les aggrégateurs RSS. Ou peut-être le W3C ou quelqu'un d'autre travaille-t-il en secret sur l'amélioration des contrôles en HTML ? Il serait intéressant de comparer la popularité des aggrégateurs 'browser', et ceux Mac, Linux ou Windows. Je trouve ces derniers beaucoup plus sympathiques à utiliser.

Haut retour au début de la page

2003.11.24 @ 08:24 par Olivier

s/échouées/échoué/

Haut retour au début de la page

2003.11.24 @ 15:16 par Faden

Dans les 13% qui n'ont pas Javascript activé, il s'agit en fait d'environ 10% de robot. Donc cet argument est erroné.

Il y aurait 3-4% pourcent d'utilisateurs au grand maximum qui n'ont pas Javascript activé.

Ensuite pour ce qui est du DHTML, il n'est pas difficile de faire un script qui passe sur tout les navigateurs modernes ...

Encore une fois ça n'empêche pas de faire n'importe quoi avec du Javascript ... Mais c'est comme l'xHTML et le CSS pas vrai ?

Voilà, selon moi le Javascript est à éviter dès qu'il se charge d'un point critique du site. Par exemple pour un menu de navigation dont on ne peut pas garantir le fonctionnement, tout comme ce que j'avais tenté de faire ici :

http://www.magnin-sante.c...

Bon là ce qui marche pas bien c'est plus le CSS, mais ça c'est une autre histoire.

Haut retour au début de la page

2003.11.24 @ 19:25 par CYBERcodeur

Notez, mes très cher amis, que j'avançais une idée à savoir si DHTML était à l'article de la mort, pas JavaScript. Faut suivre quand même ! ;)

Personne ne pourrait sérieusement avancer ou envisager une fin prévisible de JavaScript, pour les raisons que vous avez évoquées et d'autres encore. Je suis étonné cependant d'apprendre que mon sacro-saint pourcentage de javascript de 13% repose sur une aussi fausse information !

On a des preuves à l'appui les copains ?

Haut retour au début de la page

2003.11.24 @ 21:47 par Bleizig

C'est par ce que le 'DHTML' en tant que tel ne represente pas grand chose. Il n'a pas de language associe, pas de norme, plusieurs definitions ... juste un mot qui en a confondu plus d'un.

Il est juste apparu avec la notion de realiser des effets dynamiques sur un site sans recharger la page. Ainsi, selon beaucoup de definitions, il englobe l'utilisation de scripts clients aussi bien que l'exploitation des possibilites offertes par CSS (comme les pseudo classes :hover).

Alors quand tu as demande si le DHTML etait mort, je me suis dit: mais il n'est jamais vraiment né! Alors j'ai pense que tu avais confondu avec Javascript.

Haut retour au début de la page

2003.11.25 @ 02:25 par faden

Ouais le DHTML c'est un terme maketing pour dire que la page est dynamique et que ça explose tout. Que y a des pop-up, des frames, et que l'utilisateur il en prend plein la tronche avec des trucs qui bougent et qui clignotent.

Après si les a:hover cest du DHTML ... Pourquoi pas ?

Haut retour au début de la page

2003.11.25 @ 06:26 par CYBERcodeur

En fait, si ma mémoire est bonne, le DHTML est né autour de 1997 par la possibilité de créer des effets de mouseover sur des images en manipulant le DOM pour changer l'image au survol de la souris.

Quand on considère que c'est également la première possibilité dynamique que nous a offert CSS avec le pseudo-sélecteur a:hover, il est tout à fait légitime de penser qu'à terme, les display: none et block remplaceront pleinement le JavaScript pour ouvrir et fermer des menus, recréant une nouvelle forme plus accessible de menus déployants.

Est-ce à dire que DHTML deviendra une simple utilisation astucieuse de XHTML et de CSS ? Peut-être. J'hésite à me commettre, mais chose certaine, c'est qu'on sent effectivement une volonté ces temps-ci de recréer ce type de fonctionnalité, avec des efforts comme ceux de Dave Shea et d'autres dont le nom m'échappe.

Si on parvient à les recréer à deux niveaux, c'est-à-dire un premier niveau capable de permettre l'explosion d'un menu par liste HTML avec listes imbriquées seulement avec CSS *et* d'apposer à cela un second niveau, d'interactivité celui-là, par des manipulations au DOM W3C, alors DHTML prendra une toute autre allure et se libèrera de ses contraintes actuelles.

La technologie sera peut-être toujours aussi déroutante pour l'utilisateur lambda, mais au moins, elle ne véhiculera plus de limitations aussi sévères en terme d'accessibilité. Ce sera toujours ça de pris !

L'utilisateur moyen a beau vouloir apprendre à travailler avec une technologie, l'effort et le temps lui permettront d'éventuellement l'apprivoiser. Mais celui qui en est exclu à priori à beau essayer autant comme autant, il n'aura jamais la chance au départ de vraiment s'y familiariser puisqu'il lui est impossible d'y goûter pleinement.

Si DHTML devient plus ouvert, alors oui, peut-être qu'il a une chance de survivre et de devenir quelque chose de très utile, parce que utilisé proprement, en harmoie avec les normes XHTML, CSS et, à la rigueur, DOM pour des fonctionnalités plus avancées de contextualisation ou de repérage. Cela ne remet pas en cause du tout l'avenir de JavaScript, mais ça nous lance une autre perche envers le fait que JavaScript ne devrait jamais être obstrusif, mais plutôt servir le document de manière facultative.

Après des mois à dénigrer JavaScript à toutes les sauces et à l'accuser de tous les maux, sommes-nous prêts à lui redonner sa gloire d'anatan, sachant que nous somes maintenant plus responsabilisés versus ses propres limites ? Personellement, je crois que oui, mais comme la grande majorité des développeurs ne se sont pas encore posé la question, il s'en passera encore pas mal des hivers avant que massivement, on sente cette conscientisation émerger naturellement du développement Web.

Haut retour au début de la page

2003.11.25 @ 14:13 par Martin Guathier

Quand tu dis 'En fait, si ma mémoire est bonne, le DHTML est né autour de 1997 par la possibilité de créer des effets de mouseover....' et bien tu étais où toi en 1997 ? C'est ma première visite sur ton site et je conte bien y revenir. Je m'initie et j'aurai sûrement des questions pour toi.

Lâche pas le bon travail !!

Martin ;-)

Haut retour au début de la page

2003.11.26 @ 12:44 par Bobe

Ah non, le DHTML pour moi n’a aucune signification. Ou du moins, ce terme regroupe l’utilisation conjointe d’un balisage correcte et de l’utilisation des feuilles de style, d'un script client et du DOM.
Mais ce terme n’a pas de signification légitime.

Haut retour au début de la page

2003.11.26 @ 13:17 par Bleizig

Je suis tout a fait d'accord avec toi Bobe et je pense que la plupart des developeurs le sont: ce mot n'aurait jamais du etre invente.

Haut retour au début de la page

2003.11.26 @ 19:43 par jipi

Il est toujours un peut amusant de voir DHTML réduit à l'élaboration laborieuse de menus déroulant javascriptés. DHTML n'a aucune signification ?... heu ben si c'est du Dynamic HTML donc. A partir du moment ou vous agissez sur la page par l'arbre du DOM vous faites du DHTML, avec ecmascript, CSS ou tout autre méthode, un style appliqué à un node IDentifié c'est du DHTML (je vais me faire fusiller là mais bon c'est la vérité). Un style switcher client c'est du DHTML. Un rollover CSS encore du DHTML...
Il faut donc lui souhaiter une longue vie, et expliquer à ceux qui lui souhaite une mort rapide que ce serait la disparition du web :)
La confusion viens du fait que le premier langage applicatif utilisant massivement DHTML à été javascript dont il est aussi idiot de souhaiter la disparition.
La version standardisé ECMA ne pose aucun problème aux conditions requises par le bon usage : Déporter le traitement dans des fichier externes et offrir des alternatives.
Le débat JE SCRIPT ou non est un faux débat, le bon débat c'est JE SCRIPT COMMENT ?.
Correctement implémenté un traitement ECMASCRIPT est redoutable d'efficacité et de possibilité, y compris pour améliorer l'accessibilité d'une page. (Ne tirez plus je suis déjà mort...)
Et pour les non javascriptiens il vous suffira d'offrir le même genre d'alternatives que vous offrez pour les images, les liens, les animations et tutti quanti.
Le vrai et le seul problème c'est l'épidemie de script indigestes downloadés à tour de bras par les as du copier coller là c'est pas bien du tout ;)
ECMASCRIPT est un langage applicatif très meconnu et très enrichissant, votre navigateur préféré est en grande partie une application ECMASCRIPT, et il est tout à fait possible de bénéficier de la souplesse et des possibilités de ce langage dans une page web, il suffit d'y apporter la même rigueur et d'appliquer les mêmes contraintes d'universalité et d'accessibilité qu'avec les langages standards (dont ECMASCRIPT fait partie soit dit en passant).
La seule et unique recomendation utile au sujet d'ECMASCRIPT est de ne l'utiliser que si la valeur ajoutée est pertinente et sans equivalence et qu'une alternative est possible.
Alors si à l'heure de CSS faire du rollover scripté c'est souvent stupide ca ne doit pas condamner ECMASCRIPT au contrôle de formulaire, ce serait tout aussi stupide...

Et bravo pour ton blog cyber ! :)


Haut retour au début de la page

2003.11.27 @ 09:29 par Olivier

Par mesure de précaution, je suggère de découper le cadavre de jipi en petits morceaux et de les disperser aux quatre vents pour éviter qu'il revienne de l'au-delà nous hanter. ;-)

Haut retour au début de la page

2003.11.29 @ 05:49 par CYBERcodeur

Peut-être contre toutes attentes, je dirai que je pourais être plutôt d'accord avec jipi... Dans le mesure ou on ne me parle plus de javascript mais qu'on me parle d'ecmascript, je n'ai aucun problème avec la technologie. Au contraire, je l'encourage.

N'oublions pas mes bons amis que JavaScript est une technologie 100% propriétaire de Netscape. Dans ce sens, oui, elle serait mieux morte, tout comme le JScript de MicroSoft d'ailleurs.

Pour ce qui est de DHTML, dans la mesure ou il est codé *avec* ecmascript et que des alternatives sont offertes pour ceux qui ne supportent pas la technologie, je l'encourage également. Je n'ai aucun problème non plus à ce niveau, pas plus que j'en aurais avec l'utilisation de Flash pour pousser un branding sur un site (en autant que des alternatives non propriétaires et accessibles seraient également disponibles).

Cependant, ce DHTML de qualité ne devrait pas porter ce nom. Le terme Dynamic HTML devrait être zappé de la tête de tout le monde, justement parce qu'il a été corrompu par tous ces abus et ces trucs minables qui ont envahi le Web et qui ont foisonné par le passé (il y en a probablement autant de nos jours, mais j'ai la chance de ne plus les voir).

Personne ne peut condamner ecmascript, à moins d'aussi condamner CSS ou HTML.Ce sont des normes établies, ouvertes et évolutives qui sont là pour rester. Mais il faut quand même les utiliser sagement, en comprenant l'impact de nos choix technologiques sur les utilisateurs.

Haut retour au début de la page

2003.11.30 @ 05:36 par jipi

Ouaip... :)
Juste une petite précision pour rappeler le lien utile et essentiel pour implémenter un fichier flash et son alternative en conservant un code valide:

http://www.alistapart.com...

C'est déjà cité dans ton blog mais ca me parais utile de le rappeler ne serait-ce qu'en hommage à l'élégance de la solution. :)

Haut retour au début de la page

Les commentaires et trackbacks sont désormais fermés. Pour toute remarque, vous pouvez toujours nous contacter.

Pisteur (Trackback)