All pastes #737284 Raw Edit

Anonymous

public text v1 · immutable
·published 2007-10-15 09:28 UTC
rendered paste body
Sémantique HTML et bonnes pratiques

Cela fait plusieurs années que je lis un peu partout que le web 2.0 a marqué l'avènement du règne du contenu. L'auteur du site publie un contenu auquel les visiteurs réagissent par des commentaires, des billets liés, du bookmarking social, ou de la mise en avant sur les Digg like. Si la qualité des contenus mis en avant laisse souvent à désirer – il vaut mieux ne pas trop demander aux gens de réfléchir – le système marche bon an mal an depuis trois ou quatre ans. Malheureusement, si on parle beaucoup du contenu, on a un peu tendance à oublier la structure, y compris dans le monde des développeurs web, en dehors du milieu un peu trop restreint des adeptes du web sémantique. Contrairement à ce que j'ai longtemps cru, le (X)HTML n'est pas seulement un traitement de textes destiné à mettre du contenu en forme ; par la nature même de chacun de ses éléments, <strong>il donne du sens à la structure de la page</strong>. C'est pour cette raison qu'on parlera de <strong>sémantique structurelle</strong>.

<h4>La sémantique structurelle</h4>

<blockquote>
  
<p>Sémantique : Etude du langage et des signes linguistiques (mots, expressions, phrases) du point de vue du sens (du grec "semantikos", "qui signifie"). Il s'agit de savoir comment un signe tel que "X" se charge de sens, comment il est utilisé par l'énonciateur, puis perçu et interprété par le co-énonciateur. La sémantique analyse le sens des mots et le processus par lequel ils se chargent de ce sens.</p>
<p>L'étude de la sémantique peut être philosophique (sémantique pure) ou linguistique (sémantique descriptive ou théorique). On y ajoute généralement une troisième approche, la sémantique générative.</p>
<p>Source : Académie Française.</p>

</blockquote>

<blockquote>

  <p>Structure :</p> 
  <p>Sens 1 Disposition, agencement des différents éléments d'un ensemble. Ex La structure d'un atome. Synonyme agencement.</p>
  <p>Sens 2 Organisation des éléments d'un système qui lui donne sa cohérence, sa forme et sa rigidité. Ex La structure d'une entreprise.</p>
  <p>Sens 3 Ensemble, système organisé dont les éléments sont dépendants et solidaires entre eux. Ex Une structure municipale.</p>
  <p>Source : Académie Française.</p>

</blockquote>

La sémantique structurelle est donc le fait de donner du sens à la page par sa structure. 

À quoi cela sert-il ? À rendre le contenu des ressources du web accessibles et utilisables par des programmes et des agents logiciels, incapables de saisir la sémantique du contenu.

<img src="http://fredericdevillamil.com/semantique-structure.png" class="centered" alt="Opération de compréhension du sens sur le web" />

Les outils de recherche et de data mining, s'ils sont capables de reconnaître des mots, des expressions ou d'identifier des schémas plus ou moins complexes (dans le sens de pattern, c'est à dire de formes), ne sont pas capables aujourd'hui de dégager du sens d'un texte ou d'une image. Il est cependant possible de transmettre du sens dans la structure de la page. Cela va de choses très simples, comme "ceci est un titre, ceci est un tableau", à des choses beaucoup plus complexes comme "ceci est une carte de visite dans laquelle se trouve mon nom, mon adresse et mon numéro de téléphone".

<h4>La sémantique dans le HTML</h4>

<cite>Une place pour chaque chose, et chaque chose à sa place</cite> disait Samuel Smiles dans Frugalité. Il en va ainsi des balises HTML, chacune ayant son sens propre au delà de la simple présentation. Dans cette partie, nous allons parler de comportement, de structure et de sens, en mettant tout cela en rapport avec la compréhension qu'en ont les outils de recherche.

<h5>Inline, block, et comportement à l'affichage</h5>

Même s'il est possible de le changer dans la feuille de style CSS, chaque balise HTML possède un comportement par défaut, dont les deux principaux sont inline et block, même si cette liste est loin d'être exhaustive.

Dans un cadre d'utilisation normale, la différence entre inline et block est simple :
<ul>
  <li>Les éléments de type block s'affichent les uns en dessous des autres, quelle que soit leur largeur. Les balises de type block les plus utilisées sont <code>div</code>, et <code>p</code>.</li>
  <li>Les éléments de type inline s'affichent les uns à côté des autres, et vont à la ligne à la fin du bloc dans lequel ils sont contenus. Des éléments de type inline  répandus sont <code>a</code>, <code>span</code>, <code>strong</code> ou <code>br</code>...</li>
</ul>

Il découle quelques règles simples – quand on a l'habitude – de ce type de comportement :
<ul>
  <li>Je peux imbriquer autant d'éléments de type block les uns dans les autres. Pour comprendre ce que cela donne, imaginez-vous des poupées russes les unes dans les autres, c'est exactement ça. Je peux donc mettre des <code>p</code> dans des <code>div</code> (et vice versa).</li>
  <li>Je peux imbriquer autant d'éléments de type inline les uns dans les autres. Je peux décider de mettre un <code>a</code> en valeur avec un <code>em</code>.</li>
  <li>Je peux imbriquer des éléments inline dans un block. Un <code>p</code> peut contenir autant de <code>a</code> que je le souhaite.</li>
  <li>Je ne peux en revanche pas placer d'éléments block dans un élément inline. Je ne peux donc pas mettre de <code>p</code> dans un <code>a</code> pour profiter de l'affichage de mon lien en block. Je peux en revanche modifier le comportement de mon lien en CSS avec la propriété <code>display: block</code>.</li>
</ul>

Ces règles sont censées être connues de tout développeur HTML, je me permet cependant de les rappeler car elles participent au sens donné à ma structure.

<h5>Structure d'une page</h5>

Quand vous prenez un livre, vous vous attendez à y retrouver une certaine structure logique : à moins de prendre un manga, jamais vous ne verriez la quatrième de couverture à la place de la première, et vous allez spontanément au début pour trouver les mentions légales et à la fin pour consulter la table des matières. Sinon, ça n'a pas de sens. C'est exactement pareil avec une page HTML. 

La structure réelle de la page HTML tient plus du corps humain : difficile d'imaginer une tête sans corps, difficile également d'imaginer un corps sans tête. C'est d'ailleurs pour cette raison que la page HTML est divisée en deux parties, <code>head</code> et <code>body</code>. Les informations contenues dans l'en-tête ne sont pas directement apparentes, mais conditionnent le comportement du corps, exactement comme dans la vie. Personne ne peut dire ce que vous avez dans la tête (à moins d'une bonne trépanation et encore ça ne montre pas tout), mais cela conditionne largement votre comportement corporel.

<h4>Les bonnes pratiques</h4>

<h5>Titres et tagline</h5>

Placez vos titres de pages, de parties et de sous-parties dans les balises <code>h1</code> à <code>h6</code>, toujours en fonction de l'importance du titre, puis, appliquez le style désiré à cette balise. 

La balise <code>h1</code> s'utilise pour le titre du site, et, pour des raisons de référencement, ne placez qu'une seule balise de ce type par page. Choisissez <code>h2</code> pour le titre de la page en cours, puis <code>h3</code>, <code>h4</code>, <code>h5</code> et <code>h6</code>.

Pendant très longtemps, j'ai placé ma tagline dans la balise <code>h2</code>. C'est en fait une erreur communément rencontrée, pénalisante du point de vue référencement, et incorrecte sémantiquement. Bien qu'appelée sous-titre, peut-être à tort, une tagline ne rentre pas dans la hiérarchie de la structure de la page.

Un exemple de bonne utilisation des titres trouvé sur une page personnelle des années 90 :

<typo:code lang="html">
<h1>Ah mon beau site</h1>
<p>Mon super site de la mort</p>
  <h2>Bienvenue sur mon super site</h2>
    <h3>Les photos</h3>
      <h4>Mes super potes</h4>
      <h4>Mon chat</h4>
    <h3>Mon livre d'or</h3>
      <h4>Signez mon livre d'or</h4>
      <h4>Les derniers messages</h4>
</typo:code>

Dans notre exemple, j'utilise <code>h3</code> et <code>h4</code> à plusieurs reprises. Ce n'est pas par hasard, puisque ces balises déterminent les en-têtes des grandes parties de mon contenu. Elles indiquent également une position dans l'ordre hiérarchique. La sémantique de mon HTML se retrouve dans le sens que le visiteur perçoit sur la page. Les outils de recherche et les êtres humains le perçoivent donc de la même manière.

<h5>Blocs et paragraphes</h5>

Les deux balises de type bloc les plus utilisées sont <code>div</code> et <code>p</code>.

Voyez <code>Div</code> comme un conteneur, une caisse de déménageur faite pour structurer la page, dans laquelle vous mettrez le véritable contenu : des paragraphes de texte, des images, des listes...

<code>p</code> délimite un paragraphe de texte, dans lequel on va pouvoir placer des éléments de type inline. Une imbrication de p dans une div est donc sémantiquement correcte, tandis que le contraire ne l'est pas. De même, on évitera de mettre directement le texte dans une div, même si ça valide et que cela semble mieux d'un point de vue esthétique. Il existe certainement un meilleur élément imbriquant. 

Le code suivant a du sens :
<typo:code lang="html">
<div>
  <p>Mon texte</p>
</div>
</typo:code>

Le code suivant n'en a pas :
<typo:code lang="html">
<p>
  <div>Mon texte</div>
</p>

<div>Mon texte</div>
</typo:code>

<h5>Listes et menus</h5>

Il existe à ce jour trois sortes de listes, chacune ayant une signification différente.
<ul>
  <li>Les listes non ordonnées de type <code>ul</code>.</li>
  <li>Les listes ordonnées de type <code>ol</code>.</li>
  <li>Les listes de définitions de type <code>dl</code>.</li>
</ul>

Les listes de type <code>ul</code> conviennent dans le cas de listes d'objets n'ayant pas de rapport ordonné entre eux. On les utilise très souvent pour les menus, qui ne sont finalement que des listes (imbriquées ou non) d'éléments. Leur utilisation dans ce cas précis est donc tout à fait correcte. 

<typo:code lang="html">
<ul>
  <li>Des pommes</li>
  <li>Des poires</li>
  <li>Des scoubidous</li>
</ul>
</typo:code>

Les listes de type <code>ol</code> sont à utiliser quand l'ordre dans lequel les items sont affichés revêt une importance quelconque, par exemple dans une liste de tâches à effectuer dans un ordre précis.

<typo:code lang="html">
<ol>
  <li>Épluchez les carottes et découpez les en petits dés.</li>
  <li>Faites fondre la graisse d'oie dans une poile à frire.</li>
  <li>Mettez les carottes à revenir avec des oignons émincés ou des échalottes.</li>
</ol>
</typo:code>

Les listes de type <code>dl</code> sont un peu spéciales, et s'utilisent afin d'afficher des termes et leur définition.
<typo:code lang="html">
<dl>
  <dt>Chien</dt>
  <dd>Animal à 4 pattes bien pratique quand on n'aime pas ce qu'on a dans son assiette.</dd>
  <dt>Chat</dt>
  <dd>Truc plein de poils qui fait un joli bruit quand on shoot dedans.</dd>
  <dt>Perroquet</dt>
  <dd>Animal bien pratique pour remplacer sa femme quand elle est partie.</dd>
</dl>
</typo:code>

Il n'existe pas à ce jour de balise d'en-tête spécifiques aux listes, comme il existe <code>title</code> pour les tableaux. Cela rend donc l'attribution d'un titre à une liste délicat d'un point de vue sémantique. Utiliser un <code>h</code> n'est pas correct, dans le sens où il n'est pas lié à la liste, pas plus que ne le serait l'utilisation de listes imbriquées. Le débat est ouvert depuis plusieurs années, et je ne suis pas certain qu'il soit clôt à ce jour.

<h5>Formulaires</h5>



------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

TODO :
– Formulaires
– Mise en valeur de texte 


Pour mettre un morceau de texte en valeur, on utilisera strong ou em (emphase), éventuellement stylés, à un p ou un span stylé. En effet, Google est sensible à la mise en valeur par strong et em. Là aussi il y a une question de sémantique structurelle.

em plus faible que strong

Et pour les éléments genre feuille de calcul ou tableau de données, un tableau. Car, contrairement à une croyance couramment répandue, utiliser des tableaux n'est pas mal si c'est fait à bon escient.