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 :
- 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.
- Les pages s’affichaient très bien dans Mozilla, Opera 7.22 et IE
6.0 lorsque encodées en UTF-8.
- 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 !