Après un premier tutoriel consacré à ces fameuses Déclarations de Type de Document (DTD) HTML4.01 et XHTML1.0, parmi lesquels il paraît parfois difficile de faire son choix, voici un développement complémentaire. Sans entrer ici dans les détails (je vous laisse relire le tutoriel), disons simplement que ce choix est en réalité très simple, si vous l'abordez avec quelques questions élémentaires qui conviendront à la majorité des situations. Pour reprendre la conclusion de ce tutoriel :
- Avec HTML5, utilisez simplement
<!doctype html>, qui a pour mérite de laisser le navigateur en mode conforme aux standards (non quirks).- XHTML1.0 ne sépare pas plus le contenu et la présentation qu'HTML4.01 : dans les deux cas, c'est en fait le choix entre strict et transitional qui fait la différence ;
- Aucune de ces DTD n'apporte plus d'accessibilité a priori : XHTML1.0 n'est pas plus accessible qu'HTML4.01. C'est l'usage que vous en ferez qui fera la différence ;
- XHTML1.0 n'apporte aucun gain "sémantique" par rapport à HTML4.01, dont il reprend les éléments et la quasi-totalité des attributs. Là encore, c'est ce que vous en ferez qui fera la différence.
- Mais XHTML1.0 n'est pas plus difficile à apprendre qu'HTML4.01, au contraire : la syntaxe rigoureuse limite les risques d'erreurs ;
Mais il y a un point sur lequel j'aimerai insister ici : celui du doctype switching, le "changement selon le doctype" et des raisons pour lesquels vous ne devez pas vous en servir pour régler un problème de mise en page.
Tout d'abord, de quoi s'agit-il ?
Ce mécanisme, considéré aujourd'hui comme une des principales clés de l'implémentation des standards, a été inventé... par Microsoft, ou plus exactement par les ingénieurs responsables d'IE5Mac. Salué en son temps comme une avancée révolutionnaire vers les Standards Web, ce navigateur était en effet le premier de l'époque à implémenter de manière fiable une partie du standard CSS. Ce qui posait un problème de taille : traitées selon les règles de ce standard, les pages Web codées à l'ancienne, optimisées pour Internet Explorer Windows, ou pour Netscape... auraient donné le plus souvent des résultats catastrophiques dans un IE5Mac coupable de trop bien respecter les standards Web.
A titre d'exemple, prenons le cas des tailles de caractères : celles-ci, selon les standards CSS, sont héritées par les éléments descendants. Autrement-dit, il vous suffit de préciser la taille de caractères pour l'élément body, et toute votre page en héritera. Mais ce n'était pas le cas des navigateurs de l'époque : pour les Netscape 4.x d'alors, ces tailles n'étaient pas héritées dans les tableaux, alors abondamment utilisés pour la mise en page. Du coup, dans les pages conçues pour ces navigateurs, la taille des caractères était précisée pour chaque élément du tableau, à l'aide de quelque-chose que nous pourrions résumer, en langage moderne, par : body, td, th {font-size: 0.8em;}.
Et alors, me direz-vous ? Où est le problème ?
- Si vous n'appliquiez pas les règles standards d'héritage, le texte de vos cellules faisait bien, comme prévu, 80% de la taille par défaut ;
- Mais si vous appliquiez les règles standards d'héritage à ce tableau, la taille se réduisait par héritage d'élément en élément, pour finir par des cellules dont les caractères ne faisait plus que 50% de la taille par défaut. Pour peu que des tableaux eussent été imbriqués, ce qui était souvent le cas, le texte pouvait finir par arriver à une taille... sub-atomique !
Ce n'est qu'un simple exemple des multiples problèmes de compatibilité soulevés par le passage à une interprétation "standard" par un navigateur conçu à l'origine pour traiter le tout venant du Web. Ces problèmes ne se limitent d'ailleurs pas au rendu CSS, mais concernent également le DOM (javascript, si vous préférez). Si vous êtes curieux, vous trouverez d'excellentes introductions à ce sujet éminement scabreux dans les classiques :
- Picking a Rendering Mode d'Eric Meyer ;
- et Activating the Right Layout Mode Using the Doctype Declaration d'Henri Sivonen.
Retenons ici qu'il fallait donc trouver un moyen permettant à IE5Mac de différencier :
- les pages anciennes manières à traiter à l'ancienne ;
- les pages “standards” à traiter selon les normes HTML-CSS-DOM.
Ce moyen, ce fut le doctype switching :
- en présence d'une DTD HTML4.01 ou XHTML1.0 complète, bien rédigée, le navigateur savait qu'il avait affaire a priori à une page à traiter selon la norme ;
- en l'absence de DTD, ou en présence d'une DTD incomplète telle qu'on la rencontrait alors fréquemment, ou d'une DTD "non W3C", le navigateur présumait qu'il s'agissait d'une page à traiter en mode de compatibilité avec ses précédentes implémentations non standards.
Initié par IE5Mac, le mécanisme du doctype switching a connu un succès fulgurant, et a été adopté rapidement par tous les autres navigateurs. Chacun à sa manière, selon ses propres règles plus ou moins cohérentes avec celles de ses rivaux, nos navigateurs modernes switchent tous allègrement entre, au moins, deux modes de rendu : le mode Strict (conformité au standard) et le mode Quirks (compatibilité avec les anciens modes de rendu). Le doctype switching, loin d'être une péripétie de l'histoire des navigateurs, est encore aujourd'hui un mécanisme essentiel du Web rétro-compatible.
En quoi est-ce que cela me concerne ?
Si vous pensez en lisant ces mots : "Bon, c'est intéressant, mais ce mécanisme assumé par le navigateur est totalement transparent pour le développeur de site qui a choisi de respecter les standards"... Alors, heureux webmestre que vous êtes, ce qui suit ne vous concerne pas. Continuez à utilisez les DTD complètes, indiquées par le W3C, et retournez à vos travaux, la conscience tranquille.
Si, en revanche, vous êtes en train de vous dire quelque-chose comme : "Ah... C'est donc pour cela que mes pages vont bien seulement quand j'utilise une DTD un peu plus courte, ou telle DTD bien précise", du type : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">... Alors, lisez attentivement ce qui suit :
Le piège du doctype switching
Imaginons, par exemple, que j'aie callé au pixel près une superbe mise en page CSS2 sans tableaux de présentation. Je constate, inévitablement, des problèmes de rendu dans tel ou tel navigateur : les uns vont en effet calculer mes largeurs de boîte d'une certaine manière, les autres vont les calculer selon le standard CSS ; les uns vont appliquer le modèle de calcul des padding CSS, d'autres une version très personelle de celui-ci ; etc. Il existe encore bien d'autres raisons expliquant mon problème.
Dans tous les cas, le rendu au pixel près est une coûteuse illusion, dont nous reparlerons un autre jour, mais restons-en pour l'instant à ce constat : finalement, le résultat d'un navigateur à l'autre ne me convient pas.
Que se passe-t-il ? Les standards sont-ils en cause ? CSS est-elle donc une norme illusoire ? Non : le problème est ailleurs.
J'ai tout simplement conçu ma mise en page selon un modèle hors-norme, celui du modèle de boîte CSS propre à Microsoft, ou bien son implémentation très personnelle de la propriété width, ou etc. : je me suis en fait fourvoyé en ne suivant pas le standard CSS. J'aurais pu tout aussi bien développer, sans le savoir, en fonction de telle ou telle autre implémentation propre à un navigateur ou à un autre.
Que faire ? Ou plutôt, que ne faut-il surtout pas faire ? Tout simplement, il ne faut surtout pas choisir alors la DTD de manière à résoudre ce problème de rendu sans rien changer au code CSS (ou javascript, ou HTML). En effet, cela consiste à adopter une de ces DTD, par exemple incomplètes, qui vont basculer tous les navigateurs en mode de rendu Quirks. Du coup, ma page est affichées correctement... sur la base d'un modèle de développement propriétaire, non standard, et totalement dépassé.
En outre, chaque nouvelle version de chaque navigateur est susceptible de modifier son mode de rendu Quirks, sans crier gare et de manière tout à fait arbitraire : seul le mode de rendu Strict garantit qu'il ne changera que si la norme elle-même change.
En d'autres termes, en faisant ainsi, je vais reconduire et reproduire des pratiques de codage peu fiables, auxquelles il s'agit justement de mettre fin. Le doctype switching est fait pour traiter les anciens contenus qu'on ne pourra pas mettre à jour, pas pour en générer de nouveaux sur le même modèle défectueux ou problématique.
Que faire ?
Les règles de bonne pratique de codage que l'on peut recommander sont simples :
- Pour ne pas reconduire d'anciens modèles périmés, ne pas développer dans un navigateur à l'implémentation HTML/CSS réputée défectueuse. Autrement dit, ne pas prendre en particulier Internet Explorer 6.0 Windows comme navigateur-type. Lui préférer les navigateurs modernes implémentant strictement les formats HTML et CSS, tels qu'Opera, Firefox, Konqueror. Nous espérons tous pouvoir développer dans un avenir plus ou moins proche dans un IE7 respectueux des standards, mais ne confondons pas aujourd'hui IE6.0 et cet éventuel IE7 ;
-
Ne pas utiliser une autre DTD que celles recommandées par le W3C, autrement-dit, pour les 2 principales :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -
Sur un point de détail parfois rencontré : ne pas jouer sur le fait qu'un prologue XML, ou tout autre contenu placé avant la DTD, va basculer Internet Explorer Windows, et lui seulement, en mode de rendu Quirks : si vos documents sont en XHTML1.0 sans que vous sachiez gérer les types mimes
text/htmletapplication/xhtml+xml, il ne faut pas mettre ce prologue XML (du type<?xml version="1.0" encoding="UTF-8"?>) qui n'a en fait aucun sens dans le mode où vos pages seront traitées.
En conclusion : laissons le doctype switching rester le mécanisme transparent qu'il a été conçu pour être, sans jouer volontairement avec lui pour régler (illusoirement) un problème de rendu d'affichage ou de comportement. Ceci est d'autant plus important que, dans les mois à venir, le futur IE7 va sans doute faire reposer ses progrès CSS sur ce mécanisme du doctype switching...
Dans ce type de situation, plutôt que de s'enferrer dans des pratiques problématiques, la meilleure démarche est de remettre l'ouvrage sur le métier, et de revoir entièrement si nécessaire la mise en page, le comportement ou la structure concernés.. cette fois-ci selon les standards ;)