Mardi 25 novembre 2003

Cela faisait déja plusieurs jours voire semaines que je butais sur un problème. Impossible d’envoyer mes pages encodées en UTF-8, cela faisait purement et simplement planter mon navigateur (Firebird, faut le faire quand même). Reprenant mes tests ce matin pour essayer de comprendre, j’ai constaté plusieurs choses au fur et à mesure :

1. Le fil RSS, pourtant encodé lui aussi en UTF-8 et à l’aide du même mécanisme (script), s’affichait très bien dans Firebird.
2. Les pages s’affichaient très bien dans Mozilla, Opera 7.22 et IE 6.0 lorsque encodées en UTF-8.
3. Et pour finir, je constatais que les pages de tests, indépendantes en terme de design du reste du site, s’affichaient très bien quelque soit le navigateur (Firebird compris donc).

À ce niveau là, je me disais que le problème venait des données même de la page et non pas des en-têtes HTTP envoyés par exemple. Et puis vient la lueur de lucidité, je retourne voir ma feuille de style principale pour finalement constater ceci :

div#menus li.menu > a:after { content: "\00A0»"; }

Et le problème venait évidemment de là. J’insérais un caractère non encodé en UTF-8 (la feuille de style n’étant pas elle-même encodées en UTF-8) et cela a suffi pour faire planter Firebird. Il m’a suffi de remplacer le caractère » par son code ISO 10646 \00BB pour que tout refonctionne, ouf :)

Que se serait-il passé si j’utilisais non pas Firebird mais Mozilla et que mes pages étaient encodées en UTF-8 depuis le début ? Mes pages auraient été inaccessibles aux visiteurs utilisant Firebird, et ceux ci n’auraient pas pu me prévenir même s’ils en prenaient le temps puisqu’ils n’auraient pu obtenir mon adresse email. Au mieux, j’aurais été prévenu par des amis utilisant Firebird ou par des personnes parvenues ici par l’adresse du site donnée dans ma signature sur les newsgroups.

Cet exemple démontre que, malgré l’application stricte des normes en vigueur, il est nécessaire de tester ses pages sous différents navigateurs car il suffit de peu pour les rendre involontairement inaccessibles à une partie des visiteurs.

Jusqu’à maintenant, on connaissait les documents HTML contenant pèle-mèle des styles CSS et parfois une pincée de langage de script client (généralement Javascript). Ces langages s’intègrent de deux façons dans le document :

• À l’aide des éléments <style> et <script>, et en spécifiant comme il se doit le type MIME avec l’attribut type
• Directement dans le balisage HTML avec l’attribut style et les attributs d’évènement onclick, onselect, etc… Auquel cas, il est nécessaire de préciser le type MIME au niveau global avec Content-Style-Type et Content-Script-Type à l’aide de l’élément meta et son attribut http-equiv

La nouvelle norme du W3C est le XHTML 1.0, laquelle, dans sa forme strict, impose une séparation claire entre le document et les styles et scripts utilisés, ceci pour améliorer la lisibilité, la maintenance et l’évolution du code source. Pour la présentation, c’est simple, il suffit d’utiliser les styles CSS et dans l’idéal de les placer dans une feuille de style externe. Il en va autrement pour le javascript…

Lorsque les concepteurs de pages XHTML intègrent du javascript à leurs pages, ils utilisent généralement les attributs d’évènements onclick, onselect, etc… Or, il est nécessaire dans ce cas de spécifier le type MIME du langage de script utilisé. Le problème est que l’élément meta utilisé avec l’attribut http-equiv n’est pas reconnu par les parseurs XML (Vous aurez donc compris que je parle d’un vrai document XHTML, servi en tant que tel), la note du W3C sur le XHTML et les types de media est claire sur ce sujet :

Note that a meta http-equiv statement will not be recognized by XML processors, and authors SHOULD NOT include such a statement in an XHTML document served as application/xml (and application/xhtml+xml as well for that matter).

Il reste donc deux solutions :

• Envoyer les en-têtes Content-Script-Type et Content-Style-Type au niveau du protocole HTTP ou, si les pages sont générées à l’aide d’un script CGI, à l’aide du mécanisme de script idoine (la fonction header() en PHP). Cependant, je n’ai rien vu concernant ces deux en-têtes dans la RFC 2616 sur le protocole HTTP 1.1
• Pour les évènementiels sur un document, s’interesser aux gestionnaires d’évènement présents dans le DOM niveau 2 (Voir à ce titre cette page de tests très interessantes). Tout comme pour l’attribut style, ça éviterait de semer des attributs d’évènements au sein du document alors qu’ils n’ont rien à y faire (à mon avis).

Enfin, notez que "l’inutilité" des meta avec un attribut http-equiv s’applique quelque soit l’en-tête, que ce soit Content-Type, Expires, etc… et aussi que tout logiquement, l’attribut http-equiv sera purement et simplement absent de XHTML 2.0.

PS : Tiens, ce billet m’a permis de constater que les attributs d’évènements dégagent aussi du XHTML 2.0. Mwaaahaaha… j’adore :-). Vive le W3C !