Tuto : strong, em, b, i

Mon rêve en tant que Strasbourgeois ? Boire une bière avec Raphael Goetter, bien sûr (quelle question !).

Quelques remarques:

"Il est à noter qu'aucune de ces balises n'est considérée comme dépréciée ou obsolète dans les spécifications HTML4.01. Les balises <i> et <b> n'y apparaissent tout simplement pas."
Lapsus ? Expression maladroite ? <i> et <b> figurent bien sûr dans HTML4.01 ;)

"Là où le soucis et la confusion commencent, c'est que les navigateurs ont en règle générale adopté un rendu italique pour la balise <em> et une mise en gras pour la balise <strong>. Or, ce choix conventionnel des navigateurs ne repose sur aucune règle établie : dans le futur, ils pourraient très bien décider d'afficher <strong> en taille de caractère agrandie ou <em> avec un retrait à gauche, ou que sais-je encore."
En fait, ceci n'est possible (mais improbable) qu'en HTML et XHTML1.x: à l'avenir, les styles par défaut de l'agent utilisateur sont normalisés en XHTML2.0. Voir www.w3.org/TR/xhtml2/xhtm...

"Il est possible d'obtenir une bien plus grande diversité d'effets de police en utilisant les feuilles de style."

Disons franchement que la spécification HTML4.01 est tout à fait abusive sur ce point ;) En effet, styler un <i> ou un <span> revient exactement au même, et offre exactement les mêmes possibilités.

"L'emploi de la balise neutre <span> peut paraître incongru au premier abord. En effet, cela implique un code relativement complexe, simplement pour éviter d'utiliser la simple balise <i> (...) Même si le résultat est plus lourd qu'en utilisant les balises <i> et <b>, il est préférable d'utiliser cette technique, à condition que l'objectif soit uniquement d'obtenir un effet visuel italique ou gras."

Voui.
Mais <i> et <b> correspondent aussi à des rendus par défaut hors CSS (navigateurs textes, navigateurs graphiques anciens auxquels la CSS est cachée entièrement...), ce qui n'est pas à négliger par souci de compatibilité.
Ils sont d'autres part, comme tu l'as rappelé, parfaitement valides, non dépréciés et **ne sont pas déconseillés** par HTML4.01. Leur usage est... très précisément "découragés" :
"Bien qu'ils ne soient pas tous déconseillés, on décourage leur utilisation en faveur des feuilles de style."
Ce qui est, AMHA, une des plus remarquables aberrations d'HTML4.01. Autant les éléments dépréciés ont un statut clair, autant la série des éléments de présentation non dépréciés sont dans un statut totalement indéterminé et purement subjectif.

Pour ma part, en fait, je suis revenu sans hypocrisie à l'utilisation de <i> pour obtenir un rendu italique, lorsqu'une autre structure n'est pas appropriée, bien-sûr. L'outil existe et et ne pose aucun problème lorsqu'il est bien employé.

Le seul vrai problème posé par <i> et <b> ne réside finalement que dans les risques de confusion avec d'autres éléments, risques que tu as bien soulignés. Risques justement entretenus par HTML4.01 qui a décidé de ne pas déprécier ces éléments.

Merci d'avoir fait ce topo pour des personnes (comme moi) qui n'ont pas lu les spécifs.

@Laurent Denis > merci pour ces précisions toujours utiles. J'allais justement te poser cette question très bête : "pourquoi <i> et <b> sont-elles valides en XHTML strict ?". Tu y réponds en partie.

"Lapsus ? Expression maladroite ? <i> et <b> figurent bien sûr dans HTML4.01"
>> Très honnêtement, j'ai eu beau faire une recherche dans tous les sens sur les documents suivants et je n'y ai absolument pas trouvé l'ombre de ces balises :
www.la-grange.net/w3c/htm...
www.w3.org/TR/1999/REC-ht...

(recherches effectuée dans les documents : "<b>", "<i>", "italic/que", "bold/gras"... sans succès)

Pourtant il s'agit bien des spec HTML4.01

Le meilleur endroit pour trouver un élément HTML est l'index des éléments de la spécification :
- en français www.la-grange.net/w3c/htm...
- dans le version originale : www.w3.org/TR/1999/REC-ht...

Tu cites d'ailleurs toi-même dans ton article un extrait du passage concerné de la spécification :
www.la-grange.net/w3c/htm...
;)

Ah oui en effet.

Pour le <span class="italique"> je n'ai toujours pas compris l'intérêt. Il n'y a pas plus de séparation (vu que le class définit en fait la présentation et pas le sens), il y a plus de complexisté et moins de compatibilité.
Mettre le span n'a de réel intérêt que si la classe définit un rôle ou un sens, pas simplement une mise en forme déportée en CSS

En tout cas dire qu'il faut remplacer b par strong et i par em impliquerait que ces balises sont équivalentes. Si c'était effectivement le cas ça n'aurait aucun intérêt de les remplacer.

En rapport sur le sujet : blog.dreams4net.com/Stron...

@Ganf > je vois ce que tu veux dire et j'ai eu la même discussion avec ElMoustiko. Mais comme tu l'as vu, les specs sont relativement illogiques sur ce point puisque c'est ce qu'elles recommandent (utiliser span puis lui donner un aspect visuel).

"Mettre le span n'a de réel intérêt que si la classe définit un rôle ou un sens, pas simplement une mise en forme déportée en CSS"
>> Oui en théorie, je suis tout à fait d'accord.

Cependant, prenons le cas où je désire afficher une partie de texte en italique, sans lui donner de sens particulier, juste l'afficher en italique... mais sans employer de balise *déconseillée* par les specs, c'est à dire sans utiliser <i>.
La seule balise qui resterait neutre et qui permettrait cet affichage italique est bien, comme l'indique les specs, la balise <span>, non ?

@Ganf > merci pour le lien ;)

Raphael: Si tu veux afficher un morceau de texte en italique, c'est *forcément* que ce passage a un "sens" qui diffère du reste du texte, du moins pour toi. Dans ce cas, il te suffit d'utiliser le bon élément, de classer ce passage ou de l'identifier selon les situations.

@Bobe > OK, je partage effectivement ce point de vue. Cela doit forcément, quelque part, avoir du sens.

Mais si ce n'est ni une définition (<dfn>), ni une variable (<var>), ni une citation (<cite>), ni un échantillon (<samp>), ni un code (<code>), etc. ... ne doit-on pas se replier sur <span> si l'on veut éviter les <i> déconseillées par les specs ?

@Raphael: le problème que je soulevais ne venait pas du span lui même, je n'ai rien contre mais du span avec pour seule qualification un "met en italique".
Si tu veux afficher la date des comptes rendu en italique tu peux faire <span class="date-compte-rendu">. Tu définis un sens (ou un rôle) à ton élément. Charge après de le mettre en italique ou en couleur, comme tu veux. On définit bien le sens/rôle et la présentation de manière séparée
Ce qui me gênait c'était plus le <span class="italique"> qui lui n'apporte rien de plus qu'un <i>. Il apporte par contre beaucoup en moins (simplicité, maintenance, compatibilité).

Dans les déconseillé il ne faut pas regarder la technique (puisque "déconseillé" veut coté technique dire "autorisé") mais la philosophie et le but. La philsophie est celle d'une séparation stricte du contenu et de la présentation. Le but est d'utiliser le HTML uniquement pour marquer le sens et le rôle des différents contenus. Un <span class="date-compte-rendu"> respecte cette philosophie, pas un <span class="italique">.

Dernier point : bien que je sois globalement d'accord avec toi sur le fait que les <i> au milieu du HTML ne fassent pas partie de la philosophie du HTML strict, les <b> et <i> ne sont pas "deprecated" ni même déconseillés. Rien ne l'indique nulle part dans la recommandation (contrairement à <font> et les autres).

Pour l'anecdote : <big> <small> <i> <b> <bdo> <br> <pre> et <tt> sont tous des éléments uniquement de présentation qui ne sont pas dépréciés, pas déconseillés dans les recommandations et qui sont même utilisables dans le modèle strict. Après faudra pas me dire que le modèle strict est intélorant ;)

Dans la même continuité, peut-on de ce fait utiliser les balises SUP et SUB ? Elle passent tout aussi bien au validateur en XHTML1.x Strict que HTML4.01 ? Ou en partie le problème rejoint la variance d'utilisation des CSS. (Oui je rejoint un peu ... Voir même beaucoup l'avis de Ganf !).

groumphy: 2²=4, même si nous ne sommes pas en MathMl. 2<span class="puissance">2</span> ne sera pas égal à deux sans CSS.
N'oubliez pas que HTML est un langage essentiellement orienté vers une exploitation visuelle, et qu'on cherche en partie à lui faire faire ce pour quoi il n'a pas été conçu. Même si c'est pour la bonne cause.

@ Laurent Denis > Pourrais-tu expliquer ? Car je ne pense pas avoir tout compris ! Merci,

Groumphy >
Je pense que ce que Laurent Denis voulait dire, c'est que dans le cas précis de sup et sub, la mise en exposant/indice n'a pas qu'un sens visuel, mais aussi sémantique (en Maths, 2² != 22).
Or le document HTML doit être lisible même si la feuille CSS n'est pas disponible, et si tu utilises un span stylisé pour indiquer une mise en exposant, ton document risque, pour le coup, de perdre tout son sens si la CSS n'est pas disponible (navigateur texte, ...)

Donc dans les cas de sup et sub, il faut les utiliser plutôt que un span qu'on a stylisé, contrairement aux cas "mise en couleur" & co.

Birdman, juste un petit rectificatif (sinon, bravo pour avoir interprété pon commentaire un peu elliptique ;) ): <sup> et <sub> n'ont pas grand-chose de sémantique, au sens où ils permettraient d'exploiter a priori leur présence comme l'indice de quelque-chose de mathématique. 1^er, 2^e, etc. n'ont rien pour les différencier de 2², et n'ont rien de mathématique.

On parle bien ici de présentation, et non de sémantique, je crois. Mais c'est une présentation nécessaire et indispensable à l'intelligibilité du contenu. HTML n'est pas un langage abstrait indépendant du résultat affiché/écouté/imprimé. C'est une limite inhérente à sa définition historique. Ce n'est pas XML.

> HTML n'est pas un langage abstrait indépendant du résultat affiché/écouté/imprimé.

Argh, pourtant c'est justement pour être idépendant du rendu d'affichage qu'il a été créé ;)

> Ce n'est pas XML.

Il faut arrêter de voir le XML comme un langage magique. Le XML n'apporte *rien* de plus que le SGML au niveau de l'abstraction, de la modelisation ou de la sacro sainte sémantique. Et le SGML c'est justement la couche de base du HTML.

Ce n'est pas en mettant en XML que les langages gagnent de la sémantique, et ce n'est pas parce que la couche de base n'est pas XML que ça n'est pas abstrait/sémantique ou quoi que ce soit. Le XML c'est juste une syntaxe pour définir un méta langage, rien de plus, c'est "technique" au possible et de plus ça ne fait que simplifier ce qui existait déjà en SGML, ça n'apporte rien de réellement nouveau.


Effectivement il y a des balises qui sont un peu à l'intermédiaire entre le sens et la présentation, parce que HTML s'occupe des deux. Maintenant j'ai tendance à voir <sup> comme une manière de générer un exposant. Un exposant ça se gère aussi en dehors des mathématiques, par exemple pour Melle.
Si je veux juste obtenir "l'effet d'une mise en exposant" sans que ça en soit une, je n'utilise pas <sup>, mais des règles CSS.
Dans M^elle, mon <sup> a bien un sens réel lié aux habitude typographiques françaises, ce n'est pas là au même titre que la couleur de fond.

>> HTML n'est pas un langage abstrait indépendant du résultat affiché/écouté/imprimé.

>Argh, pourtant c'est justement pour être idépendant du rendu d'affichage qu'il a été créé

Mais il a grandit dans la plus totale dépendance envers le rendu d'affichage. Sinon, pourquoi tant de <tt>, de <pre> et autres www.google.com/search?hl=... (ne me dites pas qu'un paragraphe est une pure unité logique sur le Web actuel, fusse-t-il standard) ? Pourquoi des titres que rien ne lie à une section de contenu ? Pourquoi deux types de listes dont l'une n'a de spécificité que ses puces ? Pourquoi tant de haine, finalement, envers cette présentation dont on sent bien qu'on ne peut pas se détacher ?

Le "Ce n'est pas XML" n'était qu'un racourci renvoyant au fait que celui-ci permet de créer des langages abstraits si on en éprouve le besoin.

@ Birdman & Laurent Denis > Tout à fait, j'oublie souvent que le site doit être disponible AUSSI si la feuille de style n'est pas prise en compte.

Hmmm... Intéressant, la dépréciation des balises vers le XHTML entraine donc certaines possibilité assez bizarre.

Merci de vos précisions. :)