Javascript est un langage assez fabuleux : Il est interprété sur tous les navigateurs (avec de sérieuses nuances), il est relativement rapide à développer et à exécuter, et il permet des effets en manipulant le HTML, l'arbre DOM du document ou les CSS.

Dans mon précédent design (conçu en 2003... ahem...), j'insérais dans mon document HTML des commandes Javascript pour chaque balise fonctionnelle, or certaines étaient liés à des groupes. Genre toutes les balises class="masqueur" qui ont une action sur les balises "masquable" correspondantes.
Ça donnait ceci :

<dt class="masqueur" id="bloc" onclick="flipflop('bloc')" title="cliquez pour afficher">Quelque chose à écrire!</dt>
<dd class="masquable" id="bloc_m">Texte caché</dd>

Ça devenait assez chiant à coder. Que faire ? Laisser le travail à PHP, en priant qu'on ne s'emmêle pas les pinceaux dans un code à étage multiple ? Une solution qui serait devenu difficile puisque mon CMS (Dotclear) introduisait un système de template, rendant les inclusions PHP difficiles à gérer.

Exemple pratique : Supposons que vous avez un blog de plus de 800 billets et 500 pages statiques, que dedans, vous utilisez des effets comme l'affichage de galerie d'images ou d'effets de cacher/décacher dynamiquement par javascript. Supposons que vous changez toute votre base, ou même plus simple, que vous changez tout simplement de bibliothèque d'effets Javascript. Vous vous voyez tout modifier puis revérifier ?

À la réflexion, ce genre de Javascript embarqué n'a rien à faire dans le balisage HTML : il le rend lourd, pénible à maintenir, et n'a aucune utilité pour les logiciels clients qui n'utilisent pas Javascript (le panel est large : des robots de moteurs de recherche, jusqu'aux lecteurs braille en passant par les téléphones mobiles qui en plus paient au kilo-octet). Sans compter qu'il génère des incompatibilités dans l'usage des comparateurs < et > ou de l'opérateur &&. Perso, je suis pas fan des <![CDATA[ ...]]> dont j'ai jamais été fichu de retenir la syntaxe.

L'un des premiers effets réellement simples et réussis que j'ai vu d'insertion d'effet dynamiques en fonction du code HTML, c'est Lightbox. Pour appeler Lightbox, il suffit d'entourer une balise <img /> affichant une image réduite, vers l'original de la même image. Sauf qu'on utilise l'attribut rel=. Si celui-ci comporte parmis ses paramètres le mot-clé "lightbox", le lien traditionnel est remplacé par le lancement du visionneur JS.

Brillant.

• Parce qu'il supprime tout appel Javascript du HTML,
• Que cet appel est construit par manipulation DOM du document HTML
• Que si Lightbox n'arrive pas à faire son travail, les balises HTML restent fonctionnelles, c'est ce qu'on appelle de la dégradation élégante
• Qu'il utilise un attribut de la balise <a /></a> conforme mais peu utilisé

Lightbox a vite eu un panel très large d'utilisateurs. Mais il avait aussi l'inconvénient d'utiliser Prototype.js, Effects.js et Scriptalicious.js. Ce qui rendait les appels de page très lourds, notamment sur les appels (j'en parlerais prochainement). Très vite, de nombreux clones sont apparus, améliorant ou étendant ses possibilités. Seuls ceux qui utilisent le même type d'appel simplifiés sont réellement utilisés, et à raison : Tout autre méthode rend trop dépendant d'une bibliothèque qu'on pourrait être amené à changer.

En en ayant compris le principe, il devenait très rapide de s'imposer de nouvelles techniques pour créer son site web. Puisque j'utilise des classes HTML de manière conjointe avec certaines fonctions Javascript, il suffisait de manipuler mes documents HTML par ma bibliothèque JS personnelle, à la volée par le navigateur du client. Faire en sorte que celle-ci s'initialise (une fois que le navigateur a complètement parsé le document, sinon ça peut péter), en lui faisant manipuler des classes d'éléments. Les paramètres des fonctions sont tout simplement lus par le nom de la balise. Ce qui nettoie radicalement mon HTML :

<dt class="masqueur" id="bloc">Quelque chose à écrire!</dt>
<dd class="masquee" id="bloc_m">Texte caché</dd>

Et simplifie mes appels :

function flipflop() {
  var objet = document.getElementById( this.id+'_m' );
[etc...]
}

Le gain de rapidité est évident. Puisque les “éléments superflus” d'animations sont produits si le navigateur client peut les lire. Et qu'on obtient à la fois une cohérence de développement, mais aussi d'aspect puisqu'une fonction hérite du coup de propriétés CSS, lui donnant un réel look&feel. Le comportement des navigateurs n'est pas encore suffisament uniforme sur l'arbre DOM en Javascript, mais on arrive à des résultats absolument bluffants.
Mais attention : Si une fonction Javascript n'est requise que par un seul document HTML, il vaut mieux l'y laisser pour ne pas alourdir sa propre bibliothèque JS, ce qui serait passer de Charybde en Scylla. Écrire un programme en Javascript avec ses multiples dialectes n'a rien à voir avec une définition CSS... Mais plus les sites le feront, plus Microsoft sera obligé d'y réfléchir.

Quelque chose qui rappelle exactement ce qui s'est passé quand on a séparé la forme du fond. Quand toute la présentation fut retirée du HTML (adieu color= de sinistre mémoire !) et réuni en un seul endroit, le CSS. C'est peut-être ce qui manque encore à maîtriser :
Sortir les comportement globaux d'effets du HTML pour que le Javascript s'en occupe tout seul.