Pourquoi les balises <b> et <i> sont-elles déconseillées?
Cette question a été soulevée dans l'une de mes classes universitaires. Le professeur a seulement répondu qu'il était plus descriptif, mais il semble que <b> et <i> sont plutôt explicites et sont plus faciles à taper que <strong> et <em>.
Quels étaient les arguments officiels pour la dépréciation de ces balises?
L'été dernier, j'ai lu la spécification HTML5 complète, et toutes les spécifications HTML précédentes (même celles abandonnées), et toutes les spécifications CSS que j'ai pu trouver, et beaucoup de spécifications XML. Comme j'aime les documents hypertextes sémantiquement riches, permettez-moi de vous donner l'idée derrière la sémantique HTML pertinente en HTML5.
Avant HTML5
Avant HTML5, i et b étaient en effet démodés. La raison en était qu'ils fonctionnaient essentiellement comme em et strong, respectivement, mais en mettant l'accent sur la présentation et non sur sémantique (ce qui est mauvais).
En effet, i signifiait que le texte devait être en italique (il disait quelque chose sur la façon dont le texte devait être affiché à l'écran). D'autre part, em signifiait que le texte devait être souligné (il disait quelque chose sur la sémantique du texte).
Il y a ici une différence théorique importante. Si vous utilisez em, l'agent utilisateur (= navigateur) sait que le texte doit être mis en évidence, il peut donc le rendre en italique si le document est affiché à l'écran (ou en majuscules si la mise en forme n'est pas possible, ou peut-être même en gras que l'utilisateur préfère), il peut le prononcer différemment si le document est parlé à l'utilisateur, etc.
Notez que l'accent est vraiment mis sur la sémantique. Par exemple, les phrases
- Le chat est à moi. (= pas le chien!)
- Le chat est le mien . (= pas le vôtre!)
n'ont pas la même signification.
La même différence s'applique à b (police en gras) et strong (accent fort).
Un principe général de l'écriture numérique en général, et de la création hypertexte en particulier, est que vous devez séparer le contenu et le style. En création hypertexte, cela signifie que le contenu doit être dans le fichier HTML et le style doit être dans un fichier CSS (ou un certain nombre de fichiers CSS). Un principe différent mais connexe est que le document doit être riche en sémantique (comme le balisage des en-têtes, des pieds de page, des listes, des accents, des adresses, des zones de navigation, etc.). Cela présente un certain nombre d'avantages:
- Il est beaucoup plus facile pour les programmes informatiques d'interpréter le document. Ces programmes incluent des navigateurs, des applications de synthèse vocale, des moteurs de recherche et des assistants numériques. (Par exemple, le navigateur peut vous permettre d'enregistrer une adresse dans votre carnet d'adresses, si seulement il peut la trouver et l'interpréter. En outre, vous savez peut-être que Microsoft Word peut créer et mettre à jour automatiquement une table des matières pour vous si vous balisez correctement vos en-têtes .)
- Il est beaucoup plus facile de changer le style plus tard. (Si vous souhaitez modifier la couleur de tous vos en-têtes de troisième niveau dans votre document de 860 pages, vous pouvez modifier une seule ligne dans la feuille de style. Si vous aviez un contenu et une présentation mixtes, vous devrez parcourir l'intégralité du document manuellement . Et vous manqueriez probablement un en-tête ou deux, ce qui rendrait le document non professionnel.)
- Vous pouvez utiliser différentes feuilles de style selon les circonstances (le document est-il affiché à l'écran ou imprimé sur du papier?). Vous pouvez même laisser l'utilisateur final choisir le style lui-même. (Mon site Web propose un certain nombre de feuilles de style alternatives. Dans IE et FF, vous les modifiez à l'aide du menu Affichage.)
Donc, en bref, i et b ont été déconseillés parce qu'ils étaient balises HTML préoccupés par présentation, ce qui est totalement faux.
En HTML5
En HTML5 i et b ne sont plus obsolètes. Au lieu de cela, on leur donne une signification sématique . Il s'agit donc désormais de sémantique et non de présentation.
Comme précédemment, vous utilisez em pour marquer l'accent: "Le chat est le mien." Mais vous utilisez i pour presque tous les autres cas où vous utiliseriez l'italique dans une œuvre imprimée. Par exemple:
- Vous utilisez
ipour baliser les désignations taxonomiques: "J'aime R. norvegicus ." - Vous utilisez
ipour baliser une phrase dans une langue différente par rapport au texte environnant: À la carte - Vous utilisez
ipour baliser un mot lorsque vous parlez du mot lui-même: " drink est à la fois un nom et un verbe"
C'est également une bonne idée d'utiliser l'attribut class pour spécifier l'utilisation précise (également "microformat" et "microdonnées" Google). Et, bien sûr, dans le deuxième cas, vous devez vraiment utiliser l'attribut lang pour spécifier la langue correcte. (Sinon, par exemple, un agent de synthèse vocale pourrait mal prononcer le texte.)
Il y a un an environ, la spécification HTML5 indiquait également que cite devait être utilisé pour baliser les noms de livres, films, opéras, peintures, etc.:
- Que pensez-vous de Nymphomane ?
Enfin, depuis longtemps, dfn est utilisé pour baliser l'instance de définition d'une phrase dans un texte (comme une définition mathématique ou la définition d'un terme):
- Un groupe est un ensemble X équipé d'une seule opération binaire * telle que ...
Ainsi, l'italique dans votre livre imprimé, qui peut signifier beaucoup de choses différentes, est représenté par quatre balises HTML5 différentes, ce qui est vraiment génial, car la sémantique est bonne, comme j'ai essayé de vous en convaincre plus tôt. (Par exemple, vous pouvez demander à votre navigateur de faire une liste de toutes les définitions dans le texte, afin de vous assurer de toutes les connaître avant l'examen.)
En se tournant vers strong et b, la spécification HTML5 dit que strong doit être utilisé pour baliser une partie importante du texte, comme un avertissement ou un élément très important pour- attraper Word dans une phrase. D'un autre côté, b doit être utilisé pour baliser les éléments qui doivent être faciles à trouver dans le texte, comme les mots clés. J'utilise également b comme en-têtes dans les éléments de liste (LI).
Comme le dit Doval, ils ne sont pas dépréciés. Ils existent toujours mais doivent être utilisés différemment de ce que beaucoup de gens utilisaient avant HTML5.
Il s'agit de HTML "sémantique". Il devrait décrire "ce que c'est", plutôt que son apparence. Le navigateur ou théoriquement tout autre support d'affichage (par exemple, une application de lecture pour les aveugles) devrait être en mesure de décider comment interpréter exactement.
C'est similaire pourquoi vous ne devriez pas utiliser de noms de classe CSS comme "rouge" et utiliser des classes plus descriptives qui décrivent l'idée fonctionnelle derrière l'utilisation d'une couleur différente ici. Vous pouvez décider plus tard que le vert est meilleur (et peut-être que tout ce qui est "fort" devrait être affiché en utilisant la couleur rouge au lieu du texte en gras). Ou un utilisateur daltonien peut avoir des paramètres de navigateur spéciaux où les couleurs sont remplacées par d'autres moyens.
L'histoire vraie est que b et i ont d'abord été obsolètes, obsolètes, maudits et anatématisés comme "présentationnels" dans divers brouillons HTML5 (en gros), mais ils ont ensuite réalisé que ces balises sont largement utilisé et également généré par de nombreux programmes de création. Au lieu de simplement les autoriser, ils ont développé pour eux de nouvelles définitions "sémantiques" artificielles, pour pouvoir autoriser les éléments tout en faisant semblant d'être strictes sur le balisage "de présentation". Les nouvelles définitions ont varié d'un projet à l'autre et sont obscures: vous pouvez difficilement trouver deux personnes qui les comprennent et les interprètent de la même manière.
Désolé, pas de références. La description ci-dessus est le résultat du suivi des modifications et de la lecture des ébauches et des discussions, souvent entre les lignes. Ils ne disent pas explicitement la cause. Je pense toujours que c'est la vraie histoire.
La conclusion est la suivante: passez à autre chose. Il n'y a rien d'utile ici. Les éléments b et i font la même chose qu'ils l'ont toujours fait: ils mettent la police en gras ou en italique, respectivement, avec les mises en garde habituelles. C'est la réalité que vous devez prendre en compte, pas la "sémantique" quasi-scolastique qui n'a aucun impact sur les navigateurs, les moteurs de recherche ou d'autres logiciels.
Le <b> et <i> les balises provenaient des concepts "gras" et "italique". Le problème est que ceux-ci peuvent être complètement dénués de sens pour certains agents utilisateurs. Par exemple, à quoi ressemble "italique" dans un lecteur d'écran pour une personne aveugle?
Les remplacer par <strong> et <em> a supprimé le lien direct vers les concepts typographiques. Au lieu de cela, l'agent utilisateur peut les rendre comme bon lui semble.
Le <b> et <i> les balises sont essentielles lorsque vous avez littéralement besoin de texte en "gras" ou "italique".
Si vous écrivez une équation en HTML où un "Je "a une signification différente d'un" je "non en italique, il est important de pouvoir faire cette distinction.
Je pense à eux de la même manière que je pense à <sup> ou <sub> tags - vous ne pouvez pas représenter correctement la signification d'une équation sans utiliser de telles balises "d'apparence".
L'approche puriste serait d'utiliser MathML ou TeX mais le support du navigateur n'est pas encore là ...
Les principes de conception qui sous-tendent les balises HTML sont qu'elles doivent être "sémantiques", c'est-à-dire qu'elles doivent indiquer le sens et l'intention plutôt qu'une instruction de bas niveau.
Le test classique est "les balises peuvent-elles être utilement utilisées dans un navigateur pour les aveugles".
Donc, pour un navigateur basé sur l'audio, le "i" pour l'italique est assez inutile car vous ne pouvez pas parler en italique. Cependant, la balise "em" est significative, car un périphérique audio peut souligner une phrase de plusieurs manières: en augmentant la hauteur, en augmentant le volume ou en changeant l'accent. Un moteur de rendu braille pourrait souligner en augmentant les points en changeant l'espacement, en changeant la taille ou en ajoutant des vibrations.