<i>
En HTML sémantique il faut utiliser les balises ayant un sens et pas seulement un effet de style. C’est pour cela que la balise <b>
qui signifie gras est dépréciée en faveur de <strong>
qui signifie fort.
De même pour la balise italique <i>
que l’on remplace par <em>
qui signifie emphase. Cette nouvelle balise s’utilise quand on mets l’accent sur un mot et plus juste pour faire de l’italique.
Mais en français les règles typographiques veulent que certaines parties de textes soient en italique, comme par exemple les titres de livres ou encore les formules de latin. Si ces textes doivent être en italique on ne mets pas forcément l’accent dessus dans la phrase.
Il ne faut donc pas oublier la balise <i>
aussi rapidement. Il faut l’utiliser quand elle s’applique à une règle typographique et utiliser <em>
quand vraiment il s’agit d’une emphase.
(Oh et dans le même genre il y a aussi la pauvre balise big.)
est un développeur web vivant à Paris — Contact — Archives
Textes et contenus sous licence Creative Commons.
1 docLegi :
Sauf que dans le cas des règles typographiques que tu évoques, l’italique a donc également un sens, pas l’emphase certes, mais un sens néanmoins, pas juste un aspect « décoratif »… donc pour continuer à enrichir la sémantique, il faudrait chercher d’autres éléments et mettre
<i>
seulement en dernier recours.Le problème c’est qu’on se heurte assez vite aux limites des spécifications HTML. Par exemple pour le titre d’un livre, l’usage semble indiquer la balise
<cite>
. Celle-ci est définie comme suit dans la spécification :C’est assez vague, et d’ailleurs la différence entre une citation et une quotation semble difficile à établir.
Le problème c’est que l’idée d’intégrer la sémantique dans les documents web repose sur l’idée de les rendre plus accessibles, il faudrait donc que tout le monde soit d’accord sur le sens exact des éléments. Seulement, même dans les documents qui cherchent à définir les choses le plus exactement possible (les textes juridiques, au hasard?) il y a toujours de la place pour l’interprétation. De plus il y a énormément de types de documents sur le web, donc énormément de besoins sémantiques différents. D’où certains efforts comme les Microformats, Web Applications, et bien sûr l’idée d’un Web Sémantique. Mais plus on sera précis dans la sémantique plus le nombre d’éléments/de langages deviendra grand, et donc plus il sera complexe et coûteux de faire des pages web et des navigateurs.
Autre exemple : l’usage de l’italique pour un mot dans une autre langue. Sémantiquement, le plus intelligent serait un
<span lang="en">...</span>
, qu’on met en italique avec du CSS. Tant qu’il faut encore supporter IE 6 (« supporter » à la fois comme anglicisme (to support) et comme mot français ;)), il vaut mieux lui adjoindre une classe pour l’italique. D’ailleurs je crois que l’indication de changement de langue est également un sujet assez complexe.Bref un excellent exemple de toute la problématique de la sémantique en HTML…
docLegi, en passage à la veille d’un examen de sociologie politique…
P.S. J’ai pas pu indiquer le changement de langue justement, alors j’ai utilisé l’élément I
P.P.S. Je commente pas souvent sur ton blog (tes articles me font pas souvent réagir, il faut dire), mais la prévisualisation me manque toujours autant, surtout sur ce genre de commentaire bourré de code. J’espère que ça va sortir correctement.
2 Sunny :
Je suis d’accord avec toi. Donc à chaque fois que le français impose de l’italique il faut mettre un span avec une classe associée ? En résumé pour un livre anglais il faudrait faire :
Je suis en train de lire <span class="livre" class="lang-en" lang="en">The Catcher in the Rye</span>
.P.S : J’ai essayé d’installer deux plugins de prévisualisation mais les deux sont décevants, je continue de chercher promis.
3 docLegi :
Grave question, parce qu’au fond le
<span>
a encore moins de sens que le<i>
. C’est même son intérêt, d’être un élément lambda. J’essaierais vraiment au maximum de garder la sémantique. Même si ce n’est pas clair dans la spécification, je pense que le<cite>
est bel est bien fait pour les choses genre titres de livres. Donc:<cite lang="en">The Catcher in the Rye</cite>
(génial ce livre, d’ailleurs). Ou éventuellement avec une classe.docLegi, sortant d’un exam ce coup-ci :D
P.S. On pourrait essayer de le faire ensemble cet été si tu veux :D
P.P.S. t’as mis deux attributs class à ton exemple
4 Sunny :
Dans des scripts js qui insèrent tout un tas d’éléments beaucoup utilisent la balise
<b>
au lieu de<span>
parce qu’elle non plus n’a pas de sens sémantique et est plus courte.Pour moi
<cite>
est l’auteur d’une quote. WordPress dans son thème par défaut avait fait « fureur » en mettant cette balise autour des noms pour chaque commentaire d’articles.Au final c’est l’usage qui dicte le sens qu’apportent les balises. Sachant qu’en XHTML le nombre de balises est limité je pense qu’on devrait transformer l’usage de ces balises dépreciées au lieu de le jetter.
P.S : Ah oui je voulais dire
class="livre lang-en"
P.P.S : Ah et on devrait écrire
<acronym title="Post Scriptum" lang="la">P.S<acronym>
;)5 docLegi :
Catastrophe. Malheureusement tu as raison : c’est l’usage qui dicte le sens. Cela pose malheureusement de nombreux problèmes. Le but de la sémantique, ce n’est pas de faire joli, mais d’augmenter le nombre d’informations disponibles, ce qui permet notamment d’améliorer l’accessibilité. Mais si le sens des éléments n’est pas clair, difficile d’en tirer de l’information. Prenons un exemple: alors cet élément c’est une « citation » ou une « référence à une autre source », c’est souvent utilisé pour mentionner l’auteur ou le document dont est tiré une citation, mais ça peut aussi faire référence à un document en général, par exemple un livre (cf. les exemples dans la spécification).
Du coup c’est extrêmement difficile de créer de l’interoperabilité basée sur la sémantique si la sémantique n’est pas clairement définie, et l’usage ne définit jamais rien clairement. Du coup, j’ai certaines réticences à « transformer » l’usage des balises, en tout cas sans spécifications claires, de préférence à un niveau qui réunirait différents créateurs d’agents utilisateurs (navigateurs, screen readers, etc). Et c’est aussi la raison pour laquelle je critiquais le côté vague de la spécification. Preuve des problèmes que cela peut poser est assurément la confusion entre
<abbr>
et<acronym>
.P.S Tu as diablement raison, voilà qui est fait :D Mais c’est l’autre problème de la sémantique, ça demande potentiellement pas mal d’efforts.
6 docLegi :
Zut, problème à nouveau :D
7 Sunny :
Ahh la sémantique, toujours les mêmes soucis qui reviennent… (J’ai viré le pb de ton commentaire.)
8 michel v :
Juste une petite remarque d’homme qui fait des choses sexuelles avec Musca Domestica, mettre une classe par langue (comme « lang-en » l’implique) me semble contreproductif, puisqu’à la base la rêgle de l’italique s’applique à toutes les langues étrangères.
Pour éviter les désagréments et les prises de tête, j’utilise tout simplement
<i lang="en">
. Et tant pis pour la dépréciation et le purisme : c’est pas comme si XHTML 2.0 était là, à nos portes.9 docLegi :
Tu cherches la petite bête ?
Sinon je suis d’accord, l’élément
i
avec l’attributlang
me semble une bonne solution.10 Sporniket :
Les balises em et strong ne sont pas nouvelles, elle coexistent avec i et b depuis le début il me semblent (en tout cas on peut remonter jusqu’au HTML 2.0 sur le site du W3C).
Pour la difference entre citation et quotation, au niveau des balises s’entend : q et blockquote acceptent un attribut « cite » censé contenir un URI qui serait la source d’où est tirée l’extrait (chouette, j’ai appris quelque chose aujourd’hui)