Plan de site — Navigation
Blog & Blues Techniques et Standards de la Qualité Web

Accueil > weblog

- Lire le billet précédent - Lire le billet suivant -

<p></p> ou <p /> ? <br /> ou <br></br> ? Lisez les specs !

Par Laurent Denis, le 09 janvier 2005.

A force de lire les questions posées par tous ceux qui se lancent dans l'aventure exhaltante de leur première page XHTML, je vais finir par devenir totalement hébété à force de répéter ce conseil simple : lisez les spécifications. Je sais, vous allez me dire qu'elles ne sont pas aisées à lire, que ce ne sont pas des textes pédagogiques, etc. Mais il y a quelques passages incontournables, et tout particulièrement celui-ci : XHTML1.0, Appendice C. Règles de Compatibilité HTML.

Sa lecture est indispensable à toute personne soucieuse de délivrer des pages Web XHTML compatibles avec les navigateurs qui ne supportent pas le type de contenu spécifique à ce format (application/xhtml+xml), c'est à dire en particulier Internet Explorer, et plus généralement à tout ceux qui pratiqueront la syntaxe XHTML dans des documents text/html. C'est dire, finalement, que ce document concerne la très grande majorité des contenus XHTML qui sont traités en réalité comme s'il s'agissait d'un HTML un peu bizarre.

Il répond, entre-autre, à une série de questions fréquentes : vaut-il mieux écrire <p></p> ou <p /> ? Faut-il écrire <br /> ou <br></br> ? Puis-je écrire <script type="..." src="..." /> pour gagner quelques octets ?

Voyons ce que nous disent à ce sujet les directives de compatibilité :

C.2 Eléments vides

Inclure un espacement avant le / et >de fin des éléments vides, par exemple <br />, <hr /> et <img src="karen.jpg" alt="Karen" />. Utilisez également une syntaxe minale pour les éléments vides, par exemple <br />, comme syntaxe alternative de <br></br> qui est autorisé par XML, car cela donne des résultats inattendus dans certains agents utilisateurs.

C.3 Minimisation d'élément et contenu d'élément vide

Soit une occurrence vide d'un élément dont le modèle de contenu n'est pas EMPTY (par exemple, un titre ou un paragraphe vide), n'utilisez pas la forme minimisée (utilisez <p> </p> et non pas <p />).

Notons au passage qu'XML1.0 est tout aussi clair à ce sujet :

Les balises d'élement vide peuvent être utilisées pour tout élément qui n'a pas de contenu, qu'il ait été déclaré ou non avec le mot-clé EMPTY. A des fins d'interopérabilité, il est souhaitable d'utiliser la balise d'élément vide pour les éléments qui ont été déclarés EMPTY et de ne pas l'utiliser ailleurs.

Ajoutons qu'XML est totalement neutre sur la présence ou l'absence de l'espace précédant le caractère / :

Tags for Empty Elements
[44] EmptyElemTag ::= '< Name (S Attribute)* S? '/>' [WFC: Unique Att Spec]

Cet espace est simplement optionnel. On aura donc avantage à se rallier sans réserve à la bonne pratique consistant à l'utiliser pour éviter, par exemple, à NS4.x d'ignorer hr et br.

Autrement dit, les Définitions de types de Document (DTD) XHTML déclarent pour chaque élément s'il est du type vide (EMPTY) ou non. Par exemple :

<!--========== Horizontal Rule ===============-->

<!ELEMENT hr EMPTY>
<!ATTLIST hr
  %attrs;
  >
<!--=================== Paragraphs ===========-->

<!ELEMENT p %Inline;>
<!ATTLIST p
  %attrs;
  >

Les éléments qui ne sont pas marqués EMPTY, lorsqu'ils n'ont pas de contenu, ne doivent pas être écrits sous la forme <foo />. Les éléments dits EMPTY ne doivent pas être écrits sous la forme <foo></foo>.

Les éléments EMPTY sont, en XHTML1.0 strict (Les liens ci-dessous renvoient à la spécification HTML4.01) :

  • area (Définit une zone d'image cliquable) ;
  • base (Spécifie l'URI absolu servant de base à la résolution des chemins relatifs) ;
  • br (Force un saut de ligne) ;
  • col (Support des attributs de style pour les colonnes groupées dans un tableau) ;
  • hr (Ligne de séparation horizontale) ;
  • img (Inclusion d'une image) ;
  • input (Crée une commande de formulaire) ;
  • link (Définit un lien dans la section head du document) ;
  • meta (Définit une métadonnée dans la section head du document) ;
  • param (Initialise un object dans un élément object).

XHTML1.0 transitionnel y ajoute deux éléments dépréciés :

  • basefont (Etablit la taille de la police de caractères de base du document ; déprécié au profit de CSS) ;
  • isindex (Crée une commande de saisie de texte ; déprécié au profit de input).

XHTML1.0 frameset y ajoute :

  • frame (Définit le contenu et l'apparence d'un cadre).

Le respect de ces règles simples évitera aux navigateurs des erreurs qui peuvent rendre votre page inaccessible, comme par exemple le code suivant dans Opera à cause de la syntaxe impropre de l'élément script :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="fr" xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Test</title>
    <script type="text/javascript" src="script.js" />
  </head>
  <body>
    <p>Lorem ipsum...</p>
  </body>
</html>

Notez qu'un outil comme Tidy peut corriger automatiquement ce type d'entorse aux Directives de compatibilité.

Et puis, souvenez-vous, OpenWeb vous l'a déjà dit, tout ça... Il faut croire que ça n'était pas écrit assez gros smiley clin d'oeil

Trackbacks

Les trackbacks pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.

Commentaires

Bobe, le 09 janvier 2005

Précisons que ces recommandations ne concernent que les documents XHTML envoyés en tant que text/html (donc traités par un parseur SGML) et non ceux (rares) envoyés en tant que application/xhtml+xml (donc traités par un parseur XML).

Laurent Denis, le 09 janvier 2005

C'était écrit dans l'article smiley clin d'oeil Mais en effet, autant insister.

Philippe Worontzoff, le 09 janvier 2005

"Précisons que ces recommandations ne concernent que les documents XHTML envoyés en tant que text/html (donc traités par un parseur SGML)"

Pourtant, en SGML, la syntaxe <balise /> est fausse et, c'est (en grande partie) en ça que XHTML casse la compatibilité avec SGML non ?

Laurent Denis, le 09 janvier 2005

En effet (Sur l'interprétation théorique de la syntaxe du type <br /> en HTML, voir le classique hixie.ch/advocacy/xhtml : <br /> signifierait en fait <br>&gt; en HTML, le caractère / étant une fermeture de balise - "Null End Tag (NET) - et le caractère > un caractère littéral " )

Mais le principe des ces règles de compatibilité est de faire jouer le traitement d'erreur HTML de manière à obtenir un effet final satisfaisant... Autrement dit, ce n'est guère différent du traitement d'une bonne vieille "soupe HTML" invalide: le XHTML1.0 n'est rien d'autre que du HTML invalide, mais compatible pour ce qui est du résultat affiché.

dJoLembrouye, le 10 janvier 2005

Je n'y aurrait pas pensé et vous lire à de quoi embrouiller quelqu'un avec les idées claires. Je ne parle pas de l'auteur de l'article, mais des gens qui se posent des questions pareilles!

Le principe des balises ouvertes et fermées avant/après le contenu et des éléments empty est pourtant cohérent à la base, comme de suivre les recommandations sans trop se poser de questions, parce que celles-ci il faut vraiment les chercher! Je vous plainds de recevoir des assaults de ce type "j'tembrouille la tête avec des questions aussi inutiles qu'elles en ont l'air en plus". Et vous félicite de votre patience - et de votre blog très agréable au passage aussi.

Les commentaires pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.