1. Définition de la sémantique

La sémantique :

Respecter la sémantique HTML, c'est respecter l'utilisation des balises pour encadrer des contenus. HTML se compose d'une centaine de balises, chaque balise ayant un sens/une définition qui lui permet d'assurer un rôle : par exemple, une balise <p> pour un paragraphe de texte, une balise <h1> pour un titre ...

2. Sémantique et structure de page

Rédiger une page (et je parle bien de "rédiger") c'est enchaîner une suite de caractères ; pour ce qui est d'une page HTML il s'agit d'écrire un texte qui sera présenté à un visiteur, ce texte (point de vue code source) étant structuré par des balises.

Tout texte normalement constitué permet au lecteur de discerner différents types d'informations, par l'aspect du texte (ou par l'intonation lorsqu'il est lu) :

• le(s) titre(s) ;
• le(s) paragraphe(s) ;
• une éventuelle énumération d'objets ;
• pourquoi pas une présentation d'articles successifs ;
• accentuation sur des mots

Point de vue texte, cela se traduit par des balises, bien évidemment, et chaque balise a un sens différent. Pour quelle raison ?

Quelle est la différence entre :

<h1>NewsletTux est disponible !</h1>

et :

<p><font size="7">NewsletTux est disponible !</font></p>

Graphiquement, très peu de différence : la phrase sera affichée en gros. Sémantiquement, une très grosse différence : au niveau structure du document, la première formulation (balise <h1>) donne à la phrase un rôle de titre majeur (alors que la deuxième formulation grossit une phrase, mais ça n'en fait pas un titre pour autant : cela reste un paragraphe comme n'importe quel autre paragraphe).

3. Comment composer un document alors ?

Pour bien composer un document, il faut raisonner non pas en termes d'apparence graphique mais en termes de définition de chacun des objets le composant, c.à.d. raisonner en terme de structure du document. Utiliser une balise "titre" pour un titre, une balise "définition" pour une définition, etc.

C'est aussi la grosse erreur commise par ceux qui font les sites avec des tableaux, parce qu'un tableau ne permet pas de donner une structure de page conforme : le tableau (ex. tableau des horaires d'ouverture d'une boutique, liste d'articles en rayon...) est une structure qui sert à présenter des données tabulaires c.à.d. des données où toutes les lignes et/ou toutes les colonnes contiennent le même type d'information.

3.1. Un bon exemple :

	Lundi	Mardi	Mercredi	Jeudi	Vendredi
Matin	09h 00	08h 00	08h 00	08h 00	08h 00
Midi	12h 00	12h 00	12h 00	12h 00	12h 00
Après midi	14h 00	14h 00	14h 00	14h 00
Soir	18h 00	18h 00	18h 00	18h 00

Ce tableau montre des horaires, d'ouverture par exemple. Si on le lit ligne par ligne, on aura successivement les matins, les midis, les après midis et les soirs. Si on le lit colonne par colonne, on aura successivement pour chaque jour (Lundi, Mardi, Mercredi, Jeudi, Vendredi) le matin, le midi, l'après midi et le soir.

Quel que soit le sens de lecture, on rencontre toujours le même type d'information.

3.2. Un contre exemple :

menu 1	titre général	menu 2
	contenu de page
pied de page

Ici, si on lit ligne par ligne, on lira menu 1, titre général, menu 2, contenu de page, pied de page. (puisque les cellules sont fusionnées à gauche et à droite, elles comptent pour la première ligne).

Si on le lit en colonne, on lira menu1, pied de page, titre général, contenu de page, menu 2.

Autrement dit la compréhension de ce document dépend du sens de lecture du tableau, ce qui est contraire à l'esprit HTML : séparer la présentation du contenant.

3.3. Mais quel est l'enjeu réel ?

Graphiquement, aucun. Soyons clairs, une personne capable de "voir" mon tableau ci-dessus arrivera, graphiquement parlant, sans nul doute à lire les titres, les chapitres, et activer les menus. Seulement il y a des lecteurs qui ne comprennent pas ça ... Ces lecteurs soit ne disposent pas d'écrans (cas des mal-voyants ou des aveugles, qui utilisent un synthétiseur vocal pour lire les pages internet) soit ont un affichage très restreint (cas du WAP et des PDA, ou plus récemment les smartphones avec un écran plus petit), ou encore il s'agit des robots d'indexation du site !

Oui, lorsqu'un robot d'indexation (exemples concrets : MSNBot, Googlebot ...) cherche à indexer la page pour la référencer, que lit-il ? Le contenu, mais il lui sera bien plus facile d'indexer une page structurée avec des <h1> et <p> pour séparer les titres des paragraphes que des tableaux et des <font size="7"> ...

Il ne faut pas oublier que l'esprit du Web est l'accessibilité à tous, et que tout le monde n'est pas sur un écran ... De plus en plus se développent d'autres technologies, telles les PDA, le wap ou encore d'autres appareils capables d'aller sur internet, mais avec des fonctionnalités bien moindres que les écrans d'ordinateurs.

4. Sémantique et référencement

S'il est bien une question que bon nombre de gens se posent est le référencement de leur site. Cette étape consiste à l'inscrire dans un moteur de recherche avec des mots clés, le but du jeu étant d'apparaître le plus possible en début de résultats lorsqu'un visiteur soumet quelques mots-clés dans sa recherche sur le moteur.

4.1. Qu'en est-il de la sémantique dans le référencement ?

Les moteurs sont de plus en plus sensibles aux documents bien écrits. En effet, il est bien plus facile pour eux d'indexer un document composé de titre-paragraphe-titre-paragraphe qu'un document où ce ne sont que des tableaux dans des tableaux, eux-mêmes dans des tableaux ... Car la mise en page en tableaux pose l'inconvénient suivant : on est vite obligé de faire un tableau dans un tableau. (Le record que j'ai vu : 7 imbrications. Je n'ai jamais pu comprendre la structure du document...)

De même qu'il est plus facile de lire un texte si dans le code source on distingue bien les titres et paragraphes, il est plus facile de le référencer.

4.2. Sémantique vs référencement ?

Attention, tout de même : le référencement et la sémantique sont 2 notions qui ont tendance à s'opposer. En effet, lorsqu'on veut faire un lien vers une page (ou un site), on utilise cette structure :

<a href="http://www.newslettux.com/" title="NewsletTux">NewsletTux</a>

Un webmaster peu scrupuleux a vite fait, voulant abuser du référencement, de faire en plus ceci :

<a href="http://www.newslettux.com/" title="script de newsletter">Mailing-list</a>

Le même lien pointe vers la même page avec des données différentes. Point de vue référencement, la page qui contient ces deux liens "vote" pour l'adresse web avec des mots-clés différents, donc un gain de référencement : 2 liens, on supposera que le moteur de recherche indexera l'adresse de la page pointée deux fois avec les 2 mots clés. Point de vue sémantique par contre, on a une perte de sémantique : 2 lignes portant des indications différentes pointent sur la même page. La page ainsi visée parle-t-elle de "newslettux" ou bien de "script de newsletter" ?

Ainsi, il faut trouver un compromis entre sémantique et référencement... Sachant que ce sont en quelque sorte deux extrêmes et que trop tirer vers l'un minimisera l'autre.

5. Trop de sémantique tue la sémantique !

Trop miser sur la sémantique la tue : en effet, trop structurer un document peut lui faire perdre sa structure ...

Prenons un exemple concret : une galerie d'images avec, pour chacune, une mini description : taille, dimensions, nombre de visites. Doit-on considérer qu'il s'agit d'un simple listing d'images ? ou bien qu'il existe un lien entre les images et leur "description" ?

Voici un exemple de code source pour chacun des 2 cas :

<ul>
	<li>
		<ul>
			<li><img src="photo1.jpg" alt="" width="" height=""></li>
			<li>taille : 3 Mo. Dim. : 1280x1024px. Visites : 30 fois.</li>
		</ul>
	</li>

	<li>
		<ul>
			<li><img src="photo2.jpg" alt="" width="" height=""></li>
			<li>taille : 1.5 Mo. Dim. : 800x600px. Visites : 40 fois.</li>
		</ul>
	</li>
</ul>

 

<dl>
	<dt><img src="photo1.jpg" alt="" width="" height=""></dt>
	<dd>taille : 3 Mo. Dim. : 1280x1024px. Visites : 30 fois.</dd>
</dl>

<dl>
	<dt><img src="photo2.jpg" alt="" width="" height=""></l</dt>
	<dd>taille : 1.5 Mo. Dim. : 800x600px. Visites : 40 fois.</dd>
</dl>

Dans le premier cas, une suite d'éléments de liste (ul/li). Dans le second cas, des balises de définition. Quel que soit le choix du webmaster, on peut arriver à un rendu intéressant. Il ne faut pas trop se creuser la tête à vouloir "sur-sémantiser" (ça se dit ?) une page. Parfois le choix le plus simple est le mieux ...

5.1. Avantages et inconvénients.

Une liste (ul/li) est-elle vraiment adaptée à ce schéma ? Bien que, sémantiquement, elle représente une énumérations d'objets, le fait que chaque photo ne soit pas simplement énumérée mais accompagnée d'un court texte, l'utilisation de listes est moins adaptée que les listes de définitions.

On aurait pu tout aussi bien dire :

<div>
	<p><img src="photo1.jpg" alt="" width="" height=""></p>
	<p>taille : 3 Mo. Dim. : 1280x1024px. Visites : 30 fois.</p>
</div>

<div>
	<p><img src="photo2.jpg" alt="" width="" height=""></p>
	<p>taille : 1.5 Mo. Dim. : 800x600px. Visites : 40 fois.</p>
</div>

Mais l'utilisation d'un <div> fait perdre toute notion de structure de galerie photo ... Autre exemple : j'ai vu un site qui, voulant éviter un tableau de données tabulaires (sic !) utilisait des <div> avec des flottants... Triste pour la sémantique, sous prétexte de vouloir dire "je n'utilise pas de tableau sur mon site", ce webmaster a perdu une certaine logique dans l'organisation de ses données.

6. Sémantique et doctypes

La sémantique et le doctype sont deux choses tout à fait indépendantes, l'un étant à propos de la sagacité quant à l'utilisation des balises et l'autre le moyen d'écrire ces balises, de les enchaîner ou de les imbriquer. Qu'on soit clair sur un point : le passage d'un doctype HTML à XHTML n'implique pas une plus grande sémantique. XHTML n'est pas "mieux fait" sémantiquement qu'HTML, puisque les balises et la philosophie en XHTML existaient déjà en HTML.

De même, le Doctype n'influe pas sur le référencement : qu'une page soit en HTML 4.01 Strict, XHTML 1.0 ou même HTML 5, cela peut être tout aussi bien référencé. L'important est de choisir un Doctype et d'appliquer la "grammaire" en cohérence.