Cette question a été posée dans l'une de mes classes de collège. Le professeur ne donne la réponse qu'il était plus descriptif, mais il semble que <b>et <i>sont assez explicites dans leur sens et est plus facile à saisir que <strong>et <em>.

Quels étaient les arguments officiels en faveur de la dépréciation de ces balises?

L'été dernier, j'ai lu l'intégralité de la spécification HTML5, ainsi que toutes les précédentes spécifications HTML (même celles qui ont été abandonnées), ainsi que toutes les spécifications CSS que j'ai pu trouver, ainsi que de nombreuses spécifications XML. Comme j'aime les documents hypertextes riches sur le plan sémantique, permettez-moi de vous donner une idée de la sémantique HTML pertinente en HTML5.

Avant HTML5

Avant HTML5, iet bétaient effectivement démodés. La raison en était qu’ils fonctionnaient essentiellement comme emet strong, respectivement, mais en mettant l’accent sur la présentation et non sur la sémantique (ce qui est mauvais).

En effet, cela isignifiait que le texte devait être en italique (il expliquait comment le texte devait être restitué à l'écran). Par contre, cela emsignifiait que le texte devait être mis en valeur (il en disait quelque chose sur la sémantique du texte).

Il y a une différence théorique importante ici. Si vous utilisez em, l'agent utilisateur (= browser) sait que le texte doit être mis en évidence. Il peut donc être affiché en italique si le document est affiché à l'écran (ou en majuscule si le formatage n'est pas possible, ou peut-être même en gras. l'utilisateur préfère cela), 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 à moi . (= pas le vôtre!)

n'ont pas le même sens.

La même différence s'applique à b(police en gras) et à strong(accentuation forte).

Un principe général de l'écriture numérique en général, et de la création d'hypertextes en particulier, est qu'il est nécessaire de séparer le contenu et le style. Dans la création hypertexte, cela signifie que le contenu doit être dans le fichier HTML et que le style doit être dans un fichier CSS (ou dans 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 d’en-têtes, de pieds de page, de listes, d’accent, de adresses, de zones de navigation, etc.). Cela présente de nombreux 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 de sauvegarder une adresse dans votre carnet d'adresses si seulement il pouvait la trouver et l'interpréter. De plus, vous savez peut-être que Microsoft Word peut créer et mettre à jour automatiquement une table des matières pour vous si vous marquez correctement vos en-têtes. .)
• Il est beaucoup plus facile de changer le style plus tard. (Si vous souhaitez modifier la couleur de tous les titres de troisième niveau de votre document de 860 pages, vous pouvez modifier une seule ligne dans la feuille de style. Si vous aviez mélangé le contenu et la présentation, vous auriez à parcourir le document entier manuellement. Et vous manqueriez probablement un titre ou deux, ce qui rendrait le document peu professionnel.)
• Vous pouvez utiliser différentes feuilles de style en fonction des circonstances (le document est-il affiché à l'écran ou imprimé sur papier?). Vous pouvez même laisser l’utilisateur final choisir lui-même le style. (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, iet bont été déconseillés parce qu’il s’agissait de balises HTML concernées par la présentation , ce qui est totalement faux.

En HTML5

En HTML5 iet bne sont plus obsolètes. Au lieu de cela, ils ont une signification sématique . Donc, ils concernent à présent la sémantique et non la présentation.

Comme auparavant, vous utilisiez empour souligner: "Le chat est à moi." Mais vous utilisez ipour presque tous les autres cas où vous utiliseriez l'italique dans un travail imprimé. Par exemple:

• Vous ibalisiez les désignations taxonomiques: "J'aime R. norvegicus ."
• Vous utilisez ipour marquer une phrase dans une langue différente de celle du texte environnant: À la carte
• Vous utilisez ipour marquer un mot lorsque vous parlez du mot lui-même: " boire est à la fois un nom et un verbe"

C'est également une bonne idée d'utiliser l' classattribut pour spécifier l'utilisation précise (également "microformat" et "microdonnées" de Google). Et, bien sûr, dans le second cas, vous devriez vraiment utiliser l' langattribut 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 qu'il citefallait utiliser pour baliser les noms de livres, films, opéras, peintures, etc.:

• Que pensez-vous de Nymphomane ?

Enfin, depuis longtemps, dfnest utilisé pour marquer 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 de 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 convaincre plus tôt. (Par exemple, vous pouvez demander à votre navigateur de dresser une liste de toutes les définitions dans le texte afin de vous assurer de les connaître toutes avant l’examen.)

En ce qui concerne strongand b, la spécification HTML5 indique que strongvous devez utiliser cette option pour baliser une partie importante du texte, comme un avertissement ou un mot très important dans une phrase. D'autre part, bdevrait être utilisé pour marquer les éléments qui doivent être faciles à trouver dans le texte, comme les mots-clés. J'utilise aussi bcomme en-tête dans les éléments de liste (LI).

Comme le dit Doval, ils ne sont pas obsolètes. Ils existent toujours, mais doivent être utilisés différemment de ceux utilisés avant HTML5.

Il s'agit de HTML sémantique. Il devrait décrire "ce que c'est", au lieu de quoi il devrait ressembler. 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 de la manière exacte d'interpréter.

Ceci est similaire à la raison pour laquelle vous ne devriez pas utiliser de noms de classe CSS comme "red" et utiliser des classes plus descriptives décrivant 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 montré en utilisant une couleur rouge au lieu d'un texte en gras). Ou bien un utilisateur daltonien peut avoir certains paramètres de navigateur spéciaux dans lesquels les couleurs sont remplacées par d'autres moyens.

La vraie histoire est que bet iont d' abord été rendu obsolète, dépréciée, maudit, et anatematized comme « présentation » dans divers projets de HTML5 ( au sens large de langue), mais ils ont réalisé que ces balises sont largement utilisés et ont également généré par de nombreux programmes de création. Au lieu de les autoriser simplement, ils ont développé de nouvelles définitions «sémantiques» artificielles pour pouvoir autoriser les éléments, tout en prétendant être stricts à propos du balisage «de présentation». Les nouvelles définitions varient d'un brouillon à l'autre et sont obscures: il est difficile de 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 résulte du suivi des modifications et de la lecture des brouillons et des discussions, souvent entre les lignes. Ils ne disent pas explicitement la cause. Je pense toujours que c'est l'histoire vraie.

La conclusion est la suivante: avancez. Il n'y a rien d'utile ici. Les éléments bet ifont la même chose que toujours: ils font la police en gras ou en italique, avec les mises en garde habituelles. Vous devez tenir compte de cette réalité, pas de la «sémantique» quasi-islamique qui n’a pas d’impact sur les navigateurs, les moteurs de recherche ou d’autres logiciels.

Les balises <b>et ont pour <i>origine les concepts de "gras" et "italique". Le problème est que ceux-ci peuvent être totalement dépourvus de sens pour certains agents utilisateurs. Par exemple, à quoi ressemble "italique" dans un lecteur d'écran pour un aveugle?

Les remplacer par <strong>et <em>supprimer le lien direct vers les concepts typographiques. Au lieu de cela, l'agent utilisateur peut les rendre comme bon lui semble.

Les balises <b>and <i>sont essentielles lorsque vous avez littéralement besoin de texte en "gras" ou en "italique".

Si vous écrivez une équation en HTML où un « je » en italique a un sens différent d'un «je» non en italique, il est important de pouvoir faire cette distinction.

Je pense à eux de la même façon que je pense <sup>ou <sub>balises - vous ne pouvez pas représenter correctement le sens d'une équation sans utiliser ces balises « apparence ».

L’approche la plus pure serait d’utiliser MathML ou TeX, mais la prise en charge du navigateur n’existe pas encore ...

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 que des instructions de bas niveau.

Le test classique est "les tags peuvent-ils être utilisés utilement dans un navigateur pour les aveugles".

Donc, pour un navigateur basé sur l’audio, le «i» pour l’italique est plutôt inutile, car vous ne pouvez pas parler en italique. Toutefois, la balise "em" a un sens, car un périphérique audio peut souligner une phrase de plusieurs façons: en augmentant la hauteur, en augmentant le volume ou en modifiant l’accent. Un rendu en braille pourrait mettre l’accent sur les points en modifiant l’espacement, la taille ou les vibrations.