Les déclarations « Doctype » et les en-têtes « Content-type »
Doctype Declarations and Content-Type Headers

Par Tommy Olsson

Je visite régulièrement quelques forums de discussion pour les développeurs web et il y a en ce moment beaucoup de débats pour savoir si XHTML est :

  1. une règle à suivre ;
  2. utile ;
  3. sans intérêt ; ou
  4. complètement idiote.

Des incompréhensions et des affirmations infondées apparaissent de part et d'autre. J'ai donc pensé que je pourrais essayer de clarifier un malentendu aujourd'hui très commun sur l'importance de la déclaration d'un doctype comparée à celle de l'en-tête Content-Type.

Sur quoi repose le problème ?

Pour diverses raisons, beaucoup de développeurs sont attirés par le passage d'HTML à XHTML. Nombreux sont ceux qui le font sans avoir reçu la moindre information sur les réelles différences qui existent entre les deux langages. Ils apprennent que les noms des éléments et des attributs doivent être écrits exclusivement en minuscules, que les valeurs des attributs doivent être entourées de guillemets, et que <BR> doit désormais s'écrire <br />.

(Il y a même des « experts » qui croient que l'espace avant le /> est requis en XML.)

Les développeurs copient la déclaration doctype d'une page sur le net, désactivent le verrouillage des majuscules, dépoussièrent le slash de leur clavier et commencent à écrire. Quelques-uns soumettent leur résultat à un validateur et obtiennent la confirmation qu'ils ont réussi la difficile transition vers XHTML.

Après une période de temps indéterminée, ils reçoivent une remarque acide d'un de ces experts autoproclamés qui leur dit qu'en fait, ils n'utilisent pas du tout du XHTML, mais simplement du HTML mal écrit. L'expert explique que les navigateurs interprètent le document comme s'il s'agissait de HTML et que ce n'est que leur gestionnaire d'erreur (ainsi que le fait qu'ils ne décodent pas correctement le SGML) qui les empêche de sombrer dans le dysfonctionnement le plus complet. Parfois, l'expert mentionne même quelque chose d'assez incompréhensible à propos du Content-Type ou du type MIME du document.

Du coup, le pauvre débutant ne sait maintenant plus sur quel pied danser. Ne dit-il pas dans la toute première ligne de son document qu'il utilise « XHTML », et le validateur ne lui a-t-il pas donné son feu vert ? Comment pourrait-il s'agir d'autre chose que d'XHTML ?

La déclaration Doctype

De nos jours, tout développeur web qui se respecte insère une déclaration doctype dans ses documents. Le plus souvent cette déclaration ressemble à quelque chose comme ceci :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Comme tout le monde le sait « bien sûr », cette déclaration contient le nom de la Définition de Type du Document, DTD, qui coïncide avec le type de l'élément racine du document, à savoir ici : html. Elle contient aussi un identifiant public et un identifiant système à « usage externe ». L'identifiant public spécifie qui publie la DTD (le W3C), l'identité de la DTD (DTD XHTML 1.0 Strict) et le langage dans lequel elle est écrite (EN, pour l'anglais). L'identifiant système n'est quant à lui rien d'autre que l'adresse du document qui contient réellement la définition de type du document sur le site du W3C.

Et alors...?

Que peut bien vouloir dire cette déclaration pompeuse et inintelligible ? Que se passe-t-il lorsque que nous l'oublions ? En fait, rien ne devrait survenir si nous omettions de l'utiliser. Sa seule justification est de définir les règles de grammaire du balisage que nous utilisons dans notre document, et les seuls qui ont vraiment à s'en préoccuper sont les validateurs.

La déclaration d'un doctype n'est requise que pour la validation.

C'est en tout cas ce qu'on avait l'habitude de penser jusqu'au développement d'IE5 pour le Mac et l'émergence d'une nouvelle idée : le basculement de doctype (NdT : doctype switching en anglais). En raison de la difficulté des anciennes versions d'IE à prendre en charge un certain nombre de détails de la spécification CSS, on décida de corriger rapidement les choses. Il y avait sur le Web quelques millions de pages qui ne s'affichaient comme prévu par leurs auteurs que grâce à cette mauvaise prise en charge ! Le basculement de doctype signifiait que le navigateur allait désormais vérifier la déclaration doctype du document, et essayer de déterminer intelligemment si l'auteur avait voulu suivre les standards du W3C ou ceux de Microsoft.

La plupart des navigateurs modernes appliquent maintenant le basculement de doctype, de sorte que la déclaration d'un doctype a désormais une signification réelle pour les navigateurs. Cela dit, ce n'est pas ce qui avait été prévu au départ.

Mais... la déclaration n'est-elle pas censée dire au navigateur quel est le langage de balisage que nous utilisons ? Non, en réalité elle ne le fait pas. Les navigateurs n'ont pas l'habitude de lire les DTD, et plus particulièrement celles qui concernent HTML.

L'en-tête Content-Type

La chose qui contrôle comment un navigateur (ou un agent utilisateur) interprète un document web est l'en-tête du protocole HTTP, nommée Content-Type.

Quand un agent demande une page à un serveur web, il communique via HTTP, le protocole de transfert Hypertext. Chaque message commence avec un certain nombre d'en-têtes. Comme son nom l'indique, l'en-tête Content-Type établit en particulier le type de contenu que contient le message. Elle peut aussi contenir des informations relatives à l'encodage des caractères, ce qui est de la plus haute importance pour la manière dont le contenu sera interprété et affiché par l'agent utilisateur.

Pour une page web, l'en-tête Content-Type peut ressembler à quelque chose comme ceci :

Content-Type: text/html; charset=iso-8859-1

Ce qui signifie que le contenu se présente sous forme de texte simple, doit être interprété en tant que HTML, et utilise l'encodage de caractères ISO 8859-1. Avec cette information, le contenu doit être interprété comme du HTML, même s'il s'avère que « XHTML » figure bien dans la déclaration doctype.

Si nous voulons servir notre XHTML de façon à ce qu'il soit vraiment interprété en tant qu'XHTML par les agent utilisateurs, nous devons envoyer une en-tête HTTP adéquate, comme par exemple :

Content-Type: application/xhtml+xml; charset=utf-8

(La mention de l'encodage des caractères peut - et doit, selon certains - être omise, dans la mesure où XML - et le XHTML n'est rien d'autre que du XML - est supposé être un format auto-descriptif. Toute information relative à l'encodage doit donc apparaître dans la déclaration XML du document.)

Ceux qui choisissent de servir leurs documents avec application/xhtml+xml doivent savoir qu'il y a des différences considérables dans la manière dont les agents utilisateurs gèrent XML et HTML. Si nous n'avons pas connaissance de ces différences, il est vraisemblable que notre document ne s'affichera pas comme nous l'avons souhaité - ou ne s'affichera pas du tout.

Mais l'ignorance est-elle ici la seule raison pour laquelle aussi peu de documents XHTML sont servis avec un application/xhtml+xml ? Non, une autre raison relativement importante est qu'Internet Explorer - le navigateur le plus utilisé du moment - n'intègre aucun support pour les documents servis avec application/xhtml+xml.

Pour être en mesure « d'utiliser » XHTML, sans perdre trop de temps et de puissance serveur sur ce qu'on appelle une négociation de contenu, une grande majorité de documents XHTML sont servis en tant que text/html. Les recommandations du W3C le permettent - pour peu que nous suivions un certain nombre de règles de conduite - pour que nous puissions commencer à utiliser XHTML même si tous les navigateurs ne peuvent pas encore en tirer tous les avantages.

Le problème de cette approche, dont je me plains constamment, est que les documents sont alors décodés et interprétés en tant que HTML. Ceci signifie que le développeur peut faire des erreurs qui peuvent ne pas être remarquées dans la mesure où le document n'est pas géré selon les règles strictes imposées par XML. Certains disent que ce n'est pas un problème ; après tout le principal n'est-il pas que tout s'affiche comme prévu dans Internet Explorer ? Je ne suis pas d'accord, ce qui ne devrait pas surprendre tous ceux qui ont pu lire mes articles précédents. Aussi, bien que j'ai récemment promis de ne plus faire de vagues à ce propos, je voudrais terminer cet article par cette affirmation qui ne manquera pas de faire enrager un bon nombre de gens :

Il est acceptable de servir du XHTML en tant que text/html, à condition que le document satisfasse à toutes les règles de l'appendice C de la spécification XHTML 1.0, et que le document fonctionne aussi lorsqu'il est servi en tant que application/xhtml+xml.

La première condition n'est pas difficile à satisfaire. Pour ce qui est de la deuxième, il nous faudra par contre être très informés sur les réelles différences qui existent entre HTML et XHTML, sachant qu'il s'agit ici d'un peu plus que de simples minuscules ou de quelques barres obliques.

Fiche technique

À propos de l'auteur

Tommy Olsson travaille en Suède à Sundsvall comme webmestre au Swedish Companies Registration Office et donne gratuitement de son temps libre comme serviteur atitré d’Ida et d’Emil, ses deux chats préférés, en leur préparant à manger, en leur ouvrant les portes ou encore en leur servant de couverture chauffante. Surnomé « TOOLman », Tommy est aussi celui sans qui The Autistic Cuckoo, malheureusement désormais fermé, n’aurait jamais existé.

Article du même auteur

Articles similaires

Voici la liste des dix articles les plus récents en rapport avec cet article :

Intermédiaire

Web design

© 2001-2016 Pompage Magazine et les auteurs originaux - Hébergé chez Nursit.com ! - RSS / ATOM - About this site