Toi comprendre moi ?

Openweb.eu.org > Articles  > Toi comprendre moi ?

Abstract

Validation, Déclaration de Type de Document : la grammaire d’un langage Web universel.

Article

Il est bizarre, ce titre… Pourtant, vous avez bien compris qu'il signifiait Me comprenez-vous ? L'idée à exprimer était simple. Mais si elle avait été plus compliquée et si l'auteur et le lecteur n'avaient pas eu les mêmes références culturelles, le message risquait de beaucoup moins bien passer, voire de donner lieu à de splendides quiproquos à faire pâlir les auteurs de théâtre de boulevard.

Lever l'ambiguïté

Pour le Web, dont il est parfois nécessaire de rappeler qu'il a été inventé pour partager l'information en faisant fi des ordinateurs et des programmes utilisés, bien se faire comprendre est un impératif. Et les langages du Web, comme HTML et XHTML, sont en fait des langues qui obéissent chacune à une grammaire. Il est possible de se faire comprendre en s'exprimant de façon imprécise, mais on prend un risque, car le lecteur doit interpréter, deviner le sens. Quand une chose est exprimée de façon ambiguë, chacun peut interpréter le message à sa façon. C'est là tout l'intérêt des outils de validation comme le validator, qui rassure l'auteur sur la qualité de son langage (notez bien qu'on peut continuer à dire des âneries syntaxiquement correctes, comme il est tout à fait possible de fabriquer des gilets de sauvetage en béton armés estampillés ISO-9000 :-).

Ménager le passé, le présent et le futur

Le Web évolue et ses langages aussi. Alors qu'HTML s'améliore (HTML 3.2 et 4.01, XHTML 1.0 et 1.1), sa syntaxe change. Cela signifierait-il que du code HTML pourrait être conforme à la grammaire du moment, mais ne le serait plus quand une nouvelle version d'HTML apparaît ? Une telle hypothèse est absurde : devrait-on mettre à jour toutes les pages Web quand le W3C sort une nouvelle spécification Bien sûr que non. C'est pourquoi chaque document Web doit mentionner la « grammaire » à laquelle il se réfère. Dans le jargon du W3C, la grammaire est appelée DTD et cette référence est appelée DOCTYPE (pour Type de Document). C'est pour cette raison que le validateur, mentionné précédemment, exige un DOCTYPE pour valider un document, faute de quoi il ne sait pas à quelle grammaire se référer. Le DOCTYPE est nécessairement placé sur la première ligne du document, et concerne l'ensemble du document (remarque : pour les documents XHTML, il est aussi possible de disposer d'un prologue XML, qui serait alors juste avant le DOCTYPE).

Faux-plis contre amidonnage

Les navigateurs anciens (comprendre les versions 4.X de Netscape et d'IE) ont des comportements qui ne sont pas toujours très logiques, mais comparables entre eux, et non conformes aux spécifications du W3C. Alors que les navigateurs récents se veulent plus conformes aux standards, le dilemme était le suivant : faut-il reproduire les bogues des versions 4 (et rester compatible avec toutes les anciennes pages), ou bien faut-il respecter les standards et simplifier la création de nouvelles pages ? La réponse est (pardonnez-moi ce retour éclair à ma période « culottes courtes ») : « Les deux, mon Capitaine ». Pour les anciennes pages, utiliser le mode de compatibilité avec les bogues, aussi appelé Quirks (faux plis, en anglais). Pour les plus récentes, on utilisera le mode dit strict ou standard, qui respecte au plus près les normes du W3C (non, la notion d'amidonnage n'existe pas dans XHTML…). Mais comment le navigateur sait-il faire la différence ? Tout simplement en regardant le DOCTYPE. S'il n'y en a pas, le problème est vite résolu, c'est une page ancienne. Si c'est un DOCTYPE « strict », alors le navigateur est en mode strict. Il existe quantité de combinaisons possibles, entre les différentes versions de navigateurs et de DOCTYPE. Pour faire le point, Henri Sivonen propose un tableau récapitulatif à conserver soigneusement. Par ailleurs, le problème le plus fréquemment rencontré par les développeurs est lié à la volonté de rajouter un DOCTYPE à une page contenant un tableau dont les cellules contiennent à leur tour des morceaux d'images. Eric Meyer a écrit un article décrivant le problème et propose plusieurs solutions.

Conclusion

Que l'on parle français ou HTML, pour être bien compris, il est nécessaire de s'exprimer correctement. Si je m'exprime en soupe de balises (on dirait petit nègre en langage familier), les chances de me faire comprendre sont moindres. Evidemment, je peux vérifier auprès des gens autour de moi qu'ils comprennent bien mon charabia. C'est ce que fait un développeur Web qui produit du code non conforme, le teste dans MSIE et se réjouit qu'il soit visiblement bien interprété, malgré l'ambiguïté. Mais qui dit que d'autres personnes vont comprendre correctement ce que j'exprime mal ? Vais-je demander à tout le monde, autour de moi, s'ils comprennent bien ce que j'exprime mal ? Le développeur Web va-t-il tester son oeuvre dans tous les navigateurs ? C'est une possibilité, mais cela n'est sûrement pas la plus efficace. Pour être compris de façon universelle est sans ambiguïté, mieux vaut prendre l'habitude de s'exprimer correctement dans un langage simple (XHTML), avec un dictionnaire (le validateur) à portée de main.

Liens sur le sujet

À propos de cet article

  • Openweb.eu.org
  • Profil : Décideur, Expert, Gourou
  • Technologie : (X)HTML
  • Thème : Structure
  • Auteur :
  • Publié le :
  • Mise à jour : 19 mai 2008

Vos commentaires

modération a priori

Attention, votre message n’apparaîtra qu’après avoir été relu et approuvé.

Qui êtes-vous ?
Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom