Le HTML dans le potage

Commençons par un constat : un petit tour sur le site Cool Homepages, qui sélectionne depuis des années des sites selon la beauté et l’originalité de leur graphisme et/ou de leur navigation (cela étant évidemment subjectif), devrait terrifier les amateurs de standards ouverts : quasiment tous les sites sélectionnés sont désormais réalisés en Flash. Le choix du graphiste serait donc, pour la réalisation d’un beau site, un format propriétaire, alors même qu’on nous vante un XHTML arrivé à maturité ? Cela devrait tout de même inquiéter... Le même constat peut être fait sur toutes les pages de sélection de « beaux » sites.

Cela est très paradoxal : depuis l’année 2000, les recommandations pour les nouvelles normes sont publiées et les navigateurs grand public ont largement eu le temps de les intégrer. Pourtant, le HTML semble planté en rase campagne, utilisé pour faire du Web à papa, les navigations rigolotes étant désormais réalisées avec Flash.

Tout un discours s’est développé autour des nouvelles normes, basé sur des dogmes pinailleurs et tâtillons, introduisant une rupture avec l’ancien HTML ; et pourtant, on se retrouve aujourd’hui à attendre désespéremment des « innovations » qui viendront récompenser nos efforts vers la « compliance ». Il serait bon, en effet, qu’on s’amuse autant avec le XHTML bien propret du docteur W3C qu’avec le HTML tout pourri dont nous gratifiaient les versions successives de Netscape 2, 3 et 4...

Des effets étonnants sur l’écosystème

La normlisation programmée des Css a coïncidé avec l’apparition d’une nouvelle espèce d’écureuil mutant (du désert), pris ici sur le vif en Arizona.

CSS

Commençons par la technique qui a le plus apporté au HTML, pour en dire du bien, mais aussi pour pointer les limites et les aberrations de choix dogmatiques dans la définition des normes.

Les styles (regroupés en feuilles de styles : CSS) ont été normalisés dès 1998 : il s’agit de séparer d’un côté le contenu structuré de l’information (indiquer que ceci est un titre, ceci est le texte principal du document, ceci est une liste de liens de navigation...) et, d’un autre côté, dans les feuilles de style, la présentation graphique de cette information (je veux présenter les titres de telle manière, dans telle taille, avec tel espacement au-dessus et en dessous, je veux que mon texte apparaisse à tel endroit de telle façon, je veux que les liens s’affichent de telle manière...).

C’est, pour l’essentiel, une belle réussite. Non seulement parce que l’on peut faire tout ce que l’on faisait auparavant avec un code plus lisible (donc plus facile à modifier par le webmestre), plus rapide à charger (les styles sont des fichiers communs à plusieurs pages, donc ne sont pas téléchargés pour chaque page), mais aussi parce que, de plus, on peut faire ce qui était difficile ou impossible auparavant (contrôle typographique beaucoup plus fin, interface différente pour la même page selon le support — principalement, selon que l’on voit la page sur l’écran d’un ordinateur ou qu’on l’imprime...).

Par ailleurs, pour peu que les CSS soient présentées sans dogmatisme (comme confondre l’utilisation des CSS et le passage à un XHTML ultra-compliant), elles s’intégrent dans la courbe d’apprentissage normale d’un webmestre sans trop de souffrance.

Les bienfaits des CSS sont largement détaillés par ailleurs, inutile de trop développer ici. Consacrons-nous à une tâche un peu plus originale : en dire du mal !

Les CSS souffrent d’un dogme originel : les CSS ne doivent pas devenir un langage de programmation. Cette volonté est très discutable (ce que nous allons faire immédiatement), et fait apparaître des limites dans leur utilisation.

Il existe des sélecteurs et des pseudo-classes qui permettent d’appliquer (au moins sous Mozilla-Firefox) des styles de manière intéressante. Cependant, on obtient des syntaxes très complexes pour des possibilités très limitées. Par exemple, on peut définir le style de la première lettre du premier paragraphe qui suit la fermeture d’un intertitre, ainsi que la première lettre du premier paragraphe d’un texte. C’est assez amusant à faire, d’autant que la définition du style est interminable (ici pour une page générée avec SPIP) :

En revanche, vous n’avez pas accès à la seconde lettre du paragraphe, vous ne pouvez pas définir un style qui s’appliquerait à une ligne de tableau sur deux, vous ne pouvez pas tester si la première lettre est un guillemet ouvrant, auquel cas vous souhaitez appliquer le style, également, à la deuxième lettre (pour faire une belle lettrine), vous ne pouvez pas réduire la taille du texte en fonction du nombre de caractères, etc.

Dans le but d’éviter que les CSS ne deviennent un langage de programmation, leurs concepteurs se sont visiblement astreints à des limitations très importantes.
— Il n’y a pas de syntaxe pour des alternances, ou de positions relatives dans la structure (une occurence sur deux, la seconde occurence sur trois, l’avant-dernière occurence...).
— Il n’est pas possible d’appeler une définition depuis une autre définition, ce qui oblige à des doublons dans les définitions : par exemple, on définirait un style « police-helvetica », un style « taille-10 », et dans une autre définition on pourrait indiquer qu’on intègre les styles « police-helvetica » et « taille-10 », que l’on panacherait avec un fond coloré, etc.
— On manipule sans cesse des nombres et des dimensions dans les CSS (taille des caractères, espacements, couleurs RVB...), mais il n’existe aucun outil pour les manipuler ; il n’existe en particulier pas de « variables » réutilisables à différents endroits.
— Les choix conditionnels sont quasiment inexistants (limités à quelques pseudo-classes à la syntaxe très limitée ; les conditions ne se trouvent d’ailleurs pas à l’intérieur des définitions elles-mêmes). On ne peut pas, par exemple, utiliser telle couleur si l’environnement du style est dans telle taille de caractère, et telle autre couleur si le fond sur lequel il s’applique est de telle couleur. Voici un automatisme que l’on se condamne à réaliser « à la main », alors qu’il pourrait être pris en charge par les CSS : plaçons une image au début d’un paragraphe ; si cette image est de petite taille, il sera graphiquement avantageux de la faire « habiller » par le texte (float) ; si elle est d’une grande largeur, il faut la sortir du paragraphe et ne pas l’habiller avec le texte, sinon on aurait des lignes trop courtes pour que le texte soit élégant (display:block).
— Et aucune de ces limitations ne peut être résolue par le recours à Javascript dans les définitions des styles, puisqu’il n’est pas prévu de déclencher du javascript depuis les feuilles de style.

En réalité, c’est pire : il existe une solution partielle mais puissante. Ce sont les « comportements » (behaviors), et les « expressions » de Microsoft Explorer. Les comportements ne semblent pas avoir dépassé le stade de « working draft » du côté du W3C (août 1999).

Ces particularités de Microsoft Explorer sont très utilisées, bien que peu connues : elles sont habituellement utilisées pour combler les manquements de ce logiciel à la norme (les webmestres les considèrent quasiment comme des « hacks » pour faire « salement » ce que Mozilla ferait « proprement ») ! On les utilise pour lui faire accepter un « max-width » ou utiliser la transparence alpha d’une image au format PNG 24. Leur utilisation ne peut malheureusement que se limiter à cela puisque, ces éléments n’étant pas définis par une norme (encore une fois : il s’agit visiblement d’éviter à tout prix que les CSS ne ressemblent à un langage de programmation), il ne sont pas intégrés et il n’en existe pas d’équivalent dans les autres navigateurs.

Pour illustrer ce propos, il est intéressant de consulter une page du CSS Zen Garden. Je vous invite à afficher de code source de cette page.

  Pour permettre aux graphistes de définir des rendus graphiques différents pour le premier, le second et le troisième paragraphe d’un groupe de paragraphes, chaque paragraphe utilise une classe différente (class="p1", "p2", "p3"). Cela parce qu’il n’est pas possible, dans les feuilles de style, d’appeler « le deuxième paragraphe par le groupe », ou bien « le dernier paragraphe ». On a donc une page codée pour un usage spécifique, usage non généralisable (que se passe-t-il s’il y a une classe "p7" non prévue par le graphiste ?), destiné à contourner une limitation des CSS.

  Chaque grande partie du document bénéficie d’un identifiant (« id ») unique. Ce qui permet de traiter différemment chaque bloc, mais en même temps rend les possibilités de généralisation et d’automatisation impossibles. Si CSS Zen Garden change le contenu de ses pages, ou veut ajouter une deuxième page d’exemple, tous les CSS doivent être redéfinis (ce qui n’est vraiment pas l’idée derrière les CSS).

  Le code de la feuille de style contient d’innombrables doublons, que ce soit pour des définitions de marges, mais aussi pour des définitions de couleurs. Certes cela aurait pu être codé différemment mais, comme indiqué, la norme pousse assez facilement les webmestres à définir différentes classes avec les mêmes éléments. Si le code HTML est, lui, très lisible et assez facile à « maintenir », la feuille de style ne l’est pas (c’est, dans la pratique, une conséquence très fréquente de la syntaxe des CSS).

  Les intertitres, très jolis par ailleurs, sont réalisés avec des images (par exemple : « Requirements ». Ces images sont appelées par les feuilles de style, ce qui permet d’en changer en fonction de chaque feuille de style (les images ne sont pas codées directement dans le HTML). Cependant, leur appel est défini « à la main » dans la classe de chacun des intertitres. Cette méthode ne peut absolument pas être automatisée. Or, on pourrait imaginer que la définition générale des intertitres contienne l’appel à un script fabriquant lui-même cette image à partir du texte contenu dans l’intertitre (pour « <h3>Requirements</h3> », la définition de « <h3> » pourrait spécifier que le fond est une image fabriquée par un script transformant le texte en image typographique, à partir du texte compris entre ces balises, c’est-à-dire « Requirements »).

Toutes ces limitations font que, dans la pratique, il est très difficile de réellement séparer le fond et la forme.

  Comme le code source de CSS Zen Garden le montre, c’est une démonstration non généralisable (pas « exportable »), parce que l’encodage est directement lié à l’effet recherché. On a à la fois des lourdeurs (un classe différente pour chaque paragraphe) et des définitions complètement liées au contenu de la page (on définit le style de tel intertitre ; ce qui, ici, donne l’effet très paradoxal suivant : on peut changer la feuille de style de la page de démonstration, mais on ne peut pas changer la page de démonstration elle-même ; le système tel qu’il est ainsi conçu, pour un vrai site (au sens : un site avec des contenus différents dans différentes pages), exigerait de définir une feuille de style différente pour chaque page du site Web !). On se retrouve souvent face à cette difficulté : il faut réellement coder ses pages d’une certaine façon pour parvenir à les contrôler finement avec des CSS ; une page Web vraiment très simple, avec une utilisation très logique et très simple (on pourrait dire « saine ») des classes, sera, justement, difficile à contrôler très finement avec les CSS.

  L’utilisation principale de Javascript est le contrôle de l’interactivité, c’est donc une utilisation graphique. Javascript permet d’ailleurs, désormais, d’accéder simplement et de façon très standardisée, aux éléments contenus dans une page (DOM/Javascript). Or, en refusant par principe de lier les CSS et Javascript, on condamne les webmestres à des solutions bancales.
— La plupart des effets « de survol » sont codés dans les pages HTML par des « onMouseOver » et des « onMouseOut » qui déclenchent des fonctions Javascript nommées dans la page Web ; de fait, on se retrouve une fois de plus à devoir encoder directement l’interactivité à l’intérieur de la page Web, plutôt que de faire gérer cela par les CSS (selon la même logique que les :hover des CSS). Ainsi on constatera que les CSS Zen Garden sont très statiques, puisqu’il n’est pas possible de définir des comportements Javascript à l’intérieur des différentes feuilles de style.
— Pour éviter l’insertion de code à chaque balise du code, on peut tenter d’« atteindre » en Javascript certaines balises (par exemple, remplacer automatiquement des intertitres <h3> par leur image typographique, on se trouve contraint à utiliser des scripts très lourds (et, surtout, complexes).
— Beaucoup d’éléments de mise en page peuvent avantageusement profiter de calculs, les dimensions, positions et espacements se définissant en fonction des dimensions d’autres éléments de la page. Là encore, on est condamné à des scripts très lourds et inutilement complexes. Voici un exemple de tels « calculs » de mise en pages :

Avec Javascript, multicolonnage et multipage

(On trouvera une version nettement plus tarabiscotée de cet effet sur le site de l’International Herald Tribune.)

Cette longue explication essaie d’attirer l’attention sur une caractéristique de la « norme W3C » : une idée intéressante, qui répond à un besoin certain, mais limitée par une vision dogmatique de l’informatique. L’idée que l’on va séparer très strictement la structuration de l’information (la page Web elle-même), le graphisme (la feuille de style CSS) et l’interactivité (Javascript). Séparation qui ne correspond pas aux besoins réels du webmestre :
— le graphisme ne peut se faire réellement sans un minimum de test conditionnels et de calculs ;
— l’interactivité et le graphisme sont intimement liés.

Ce qui, dans la réalité des pages Web, se traduit par des solutions contraires à l’idée d’origine :
— les pages sont encodées en fonction des besoins des CSS, et non le contraire ;
— l’interactivité est également encodée à l’intérieur des pages (l’ergonomie n’est donc pas plus transposable que le graphisme) ;
— les CSS sont raremement un modèle d’élégance informatique, avec force redondances et lourdeurs ;
— les éventuels calculs de mise en pages se font « par l’extérieur » avec des scripts inutilement lourds, lents et compliqués.

Une « compliance »sauvage

Les recommandations s’étendent même à la taille des hotdogs, et l’usage restritif de la balise <moutarde>

DOM/Javascript, la faute aux webmestres

Évoquons maintenant une technologie qui existe, qui est implémentée, qui donne d’excellents résultats, mais qui n’est pas très exploitée... Il s’agit d’exposer non un manque technique ou une limitation dogmatique de la norme, mais un état d’esprit assez sidérant : à force de se focaliser sur le XHTML et le code « compliant », on perd de vue les possibilités intéressantes du HTML, au profit de Flash.

DOM/Javascript est la combinaison de deux techniques :
  DOM, Document Object Model, standardise l’accès à la structure d’un document ; proche de l’usine à gaz, mais certaines utilisations assez simples sont valables sous tous les butineurs, ce qui permet de « manipuler » les différents éléments d’une page Web sans trop de difficulté ;
  Javascript est ce vieux langage inséré à l’intérieur du HTML, et qui s’exécute chez le client.

Énormément de choses réalisées aujourd’hui en Flash peuvent être faites en HTML grâce à cela. Rappelons l’exemple de plusieurs colonnes sur plusieurs pages. On peut aussi réaliser de petites animations, ou des animations de grands blocs :

Animations de grands blocs

Une version finalisée est en ligne.

Une trifouillée de possibilités, qui devraient exciter le graphiste, mais qui se perdent dans des considérations techno-centrées et tristounettes. Alors que le DHTML (Dynamic HTML) avait provoqué énormément d’expérimentations (notamment au niveau des interfaces de navigation) de la part des webmestres, tout en se heurtant à l’époque à d’impossibles problèmes de compatibilité, la généralisation de DOM/Javascript permet de manipuler directement les styles et, pour les plus courageux, les nœuds de la structure, avec une compatibilité entre navigateurs assez simple à assurer ; pourtant, hormis un nombre sidérant de menus déroulants, le choix premier du graphiste pour animer ses pages et réaliser des navigations un tant soit peu rigolotes reste Flash.

Faut-il voir là un des dommages collatéraux des interminables pinaillages autour d’une utilisation fadasse du XHTML, les webmestres se retrouvant embringués dans des considérations interminables sur la « compliance », plutôt que sur une utilisation ludique et originale de ce qui se fait déjà ? (La consultation des forums est souvent dramatique : le webmestre qui vient demander un conseil pour ses animations se voit trop souvent imposer un « t’as qu’à faire ça avec CSS et :hover, tu peux me croire c’est vachement mieux — le tout tournant généralement aux considérations vaseuses sur MSIE qu’il est pas compliant et des conseils foireux pour des « hacks CSS » pour MSIE 5.)

On peut rapprocher cette partie des limites, évoquées ci-dessus, des CSS : ne pouvant gérer les « événements » (tels que les survols) directement depuis les feuilles de style, le recours intensif aux possibilités de DOM/Javascript impose soit de « salir » le code HTML avec une foultitude de « onMouseOver » et autres « onMouseOut » — ce qui rend la page difficile à maintenir — ou d’« attaquer » les balises depuis l’extérieur de la page à l’aide de scripts très lourds — également difficiles à maintenir, parce que quelques mois plus tard on ne sait plus trop comment ils fonctionnent...

Signalons, pour le plaisir du paradoxe, que les possibilités de DOM/Javascript, associées à certaines caractéristiques des CSS, telles que les positionnements absolus et les possibilités de masquages (display: none), embringuent très facilement les webmestres dans des constructions, impossibles avec les versions précédentes du HTML, et qui, pour le coup, détruisent complètement l’accessibilité : informations redondantes (puisqu’affichées ou masquées au besoin), structure non logique (puisque positionnement absolu)... Il y a un aspect pousse-au-crime de DOM/Javascript !

Le XHTML n’existe pas...

L’erreur la plus courante consiste à confondre, purement et simplement, le XHTML avec l’utilisation des feuilles de style (CSS). Fréquemment, les arguments en faveur du XHTML se résument à présenter la souplesse, la puissance, l’accessibilité... liées à l’utilisation de styles, en lieu et place des interminables balises qui prédominaient auparavant.

Or, et ce point est particulièrement important ici : les CSS ne définissent pas le XHTML. Les CSS s’utilisent parfaitement avec le HTML ; il n’y a rigoureusement aucune innovation en matière de CSS liée à l’adoption du XHTML. Oui, les CSS sont absolument formidables, souples, puissantes... elles rendent des services épatants (je ne détaille pas) ; mais, non, elles ne sont en rien l’apanage du XHTML.

Ce qui définit le XHTML par rapport au HTML, c’est l’extensibilité (« X »=« eXtensible »), ainsi que le définit le W3C dans sa recommandation de janvier 2000 (oui, ça commence à dater...) : « XHTML 1.0 : The Extensible HyperText Markup Language. A Reformulation of HTML 4 in XML 1.0 ».

Et c’est justement l’inexistence de ces « eXtensions » qui pose aujourd’hui problème pour vanter l’intérêt du XHTML. Aujourd’hui, ce qui existe, c’est du XHTML sans extensions - autrement dit du HTML « reformulé ». Et si l’on se limite à cela, on ne fera que confirmer la tendance de Cool Homepages : pour faire du Web sympa, passage par Flash - ce qui serait particulièrement dommageable, Flash présentant nombre de défauts rédhibitoires pour assurer une évolution saine du Web (Flash ne faisant pas évoluer le Web vers des habitudes « saines », telles que : automatismes simples, ouverture aux débutants, facilité d’interfaçage avec des logiciels libres, accessibilité et portabilité, échanges entre sites, etc.).

Revenons à CSS Zen Garden. Certes, tout cela est très joli ; mais il faut être clair : c’est une très mauvaise (si ce n’est une des pires) façon de « vendre » le XHTML : on se contente d’y réaliser, en XHTML 1.0 Strict, des choses qui sont tout aussi réalisables en HTML 4 (avec un code quasiment identique, puisque les CSS sont parfaitement utilisables en HTML 4). Le site milite donc pour un HTML propre et simple utilisant les CSS (elles, pas forcément propres et simples), mais en aucune manière pour un XHTML original (le site n’évoque d’ailleurs pas lui-même le XHTML : il met en avant les CSS).

En consultant le code source, on fera un constat supplémentaire, constat généralisable à quasiment toutes les pages qui adoptent un « DOCTYPE XHTML 1.0 Strict » : le « content-type » (le type de contenu) est défini comme étant « text/html ». Et non comme du « application/xhtml+xml », qui est la définition d’un contenu XHTML « extensible ». Cela n’est pas interdit, mais comme la recommandation du W3C l’indique, cela limite grandement l’originalité de ces pages : « The use of “text/html” for XHTML SHOULD be limited for the purpose of rendering on existing HTML user agents, and SHOULD be limited to [XHTML1] documents which follow the HTML Compatibility Guidelines. » Pour qu’une page exploite les extensions du XHTML, elle doit être en « application/xhtml+xml » (c’est le cas, déjà, pour afficher du MathML dans Firefox). De fait, si la syntaxe est bien du XHTML, dans la pratique l’utilisation se limite à une utilisable compatible avec le HTML. C’est donc une utilisation extrêmement limitée du XHTML, dont les effets, le rendu et les possibilités sont parfaitement réalisables en HTML (avec, d’ailleurs, un code quasiment identique).

On a vu perspective plus enthousiasmante.

Cela, de plus, semble lourdement influer sur l’évolution des butineurs. Comme nous allons le voir, les développeurs de butineurs n’ont, pour l’instant, proposé aucune solution utilisable des eXtensions propres au XHTML, et la référence permanente au CSS Zen Garden pousse à l’adoption quasi exclusive d’une norme définie en janvier 2000 (pour le visiteur, du Web à papa, mais avec des feuilles de style). C’est un principe assez habituel des développements du Web : une norme n’est utilisée que si les outils existent, et les outils ne se développement que si la norme est utilisée ; tant que la référence est CSS Zen Garden, alors les codeurs développent en pensant « selon » les besoins de CSS Zen Garden.

Pendant ce temps, sur Cool HomePages, c’est une déferlante de sites sous Flash, personne n’imaginant plus qu’on puisse faire des choses sympatoches avec du HTML (et c’est un tort).

Toujours sur les difficultés du XHTML à s’imposer, revenons un instant sur l’accessibilité, un des éléments les plus importants en sa faveur. Je l’ai déjà évoqué dans un article précédent, je pense que cela a été « vendu » de la pire façon possible, sur la base d’une vision dogmatique des normes. La plupart des arguments « contre » le vieux HTML étaient assez systématiquement retournables (parce qu’on peut faire du HTML crado mais accessible et du XHTML très compliant et pas du tout accessible). On peut ainsi reprocher au W3C, dans sa « promotion » des normes, d’avoir livré des validateurs indignes d’adresser la parole à un être humain. Jargoneux et abscons, ces outils ne valident que l’imposition d’une norme dogmatique, sans être ce qu’ils devraient être : des outils d’aide et de pédagogie. Pour s’en convaincre, on pourra visiter un validateur d’accessibilité, et constater la différence d’état d’esprit : conseils, indication du niveau des interventions, ton poli, description des problèmes pratiques que va rencontrer un mal-voyants... Les masochistes du code peuvent préférer se faire interpeller par un expéditif « This page is not Valid HTML 4.01 Transitional ! » (avec un point d’exclamation).

Le son, porté disparu

Parmi les grands absents du HTML (et du XHTML) : le son. Faire jouer un fichier musical sur un site Web oblige à utiliser des techniques spécifiques et, pour garantir la compatibilité entre les butineurs, à ne respecter aucune norme connue... Finalement, le simple fait de vouloir diffuser de la musique ou de la radio condamne le webmestre à (pour faire simple) installer une animation Flash dans sa page.

Quant à réaliser une chose aussi triviale que sonoriser les survols (« bip » quand on survole un bouton), cela n’est réalisable ni avec les feuilles de style, ni simplement avec DOM/Javascript.

Cela va sembler un peu compliqué, mais le W3C propose une solution : la norme SMIL (Synchronized Multimedia Integration Language). Voilà qui est intéressant, d’autant qu’un navigateur grand public est signalé comme capable de comprendre SMIL — tenez-vous bien — : Microsoft Explorer ! Côté Firefox, on ignore si SMIL sera intégré avec SVG (la FAQ de Mozilla semble indiquer que non).

On ne trouvera donc pas, avant un moment, de sites reposant sur XHTML+SMIL pour produire du son (surtout si Firefox intègre cela avec autant d’intransigeance que pour MathML — obligeant à passer en « application/xhtml » —, ou si Firefox implémente SVG sans SMIL, alors que le plug-in Adobe le permettait, ce qui ajouterait encore au difficultés de détection des versions de butineurs).

On peut voir dans cette situation un autre volet de la redéfinition de la norme (passage à XHTML). Plutôt que de privilégier la continuité, la rupture a amené les développeurs de butineurs à se lancer dans des développements énormes, selon des concepts très lourds. Jouer de la musique simplement, chose finalement assez simple si l’on utilise du HTML pas compliant pour deux sous, oblige en XHTML à recourir à des extensions lourdes : lourdes à la fois pour le webmestre, mais surtout pour le développeur de navigateur qui doit intégrer le fait de jouer un son dans le développement d’une norme complète (SMIL). On peut se réjouir, en théorie, de la naissance d’une norme qui permettra des choses très puissantes (pas uniquement faire bip quand on survole un bouton...), mais dans la pratique, il n’est pas possible de faire une chose aussi simple, et la nouvelle orientation privilégie l’entreprise qui peut aligner une équipe complète d’ingénieurs à temps plein pour implémenter la nouvelle norme (devinez...). Ce qui, par rapport au discours habituel autour du XHTML, est assez paradoxal.

Le vectoriel

Les graphismes vectoriels sont une idée absolument épatante pour le Web. Définir des graphismes par des coordonnées offre de nombreux avantages :
  ils sont, à priori, légers ;
  on peut zoomer ;
  surtout : ils sont faciles à fabriquer avec des scripts, ce qui permet de présenter, par exemple, des informations techniques (courbes, etc.) à partir d’une base de donnée ;
  très intéressant également : on peut y placer du texte facilement ; de fait, des graphismes vectoriels deviennent des éléments de navigation et d’interface ;
  puisque les objets graphiques sont définis par des coordonnées, on peut modifier ces coordonnées par DOM/Javascript.

(Flash est d’ailleurs, à l’origine, un logiciel d’animation vectorielle.)

Il existe justement une norme pour cela : SVG, Scalable Vector Graphics, et elle est absolument enthousiasmante. Quand on a joué avec SVG, on n’est pas loin de penser que c’est là tout l’intérêt du XHTML, et que c’est là que se trouve l’évolution principale du Web (d’autant que, dans la logique d’Adobe et son SVG Viewer, SVG et SMIL sont liés). SVG est réellement excitant : facile à coder, facile à produire automatiquement (en PHP notamment), dans la logique du HTML (ou, évidemment, du XHTML), contrôlable facilement par Javascript, utilisant intensivement les CSS...

À lui seul SVG justifie de passer à XHTML.

Des webmestres déboussolés !

Kevin l’avoue lui-même : « avant j’avais deux passions le curling et le XHTML orienté objet, mais à présent, j’ai plutôt envie de trouver une meuf en fait... »

Mais les choses ne sont jamais aussi simples...
  Le principal outil Wysiwyg permettant de fabriquer du SVG étant Adobe Illustrator, SVG est largement perçu comme un façon d’insérer des images vectorielles dans des pages Web, et non comme un grand « conteneur » multimédia fabriqué grâce à des automatismes. Ce qui donne des pages d’exemples généralement assez enquiquinantes à consulter...
  Certaines démonstrations prouvant que SVG peut produire des animations « façon Flash », l’autre utilisation attendue du SVG est le « Flash killer » (un remplaçant complet de Flash), ce qui signifie que les graphistes attendent encore un éditeur Wysiwyg, à la façon de Flash, avant de s’y mettre. (Macromedia, créateur de Flash, et Adobe, créateur de SVG, venant de fusionner, ça n’est pas demain la veille.)
  De fait, puisque cela n’a pas l’air bien excitant pour un graphiste (des images vectorielles peu animées, ou des animations moins faciles à réaliser qu’avec Flash), les développeurs de butineurs ne se sont pas empressés d’implémenter cette norme, alors même qu’elle est, à mon avis, la principale raison de « passer » à XHTML.

On nous promet pour très bientôt une version de Mozilla Firefox qui intègrerait SVG en standard (et non plus sous forme d’extension que l’utilisateur s’installerait lui-même). Tant que, au minimum, Firefox n’aura pas imposé cette utilisation standardisée de SVG, cette norme restera inexploitable par les webmestres.

Sachant que SVG est quasiment aussi vieux que XHTML — septembre 2001 pour la première recommandation officielle du W3C — il serait peut-être temps.

Dingue de maths

La seule autre eXtension existente qui dépend de la normalisation XHTML est MathML. Cette norme doit permettre d’afficher des formules mathématiques dans une page Web. C’est une norme tellement ancienne qu’elle est, sauf erreur, antérieure au XHTML. Sa dernière version, MathML 2.0, date de février 2001.

Mais, là encore, il n’existe pas d’implémentation standard de MathML dans les butineurs. Pas même Mozilla Firefox. MathML n’est utilisable qu’avec des extensions, à charge pour le visiteur de s’installer les logiciels nécessaires, ainsi que les polices de caractères mathématiques. Ce qui n’a rigoureusement rien évident (ces plug-ins de brouteurs ne permettant pas, d’ailleurs, au webmestre, d’être certain que son visiteur pourra ou ne pourra pas afficher les formules de mathématiques, et donc lui proposer une alternative automatiquement).

On retrouve ici le principe du serpent XHTML qui se mord la queue : il n’existe pas de butineur grand public permettant d’afficher du MathML à coup sûr, du coup :
— personne ne publie réellement des pages contenant du MathML,
— personne ne développe réellement les outils permettant de créer du MathML (notamment des traducteurs TeX vers MathML, ceux existants étant encore très insuffisants pour une utilisation réelle),
— et ainsi les développeurs de butineurs ne placent pas l’intégration de MathML dans leurs priorités.

Voici une anecdote qui illustrera mon propos, et qui permettra de faire le lien entre le présent article et l’article « W3C Go Home ».

Au cours du développement de la version 1.8 de SPIP, nous avons introduit un convertisseur de code LaTeX (une façon plus répandue et plus « humaine » de coder les mathématiques que la syntaxe de MathML) en image : SPIP extrait les formules en LaTeX et les transforme en une image de la formule mathématique.

Désireux de rentre le truc plus « Web », on a tenté de compléter cette méthode par transformation de code LaTeX en MathML, de façon à ce que les formules s’insèrent dans le texte en tant que texte MathML, et non plus en tant qu’image.

Premier obstacle : convertir du code LaTeX en MathML. Il existe un grand nombre d’outils, mais tous (absolument tous) sont inachevés. Cela est assez symptomatique : cela fait des années que MathML est défini, mais il n’est pas possible de l’afficher simplement ; ceux qui ont développé des convertisseurs se sont éreintés sur des développements inutilisables dans la pratique. Que ce soit en PHP ou en script sur un serveur, tous les outils ont donné des résultats très incomplets (on trouve même un convertisseur en javascript, mais là c’est encore pire). C’est le serpent qui se mord la queue déjà évoqué : pas d’outils pour fabriquer le format donc pas d’implémentation dans les navigateurs, pas d’implémentation donc pas d’outils.

Ensuite, parvenir à afficher, dans un butineur sur lequel on a installé un plug-in MathML, du MathML. C’est là qu’on constate l’intégrisme des implémentations. Sous Mozilla, l’affichage de MathML n’est accepté qu’avec un « content-type » (évoqué ci-dessus) de type « application/xhtml+xml » ; or, avec ces content-type, Mozilla suit la recommandation aberrante du W3C qui consiste à refuser une page à la moindre erreur de syntaxe HTML (ou plutôt : XHTML) — merci les enfants. Par ailleurs, ces « content-type » ne sont pas forcément acceptés par tous les butineurs grand public ; ces butineurs vous proposent de télécharger une telle page Web, et vous demandent avec quelle application l’ouvrir. Le problème est contourné en installant un javascript (un peu lourd par ailleurs) qui analyse la page Web, « isole » les parties en MathML, et permet de tout de même les afficher, quel que soit le content-type. Le choix de limiter l’affichage de MathML à un content-type intolérant n’est donc pas pratique, mais relève d’un choix quasi-idéologique.

Cela fait (en notant qu’à chacune des étapes précédentes, cela fonctionne déjà couci-couça avec des solutions bancales), il faudrait encore pouvoir déterminer, pour chaque visiteur, s’il a MathML installé sur son butineur (dans ce cas on lui envoie la version en MathML) ou non (dans ce cas on lui envoie la version « image »). Mission impossible : de toute façon les installations de MathML sont tellement problématiques qu’on a même des plug-in installés dans le butineur, mais sans les polices de caractères mathématiques, donc un affichage totalement illisible.

D’autres loufoqueries liées au charset, mais à la longue, le truc est déjà bâché.

Nous avons donc :
— une syntaxe qui nécessite l’utilisation d’outils spécifiques pour la créer (parce que, contrairement à la syntaxe de LaTeX, la syntaxe de MathML ne permet pas qu’on code une formule de mathématiques « à la main ») ; ces outils sont incomplets, puisque les navigateurs ne permettent pas facilement un affichage (même pas un affichage conditionnel : il n’est pas possible de déterminer si MathML sera affiché correctement ou non) ;
— la rupture totale d’avec le HTML, pour adopter une version extrêmement restrictive du XHTML strict (l’implémentation suit la recommandation du W3C : à la moindre erreur, la page ne s’affiche pas) ; or, puisqu’il est possible de « ruser » avec un peu de javascript, le choix d’un comportement intolérant aux erreurs n’a rien d’une obligation technique ;
— devant autant de limitations, l’implémentation de cette norme dans d’autres outils (comme SPIP) est reportée à des jours meilleurs.

Se pose alors la question suivante : pourquoi a-t-on une telle rupture dans la norme précédente (c’est le sujet du précédent article), avec obsolescence programmée et pinailleuse des tags HTML, alors même que les implémentations de la nouvelle norme sont soit inexistantes, soit inapplicables en pratique ? La rupture ne concerne donc pas que la « courbe d’apprentissage » évoquée dans l’article évoqué, elle est aussi dans le développement des outils : là où des outils existent pour afficher du MathML à l’intérieur du vieux HTML (y compris pas très compliant — MathML est réellement un langage de description très ancien), tel que le plugin MathPlayer, les nouvelles implémentations respectueuses de la norme limitent l’utilisation à un type de document très intolérant (nous l’avons signalé : même CSS Zen Garden passe un « content-type » qui interdit d’afficher du MathML).

Résultat : pas de MathML. (C’est même pire : ces traquasseries donnent le résultat suivant : la solution la plus simple consiste, en pratique, à développer son site pour Microsoft Explorer sous Windows, en demandant à ses visiteurs d’installer le plug-in MathPlayer. Sauf erreur, c’est exactement l’inverse de ce pourquoi le W3C existe.)

Reprenons. Les recommandations du W3C qui, réellement, utilisent l’eXtensibilité de XHTML et qui représentent un réel intérêt pour les webmestres, sont presque aussi anciennes que XHTML ; pourtant, elles ne sont implémentées en standard dans presque aucun des navigateurs de nouvelle génération (le moins à jour étant Firefox, qui sert de référence aux webmestres). Ce qui fait que, dans la pratique, il n’existe pas d’extension du XHTML, et l’utilisation du XHTML se limite aujourd’hui à ce qu’on peut tout aussi bien réaliser en HTML.

Quant à pleurer sur les limites des feuilles de style de Microsoft Explorer, c’est passer à côté du problème. Les butineurs présentés comme super-compliants (en gros : tous sauf MSIE) n’intègrent pas plus qu’Explorer les normes justifiant le passage au XHTML, normes pourtant définies il y a quatre ans. Pour vraiment être clair, faire la promotion de XHTML uniquement autour des CSS, c’est nuire à cette norme, qui ne deviendra réellement intéressante pour les webmestres qu’avec SVG, SMIL et MathML. Nuisible, car on démotive les webmestres avec des considérations pinailleuses, dans le but de leur faire coder « proprement » des pages qui, visuellement, peinent à dépasser ce qui se faisait déjà en 1998 ; nuisible car les développements de navigateurs (Firefox, Opera, Konqueror/Safari...) tardent franchement à implémenter ces normes vieilles de plusieurs années ; nuisible enfin parce que le grand public ne se voit jamais exposer l’intérêt réel de ces normes pour lui (quel magazine de presse informatique grand public a signalé à ses lecteurs que Opera 8 intégrait SVG en standard).

Les polices de caractères

Continuons avec nos lamentations de webmestre malheureux (malheureux puisque, vous l’avez compris, je ne peux pas me résoudre à faire avec Flash ce que je devrais pouvoir faire en HTML depuis belle lurette). L’autre sujet qui fâche dans le HTML (et, encore une fois, dans le XHTML), c’est qu’il n’existe pas de méthode normalisée pour y intégrer des polices de caractères.

Or, pour un graphiste, le choix de la police de caractères est l’une des premières méthodes pour créer l’ambiance de son site Web.

Là aussi, on trouvera des puristes pour assurer que (blah blah blah) le HTML n’est pas fait pour cela. Pour se convaincre du contraire, il suffit de constater que la moitié des exemples du fameux CSS Zen Garden utilisent des images pour réaliser les titres et les intertitres (voici un exemple parmi tant d’autres. L’utilisation d’un style CSS un peu particulier permet de ne pas afficher un <img src=...> dans le code source, mais ce sont bien des fichiers graphiques qui sont utilisés pour effectuer le rendu typographique si particulier (rien à voir, en tout cas, avec une « beauté » intrinsèque aux CSS).

Au rayon HTML/XHTML, on ne trouvera aucune norme ni recommandation. Il n’existe, côté « fontes embarquées », que des méthodes tordues à peu près inutilisables et totalement propriétaires. SVG, format vectoriel, permettra-t-il de contourner l’obstacle ?

C’est en tout cas encore un de ces aspects étonnants des développements du Web, axé sur des considérations techniques qui échappent au commun des mortels, au détriment des besoins simples des webmestres et des graphistes.

VRML, RIP

La dernière mise à jour de la page du W3C consacrée au VRML, Virtual Reality Modeling Language semble remonter à... avril 1995. Voilà un langage purement et simplement enterré.

Cela est très paradoxal : le VRML a été très à la mode à une époque où les ordinateurs n’étaient pas capables d’afficher avec souplesse et élégance des modèles 3D en temps réel (c’était au siècle dernier) et où, surtout, les modems ne permettaient pas de télécharger rapidement le moindre fichier VRML (une centaine de kilo-octets, c’était déjà rédhibitoire). Aujourd’hui les machines se débrouillent parfaitement avec des modèles 3D de folaïe et le haut débit rend le téléchargement des méga-octets une partie de plaisir, pourtant la réalité virtuelle ne figure pas du rayon des normalisations prioritaires.

Outre les modèles 3D complexes, il existe un besoin plus « automatisable » : les interfaces graphiques. On trouve ainsi, souvent, des animations Flash en fausse 3D (les possibilités 3D de Shockwave ont, en revanche, fait long feu) ; et on simule souvent un effet de relief (3D) pour présenter une information 2D. Techniques utilisables sur un site Web sans investir dans le développement d’un concurrent à Doom 3...

On dispose d’une norme XML, donc à priori promise à être utilisable en XHTML : X3D. Quant à l’implémentation en standard dans un navigateur grand public, à vue de nez vous pouvez attendre la dernière trilogie Star Wars (épisodes 7 à 9) pour plus tôt.

Flash versus XHTML

Comme je l’ai signalé en introduction, Flash est omniprésent dans les sélections de sites « beaux », et les graphistes y recourent dès qu’ils veulent réaliser une ergonomie un tantinet originale. Et la stagnation du HTML depuis quelques années, l’attente interminable de techniques qui n’arrivent toujours pas, devraient encore plus inquiéter de l’avenir d’une norme ouverte.

Cependant, même en ne se reposant pas sur la promesse de techniques promises mais pas encore exploitables, certains points sauvent le HTML du naufrage. Comprenez bien : le but du présent article n’est pas de comparer le XHTML et Flash (si vous êtes arrivé jusqu’ici, vous avez constaté qu’il n’est pas du tout consacré aux caractéristiques de Flash) mais, avant de conclure, de se demander pourquoi Flash n’a pas encore totalement supplanté un HTML qui peine à évoluer depuis plusieurs années.

Il est important d’éviter, coûte que coûte, le basculement complet vers Flash. Flash, en effet, n’est pas à même d’assurer une évolution du Web vers des habitudes « saines » : les pages sont « fermées » (les visiteurs ne peuvent pas apprendre en consultant le fonctionnement intrinsèque des autres sites, comme on le fait en consultant le code source du HTML), Flash n’est pas du tout accessible aux mal-voyants et aux non-voyants, Flash est très difficile à interfacer avec des logiciels libres, Flash ne promeut pas les échanges entre les sites, un site réalisé comme une grosse animation Flash n’est pas indexable et ne propose pas de « portes d’entrées » permettant de linker de l’extérieur des articles spécifiques, etc.

Mais ce ne sont pas ces considérations qui, dans la pratique, limitent le développement de Flash (ce genre d’arguments n’a d’impact que sur un nombre limité de webmestres à l’éthique janséniste sévère !). Plus prosaïquement :
— HTML reste infiniment plus simple que Flash pour publier vite et bien des documents textuels ; et cela, même, avec un contrôle typographique plutôt puissant grâce aux feuilles de style ; une chose aussi simple que mettre son CV en ligne, avec Flash, est long (pour une entreprise : cher) ;
— il est beaucoup plus simple de créer un site HTML avec des outils de gestion de sites qu’un site Flash ; interfacer Flash à une base de données n’est pas à la portée de la première bourse venue ;
— si cela peut paraître paradoxal, de part ses limitations, HTML tolère, visuellement, beaucoup mieux les petites approximations graphiques (images mal traitées, petites erreurs typographiques, placements pas toujours élégants des images...) qu’une page Flash où la « perfection » graphique qu’autorise le format rend les mêmes défauts graphiques impardonnables ; dit autrement : l’exigence visuelle que l’on a d’une page Flash fait que l’intégralité du site doit, quasiment, être réalisée par un professionnel, là où le HTML réalisé par des amateurs pourra tout à fait sembler « professionnel ». Cette exigence graphique allourdit encore les coûts d’un site en Flash ;
— un site en Flash repose toujours sur du HTML, du XHTML et/ou du XML pour s’interfacer avec une base de données, fournir un feed RSS, etc. ; de fait, alors qu’on peut parfaitement réaliser un site très pointu avec le HTML sans développer la moindre compétence en Flash ; à l’inverse, un site très pointu en Flash impose d’excellentes compétences dans les autres formats. Dans tous les cas, l’apprentissage passe par les formats « texte » ;
— tout de même, l’accessibilité est un point important pour nombre de webmestres hérétiques, ne serait-ce que pour les associations, les administrations et les services publics, qui représentent un volume important des publications en ligne.

Deux autres éléments ont beaucoup joué, également, pour continuer à promouvoir un HTML devenu assez plan-plan :
— la généralisation de PHP sur les hébergements grand public ; une bonne partie de ce que les normes ne font pas (ou pas encore) du côté des navigateurs, est réalisé grâce à PHP du côté du serveur ; des choses anodines comme le redimensionnement et le placement des images, la création d’images typographiques, enrichissent considérablement les mises en page (permettant d’automatiser ce qu’on faisait « à la main » précédemment, et qui était peu viable sur un site aux mises à jour régulières) ; le contrôle des logiciels clients permettent d’affiner ce qui est envoyé au visiteur ; citons aussi les feuilles de style modifiées avec PHP, pour palier les manques des CSS (changer automatique toutes les couleurs dans une feuille de style, inverser « right » et « left » pour faire fonctionner une même feuille de style en affichage « Droite à gauche » comme en arabe...) ;
— le développement des CMS libres a mis à disposition du grand public ces automatismes, permettant le développement de « gros » sites, entièrement basées sur le HTML (et non sur Flash, le développeur d’un logiciel libre n’allant pas, par définition, privilégier un format propriétaire).

Pour beaucoup d’entre nous, c’est de ce côté que se sont déroulées les évolutions « rigolotes » et excitantes, que l’on peut attendre d’un média jeune comme l’internet, alors que le HTML, lui, n’a pas évolué dans le même temps. Il serait temps que le plaisir de « faire » de l’internet passe aussi par le HTML, comme ce fut si longtemps le cas.