XHTML :: Comment réussir

Patrice Levesque
Édimestre
  • Français
  • English

XHTML :: Comment réussir

Préface

Dès son apparition début des années '90, le World Wide Web (WWW) a suscité l'intérêt des auteurs en herbe. Depuis, n'importe qui, n'importe quand, n'importe où, le plus commun des mortels avec un peu de débrouillardise peut publier sur le WWW. Cette facilité d'accès a permis à des milliards de pages web d'apparaître dans le réseau, n'importe comment.

Le HyperText Markup Language (HTML), le dialecte de base du web, est constitué d'une syntaxe et d'un vocabulaire très simples, qui pourtant, ne sont pas respectés dans plus de 90% des pages sur la toile. Pour plusieurs raisons, le navigateur web Internet Explorer favorise cette faible trempe de HTML et même encourage le status quo: il affiche sans message d'erreur des documents HTML mal formés, corrigeant comme bon lui semble les déficiences du document, entraînant les artistes web à un exercice de médiocrité (la faute revient aux autres navigateurs, tout fonctionne parfaitement sous IE...). Ce document vise principalement les auteurs qui utilisent le web comme medium et qui veulent savoir comment améliorer la qualité de leur travail tout en permettant une compatibilité totale au niveau du contenu - convenable au niveau de la présentation - avec les principaux fureteurs web.

À l'automne 2006, le navigateur web le plus avancé côté standards et conformité porte l'appellation de Mozilla Firefox (les autres projets Mozilla partagent le titre). Puisque tous les navigateurs devront un jour ou l'autre se soumettre aux standards aussi bien que ces derniers - et les dépasser -, ce document prend pour acquis ce qu'offrent Mozilla et Firefox et donne les moyens, autant que possible, de garder une compatibilité permettant une saine dégradation pour les fureteurs web encore incomplets.

Pourquoi choisir XHTML

Contenu et présentation

Première loi pour changer le monde: séparer le contenu de sa présentation. Le HTML de l'époque pré-CSS (milieu des années '90) forçait les auteurs à mélanger dans un même document couleurs, textes, images de fond, interlignes, figures, ainsi de suite. Bien que les fichiers CSS peuvent être liés à des documents HTML modernes, d'autres types de feuilles de style - comme XSL - sont conçus pour les langages XML comme XHTML alors autant bien s'y préparer.

L'expérience a démontré qu'une approche mêlant contenu et présentation comporte un nombre important de désavantages et de désagréments. Parmi ces irritants, ceux-ci semblent les plus importants:

Difficulté d'entretien
Contrairement aux médias conventionnels, une page web peut évoluer au gré de l'auteur. Lorsque le contenu n'est pas séparé de sa présentation, une simple modification telle que de changer la couleur de tous les liens devient cauchemardesque, il faut y aller un lien à la fois, une procédure pénible qui décidément demande beaucoup trop de temps.
Collaboration difficile
Parfois un auteur aimerait déléguer tous les aspects visuels à un graphiste. Si contenu et présentation résident dans un même fichier, le travail en parallèle devient une option dangereuse.
Réutilisation impossible
Pour un ensemble de pages, souvent une présentation similaire est désirée. Recopier les mêmes informations de présentation d'une page à l'autre demande un travail aliénant de moine. Simplement changer la couleur de fond de toutes les pages d'un ensemble devient une sinécure.
Trucs douteux
Afin de permettre un contrôle sur la présentation, des moyens jadis nécessaires ont été inventés, créant de fort mauvaises habitudes. Des idées géniales telles qu'installer des images vides de contenu (et mêmes transparentes) pour déplacer du texte. Utiliser des balises associées à un et un seul navigateur web. Utiliser des défauts des navigateurs à son avantage. Ces méthodes, bien qu'inventives et utiles en leur temps, sont devenues obsolètes et freinent l'élégance tant du côté structure que du côté cohérence. Il faut garder à l'esprit qu'un tour de passe-passe ne sert plus à rien quand des fonctionnalités sont conçues pour obtenir les mêmes résultats.
Public limité
En mélangeant contenu et présentation, on laisse de côté un public pour qui la présentation peut nuire. Une personne avec une vision déficiente peut vouloir consulter une page web mais ne pas pouvoir la lire car la taille de la police de caractères rend la page illisible pour lui. Un non-voyant doit s'ennuyer à mourir en écoutant une page web pourvue de dizaines de phrases uniquement reliées à ce qu'il ne verra jamais. Bref, bien que la majorité des gens peut sans embûche consulter le web, et que trop souvent le contenu passe au second rang derrière un tape-à-l'oeil criard, il reste que d'offrir à tous la possibilité d'obtenir une expérience de qualité démarque les grands auteurs.

Ainsi, en n'utilisant que les Cascading Style Sheets (CSS) pour la présentation, l'on règle ces problèmes tout en obtenant un meilleur contrôle sur les aspects visuels que celui que fournit le HTML.

XHTML donne de bonnes habitudes

Le eXtensible HyperText Markup Language (XHTML) a été officialisé en 2000. Il s'agit d'une reformulation du HTML sous les règles du eXtensible Markup Language (XML). Le XHTML demande un effort supplémentaire de rigueur, mais pour l'essentiel ressemble de très près au HTML. Un des très grands avantages de choisir d'utiliser le XHTML: puisque il est fondé sur le XML, tous les outils de traitement de XML deviennent d'un seul coup disponibles, permettant une variété impressionnante de manipulations permettant de reformater l'information concentrée dans le document. Ces transformations permettent d'envisager le partage du contenu avec des bases de données, des fichiers de configuration, des Web Services (SOAP, XML-RPC) et plein d'autres applications utilisant le XML.

Il devient donc beaucoup plus aisé de transformer un document destiné pour le web conventionnel vers d'autres médias tels que les téléphones cellulaires, les WebTV, l'imprimerie conventionnelle et les assistants numériques personnels. L'information n'est plus dépendante de son support.

Syntaxe du XHTML

Différences entre le HTML et le XHTML

Pour construire un document XHTML, il faut suivre à la lettre toutes les règles suivantes:

Squelette d'un document XHTML

Voici un exemple d'un document XHTML simple résumant quelques contraintes explicitées plus haut; les numéros de ligne renvoient vers la justification la plus appropriée pour cette ligne;

[1] <?xml version="1.0"?>
[2] <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
[3] <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
[4]   <head>
[5]     <title>Page 1</title>
[6]     <style type="text/css" media="screen">
[7]       <![CDATA[
[8]         p { color: black; background: white; }
[9]       ]]>
[10]     </style>
[11]   </head>
[12]   <body>
[13]     <p>Hello!</p>
[14]   </body>
[15] </html>

Il ne faut pas oublier d'envoyer ce document avec l'entête appropriée!

Contourner le passé

Depuis la chute de Netscape vers 1998, Internet Explorer domine le marché des navigateurs web de manière indiscutable. Microsoft, propriétaire d'Internet Explorer, n'a pas jugé bon d'améliorer son produit depuis: la bataille est déjà remportée. Dans l'ombre, plusieurs navigateurs ont poursuivi, eux, l'adoption des nouvelles techniques, devenant un à un plus conformes aux recommendations du W3C qu'Internet Explorer. Toutes ces améliorations au web n'ont pas été adoptées par IE; dans cette section seront décrits les moyens que peut employer un webmestre pour contourner les obsolescences particulières de IE tout en restant à la fine pointe des nouvelles possibilités offertes par le médium web. D'autres trucs pour les autres navigateurs s'y trouvent aussi, aucun fureteur ne respecte les recommendations à 100% (pas encore!)

Les images

Dans son trousseau, le webmestre des années '90 bénéficiait de deux formats de fichier d'image: Joint Experts Picture Group (JPEG) et Graphics Interchange Format (GIF). JPEG est un format de compression admettant de la perte de qualité qui permet de stocker des images comportant jusqu'à 16777216 (224) couleurs; idéal pour les photos. GIF, en revanche, ne supporte que 256 (28) couleurs, mais l'image ne subit aucune perte. Optionnellement, 1 « couleur » totalement transparente s'offre au graphiste: ainsi, les images ne doivent pas forcément adopter la forme rectangulaire qu'oblige le format JPEG.

Comment alors afficher une image avec compression sans perte comportant plus de 256 couleurs? Peut-on obtenir plus d'un canal alpha et ainsi profiter d'effets de transparence? Un nouveau format de fichier voit le jour au début des années '90.

Le format PNG

Devenu une recommendation du W3C en 1996, le format PNG détient un nombre impressionnant d'avantages vis-à-vis le format GIF. Ainsi, le nombre de couleurs n'est pas limité à 256 et le type d'encodage s'adapte au nombre réel de couleurs utilisées: jusqu'à 16777216. Tout comme le format GIF, le format PNG n'admet aucune perte. Il inclut également un canal alpha, permettant une transparence jusqu'à 256 degrés. Le format supporte aussi la notion de valeurs gamma, permettant une restitution fidèle des couleurs peu importe l'ordinateur et le moniteur. Autre point non-négligeable: la taille des fichiers est généralement réduite par-rapport au format GIF; il ne reste donc aucune bonne raison d'utiliser GIF puisque le format PNG surpasse toutes les spécifications du format GIF.

Internet Explorer supporte partiellement le format PNG; le canal alpha n'est pas spontanément appliqué. Il existe une méthode permettant à Internet Explorer versions 5.5 et ultérieures d'afficher correctement les images avec canal alpha; noter que cette méthode ne s'applique qu'aux balises <img/> et qu'aux directives CSS background[-image]. Il s'agit de la directive CSS non-officielle filter utilisant une commande propriétaire: AlphaImageLoader. Ainsi pour afficher une image au format PNG, au lieu d'utiliser:

<img src="foo.png" />

Internet Explorer nécessite:

<img src="blank.gif" style="width:100px; height: 64px; filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='foo.png', sizingMethod='scale');" />

Remarquer l'inclusion du « blank.gif » qui pointe vers un fichier GIF de dimension 1 pixel par 1 pixel, transparent. Il faut aussi spécifier la taille de l'image PNG via une directive CSS afin que l'image soit affichée à la bonne taille. Pour les fonds d'écran, au lieu d'utiliser:

<div style="background: url(foo.png);"></div>

Il suffit d'allonger la directive:

<div style="background: transparent; filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='foo.png', sizingMethod='scale');"></div>

Il existe différents scripts côté client qui modifient dynamiquement le contenu des balises <img> pour que de manière transparente les images au format PNG soient « enrobées » pour Internet Explorer; malheureusement pour des raisons inconnues ces scripts ne fonctionnent pas à tous les coups (!!!). D'y aller avec un script de détection côté serveur et donc d'envoyer un document différent pour IE semble beaucoup plus efficace.

Vérifier si, au-dessus de cette image de fond, les liens <a> fonctionnent toujours; certaines combinaisons de balises amènent Internet Explorer à un stade où les hyperliens ne fonctionnent plus.

Noter aussi que la combinaison background-color et background-image ne fonctionne pas correctement sous Internet Explorer: la recommendation insiste pour qu'une image semi-transparente laisse transparaître la couleur de fond, ce que IE laisse de côté en employant une syntaxe qui l'empêcherait de toute façon.

Les balises XHTML

Bien que le jeu de balises du XHTML ressemble de très près à celui du HTML, certaines différences doivent être remarquées et le comportement des navigateurs peut s'altérer légèrement selon le type de document utilisé. Cette section décrit les différences notables entre les deux ensembles.

<a>

La balise qui a ni plus ni moins créé le web pouvait jadis comporter un attribut target, permettant entre autres de forcer une nouvelle fenêtre à s'ouvrir pour le lien spécifié (en utilisant target="_blank"). L'attribut target n'existe plus pour la balise <a> en XHTML 1.1 et bien que forcer l'ouverture d'une autre fenêtre brise la navigation et irrite le visiteur qui peut décider de lui-même s'il veut ouvrir un lien dans une nouvelle fenêtre, un moyen existe, via ECMAScript, de provoquer le même effet.

Afin d'ouvrir une autre fenêtre par un clic sur un hyperlien, il suffit d'utiliser l'attribut onclick qui permettra aux gens utilisant une souris d'obtenir une nouvelle fenêtre tout en permettant aux utilisateurs de navigateurs non-graphiques et robots de pouvoir suivre le lien quand même.

Il suffit donc de remplacer <a href="http://example.com/" target="_blank"> par <a href="http://example.com/" onclick="window.open('http://example.com/', '_blank', ''); return false;">. Noter le return false; qui empêche le lien de remplacer la page courante si un clic a été effectué.

<body>

Balise obligatoire, en HTML elle est affichée comme comme le parent de tout le document, alors qu'en XHTML la balise <html> sert de parent de tout le document. Ainsi par exemple le navigateur peut - par défaut - ajouter des marges externes à l'élément <body> ou des marges internes à l'élément <html>.

Pour conserver la même apparence de page lors du passage de HTML à XHTML, ajouter à la feuille de style CSS appropriée:

html { margin: 0px; border: 0px; padding: 0px; }
body { margin: 0px; }

Noter que Internet Explorer affiche la barre de défilement pour l'élément <body>, ce qui implique qu'un <body> n'utilisant pas tout l'espace du navigateur ne crée pas nécessairement l'effet voulu.

<fieldset>

Cette balise permet de regrouper des éléments d'un formulaire <form> de manière structurellement cohérente.

Le navigateur Opera ne permet pas de retirer la bordure autour des éléments <fieldset>. Pour enlever l'effet de bordure, utiliser une couleur de bordure équivalente à la couleur de fond de l'élément parent.

<map>

Afin de permettre des images sur lesquelles différentes parties peuvent être sélectionnées (une carte routière par exemple), les éléments <map> et <area> existaient déjà à l'époque de HTML 3.2. Le code ressemble à ceci:

<img src="image.png" alt="Canada" usemap="#mymap" width="50" height="100" />
<map id="mymap">
  <area href="section1.html" alt="Route 20" shape="rect" coords="0,0,49,49" />
  <area href="section2.html" alt="Route 35" shape="rect" coords="0,49,49,99" />
</map>

Un navigateur n'affichant pas les images propose une liste comprenant le contenu des attributs alt, alors l'accessibilité reste possible.

Avec l'arrivée de XHTML 1.1, l'attribut usemap de la balise <img/> n'accepte plus d'URI. Il faut simplement écrire le nom de l'ancre de destination, sans le préfixe « # ». Comme on devait s'y attendre, cette nouvelle méthode ne fonctionne que sur peu de navigateurs. De rétrograder à XHTML 1.0 pour les pages comprenant des attributs usemap semble pour l'instant une sage décision.

<object>

Supposons qu'un nouveau format graphique surgisse (appelons-le xyz), plein de promesses, et qu'un seul navigateur le supporte. Pour l'utiliser sur un ensemble de pages web, un script détecte le navigateur et envoie une image d'un format plus commun aux navigateurs qui ne supportent pas le format xyz. Un second navigateur, quelques semaines plus tard, supporte le format xyz. Il faudra changer toutes les pages web afin de détecter le second fureteur. Absurde. La balise <object> sert à pallier cela en proposant des alternatives - même un texte; on peut ainsi chaîner une liste d'« objets » et le navigateur, suivant l'ordre proposé, choisit le premier « objet » qu'il supporte et l'affiche. Une bien belle idée.

Internet Explorer adhère à une autre ligne de pensée lorsqu'il s'agit de la balise <object>. Pour ce navigateur, toutes les balises <object> demandent que l'usager accepte les scripts ActiveX, que ces objets utilisent cette technologie ou non. De plus, aveuglément, Internet Explorer affiche toutes les alternatives possibles, encadre systématiquement les <object> de barres de défilement et d'une bordure. Comment s'en sortir? Si nous savons que l'usager n'a pas configuré son navigateur de manière à refuser les ActiveX, nous pouvons ajouter par exemple un script à la page web pour retirer barres de défilement et bordures:

function objectfix () {
  var objects = document.getElementsByTagName ('object');
  for (i = 0; i < objects.length; i++) {
    var o = objects[i];
    if (((o.type == "image/jpeg") ||
    (o.type == "image/gif") ||
    (o.type == "image/png"))) {
      o.body.style.border = 'none';
      o.body.style.margin = '0';
      o.body.style.padding = '0';
      o.body.style.overflow = 'hidden';
    };
  };
};

window.onload = objectfix();

Pour empêcher IE d'afficher toutes les alternatives, il faut encore une fois faire appel à de la détection de navigateur. Rien n'indique que ce bogue va se réparer.

<script>

Permettant d'épicer la page web de code ECMAScript, ou encore Javascript/JScript, cette balise ne doit plus utiliser les méthodes désuettes telles que document.write pour transformer une page web. Puisque le document XML constitue un arbre d'information, il s'agit - en utilisant le modèle DOM, d'ajouter des noeuds au document.

La plupart des navigateurs n'acceptent pas la forme courte de la balise <script>. Ainsi <script type="text/javascript" src="foo.js" /> ne fonctionnera pas, mais <script type="text/javascript" src="foo.js"></script> passera très bien. D'un point de vue XML, les deux formes devraient se valoir, mais il semble que bien des programmeurs de fureteurs n'aient pas encore saisi l'idée.

Le navigateur Opera, lorsque en mode XHTML, ne reconnaît pas cette balise avant la version 7.5; il faut présenter un autre mode (typiquement text/html) à Opera s'il y a besoin de scripter des pages.

Les feuilles de style (CSS)

L'avènement des Cascading Style Sheets (CSS) (ou feuilles de style) à la fin des années '90 a permis une première séparation entre le contenu et sa présentation. À l'aide de directives simples (purement déclaratives), il devenait alors possible de changer la présentation d'un document HTML sans toucher à ce dernier.

Le modèle bloc

Dès la première version, CSS1, l'on pouvait déjà, pour tout élément bloc, lui associer une marge externe, une bordure, une marge interne, une largeur et une hauteur.

Internet Explorer (en mode « compatible », le mode « strict » de IE6 règle enfin le problème) diffère des autres navigateurs par sa compréhension des termes largeur (width) et hauteur (height); pour IE la largeur et la hauteur comprennent la bordure ainsi que la marge interne, alors que la recommendation explicite bien que ces trois identités ne se superposent pas.

Pour rendre le modèle bloc compatible avec tous les navigateurs, la solution consiste à insérer un second bloc dans le bloc problématique et d'y ajouter marges internes et bordures. Inélégant car demande de changer le code XHTML (qui ne devrait jamais servir à présenter). Une autre solution demande d'écrire du code CSS fautif pour utiliser les bogues du parseur CSS de IE. Encore moins joli.

Positionnement fixe

Un des grands apports de CSS2 aux graphistes: spécifier exactement la position des éléments. Que l'on veuille placer les items pixel par pixel, les déplacer relativement à leur endroit calculé ou utiliser la méthode traditionnelle, chacun trouve semelle à son soulier. Il existe même une directive qui permet de positionner un élément sur l'écran, de manière fixée, peu importe le défilement du document.

La directive CSS2 position: fixed est correctement interpretée par la plupart des navigateurs; Internet Explorer ne la lit pas encore. Afin d'obtenir le même effet, il faut employer du code javascript - ce dernier vérifie régulièrement si la page a défilé et en ce cas le javascript replace l'élément à sa position originale. Par exemple, ce code replace l'élément dont l'id vaut « menu » au haut de l'écran. Il suffit d'appeller la fonction init() au chargement de la page:

var menu; var theTop = 0; var old = theTop;
function init() {
  menu = document.getElementById('menu');
  movemenu();
};
function movemenu() {
  if (window.innerHeight) {
    pos = window.pageYOffset
  }
  else if (document.documentElement && document.documentElement.scrollTop) {
    pos = document.documentElement.scrollTop
  }
  else if (document.body) {
    pos = document.body.scrollTop
  }
  if (pos < theTop) pos = theTop;
  else pos += 0;
  if (pos == old) {
    menu.style.top = pos;
  }
  old = pos;
  temp = setTimeout('movemenu()',100);
}

Une autre méthode, qui pourrait fonctionner dans certains cas, est décrite par Simon Jessey.

Conclusion

Microsoft a acquis la plus grande part de marché des navigateurs web via son canal de distribution de système d'exploitation Windows. Bien que cette politique d'intégration de navigateur web permette à tous ceux qui installent Windows d'obtenir un fureteur web sans effort supplémentaire, il écrase en quelque sorte la compétition des autres aspirants peut-être plus adaptés et clairement plus avancés. Des navigateurs web de grande qualité tels que Mozilla (et ses dérivés Netscape, Firebird Firefox, Galeon, Epiphany, K-Meleon, Camino, ...), Opera, Konqueror (et son cousin Safari issu d'Apple) attendent humblement leur essai, intégrant une à une les nouvelles recommendations du W3C. Le web évolue et Internet Explorer refuse obstinément de suivre le courant.

Dans le monde de l'informatique, le progrès avance à pas gigantesques et les applications qui résistent au changement ne subsistent pas d'ordinaire longtemps; Internet Explorer a accumulé un décalage considérable - ne laissons pas le WWW s'ankyloser devant tant de belles possibilités.

Un noble essai de la part de Dean Edwards pour contourner les défaillances d'Internet Explorer s'appelle IE7. Son module de compatibilité offre beaucoup de solutions aux problèmes décrits plus haut. Souhaitons que son bon travail se poursuive, permettant à de plus en plus de programmeurs web de s'approprier les standards et de nettoyer ce web écrit de manière si bâclée.

Tout commentaire, correctif ou suggestion peut être envoyé par ce formulaire. Il me fera grand plasir d'améliorer ce document pour le bien de la communauté.

XHTML:: Comment réussir

Création : 30 août 2003
Villeray
N 45° 33′ W 73° 36′

XHTML:: Comment réussir

Dernière mise à jour : 21 novembre 2006,
Villeray,
N 45° 33′ W 73° 36′