Dois-je utiliser la balise <i> pour les icônes au lieu de <span> ?

Question

Le code HTML de Facebook et le code HTML de Twitter Bootstrap (avant la version 3) utilisent tous deux l'attribut <i> pour afficher des icônes.

Cependant, à partir du Spécifications HTML5 :

L'élément I représente un intervalle de texte dans une voix ou une humeur alternative, ou autrement décalé par rapport à la prose normale, comme une désignation taxonomique une désignation taxonomique, un terme technique, une expression idiomatique d'une autre langue langue, une pensée, un nom de navire ou tout autre texte dont la présentation typographique dont la présentation typographique typique est en italique.

Pourquoi utilisent-ils <i> pour afficher des icônes ? N'est-ce pas une mauvaise pratique ? Ou est-ce que quelque chose m'échappe ?

J'utilise span pour afficher les icônes et cela semble fonctionner pour moi jusqu'à présent.

Mise à jour :

Bootstrap 3 utilise désormais span pour les icônes. Doc officiel

Answer 1

Pourquoi utilisent-ils <i> pour afficher des icônes ?

Parce que c'est le cas :

• Short
• i signifie "icône" (mais pas en HTML)

N'est-ce pas une mauvaise pratique ?

Une pratique horrible. C'est un triomphe de la performance sur la sémantique.

Answer 2

J'interviens un peu tard, mais je suis tombé sur cette page en y réfléchissant moi-même. Bien sûr, je ne sais pas comment Facebook ou Twitter l'ont justifié, mais voici ma propre réflexion pour ce qu'elle vaut.

En fin de compte, j'ai conclu que cette pratique n'est pas si peu sémantique (est-ce un mot ?). En fait, en dehors de la brièveté et de l'association sympathique de "i pour icône", je pense que c'est en fait le choix le plus sémantique pour une icône lorsqu'un simple <img> L'étiquette n'est pas pratique.

1. L'utilisation est conforme à la spécification.

Bien que ce ne soit pas ce que le W3 avait principalement à l'esprit, il me semble que la spécification officielle de l'initiative <i> pourrait accueillir une icône assez facilement. Après tout, le symbole de la flèche de réponse dit "répondre" d'une autre manière. Il exprime un terme technique qui peut être peu familier au lecteur et qui serait typiquement en italique. ("Chez Twitter, c'est ce que nous appelons un flèche de réponse .") Et c'est un terme d'un autre langage : un langage symbolique.

Si, au lieu du symbole de la flèche, Twitter a utilisé <i>shout out</i> ou <i>[Japanese character for reply]</i> (sur une page en anglais), ce qui serait conforme à la spécification. Alors pourquoi pas <i>[reply arrow]</i> ? (Je parle ici strictement de sémantique HTML, et non d'accessibilité, ce dont je parlerai plus tard).

Pour autant que je puisse voir, la seule partie de la spécification explicitement violée par l'utilisation de l'icône est la phrase "span of text" (lorsque la balise ne contient pas de texte également). Il est clair que le <i> est principalement destinée au texte, mais il s'agit d'un détail mineur par rapport à l'intention générale de la balise. La question importante pour cette balise n'est pas de savoir quel format de contenu elle contient, mais quelle est la signification de ce contenu.

C'est particulièrement vrai si l'on considère que la frontière entre "texte" et "icône" peut être presque inexistante sur les sites Web. Le texte peut ressembler davantage à une icône (comme dans l'exemple japonais) ou une icône peut ressembler à du texte (comme dans un bouton jpg qui dit "Envoyer" ou une photo de chat avec une légende superposée) ou le texte peut être remplacé ou amélioré par une image via CSS. Texte, image - qui s'en soucie ? Il s'agit de contenu. Tant que tout le monde - humains handicapés, navigateurs handicapés, robots des moteurs de recherche et autres machines de toutes sortes - peut comprendre cette signification, nous avons fait notre travail.

Le fait que les auteurs de la spécification n'aient pas pensé (ou choisi) de clarifier ce point ne doit pas nous empêcher de faire ce qui est logique et conforme à l'esprit de la balise. Le site <a> était à l'origine destinée à emmener l'utilisateur ailleurs, mais elle peut maintenant faire apparaître une lightbox. La belle affaire, n'est-ce pas ? Si quelqu'un avait trouvé le moyen de faire apparaître une lightbox en cas de clic avant que les spécifications ne le rattrapent, il aurait quand même dû utiliser la balise <a> et non une balise <span> même si elle n'était pas entièrement conforme à la définition actuelle - parce qu'elle s'en rapprochait le plus tout en restant conforme à l'esprit de la balise ("quelque chose va se produire lorsque vous cliquez ici"). Même chose pour <i> - quel que soit le type de chose que vous mettez dedans, ou quelle que soit la créativité avec laquelle vous l'utilisez, il exprime l'idée générale d'un terme alternatif ou à part.

2. Le site <i> étiquette ajoute une signification sémantique à un élément d'icône.

L'option alternative pour porter une classe d'icônes par elle-même est <span> qui n'a bien sûr aucune signification sémantique. Lorsqu'une machine demande à la <span> ce qu'il contient, il dit, "Je ne sais pas. Ça pourrait être n'importe quoi." Mais le <i> L'étiquette dit : "Je contient une façon différente de dire quelque chose que la façon habituelle, ou peut-être un terme peu familier". Ce n'est pas la même chose que "Je contient une icône", mais cela s'en rapproche beaucoup plus que <span> Je l'ai !

3. Finalement, c'est l'usage commun qui fait foi.

En plus de ce qui précède, il convient de considérer que les lecteurs automatiques (qu'il s'agisse d'un moteur de recherche, d'un lecteur d'écran ou autre) peuvent à tout moment commencer à tenir compte du fait que Facebook, Twitter et d'autres sites web utilisent la technologie de l'adresse IP. <i> pour les icônes. Ils ne se soucient pas tant de la spécification que d'extraire le sens du code par tous les moyens nécessaires. Ainsi, ils peuvent utiliser cette connaissance de l'usage courant pour simplement enregistrer que "il peut y avoir une icône ici" ou faire quelque chose de plus avancé comme déclencher une recherche dans le CSS pour un indice de signification, ou qui sait quoi. Ainsi, si vous choisissez d'utiliser le <i> pour les icônes sur votre site web, vous pouvez donner plus de sens que la spécification.

De plus, si cet usage se généralise, il sera probablement inclus dans la spécification à l'avenir. Vous devrez alors passer en revue votre code, en remplaçant <span> s avec <i> 's ! Il peut donc être judicieux de se rallier à ce qui semble être la direction de la spécification, en particulier lorsque cela n'entre pas clairement en conflit avec la spécification actuelle. L'usage courant a tendance à dicter les règles linguistiques plutôt que l'inverse. Si vous êtes assez vieux, vous souvenez-vous que "site Web" était l'orthographe officielle lorsque le mot était nouveau ? Les dictionnaires insistaient sur le fait qu'il devait y avoir un espace et que Web devait être mis en majuscule. Il y avait des raisons sémantiques à cela. Mais l'usage commun disait : "Peu importe, c'est stupide. J'utilise 'site web' parce que c'est plus concis et plus joli." Et très vite, les dictionnaires ont officiellement reconnu cette orthographe comme correcte.

4. Je vais donc l'utiliser.

Donc, <i> donne plus de sens aux machines en raison de la spécification, il donne plus de sens aux humains parce que nous associons facilement "i" à "icône", et c'est seulement une lettre de long. Gagnant ! Et si vous vous assurez d'inclure un texte équivalent soit à l'intérieur de la balise <i> ou juste à côté (comme le fait Twitter), les lecteurs d'écran comprennent alors où cliquer pour répondre, le lien est utilisable si le CSS ne se charge pas, et les lecteurs humains ayant une bonne vue et un navigateur décent voient une jolie icône. Avec tout cela en tête, je ne vois pas l'inconvénient.

Answer 3

La réponse de Quentin indique clairement que i ne doit pas être utilisée pour définir des icônes.

Mais, Holly a suggéré que span n'a pas de sens en soi et a voté en faveur de i au lieu de span étiquette.

Peu de suggestions d'utilisation img car il est sémantique et contient alt étiquette. Mais, nous ne devrions pas également utiliser img parce que même vide src envoie une requête au serveur. Lire ici

Je pense que la manière correcte serait,

<span class="icon-fb" role="img" aria-label="facebook"></span>

Cela résout le problème de l'absence de alt tag dans span et le rend accessible aux utilisateurs malvoyants. Il est sémantique et ne fait pas un usage abusif (piratage) d'une balise.

Answer 4

À mon avis, c'est parce que Twitter estime qu'il est nécessaire de prendre en charge les anciens navigateurs. :before / :after pseudo-éléments.

Les anciens navigateurs ne supportent pas les pseudo-éléments que j'ai mentionnés, ils doivent donc utiliser un élément HTML réel pour les icônes, et comme les icônes n'ont pas de balise "exclusive", ils ont simplement utilisé la balise <i> et tous les navigateurs supportent cette balise.

Ils auraient certainement pu utiliser un <span> comme vous (ce qui est TOTALEMENT bien), mais probablement pour les raisons que j'ai mentionnées ci-dessus et celles mentionnées par Quentin C'est aussi pour cette raison que Bootstrap utilise l'option <i> étiquette.

C'est une mauvaise pratique que d'utiliser des balises supplémentaires pour des raisons stylistiques. pseudo-éléments ont été inventés, pour séparer le contenu du style... mais quand on voit la nécessité de supporter les anciens navigateurs, on est parfois obligé de faire ce genre de choses.

PS. Le fait que les icônes commencent par un 'i' et qu'il y a un <i> est une pure coïncidence.

Answer 5

Je me suis dit que c'était plutôt mauvais, parce que j'ai travaillé récemment sur un modèle de Joomla et que le modèle échouait toujours au W3C parce qu'il utilisait la balise <i> et qui a été déprécié, car son utilisation originale était de mettre quelque chose en italique, ce qui est maintenant fait par CSS et non plus par HTML.

C'est vraiment une mauvaise pratique, car quand je l'ai vu, j'ai parcouru le modèle et changé toutes les <i> balises pour <span style="font-style:italic"> et s'est ensuite demandé pourquoi le modèle entier avait l'air étrange.

C'est la principale raison pour laquelle c'est une mauvaise idée d'utiliser l'option <i> Vous ne savez jamais qui va regarder votre travail après coup et "supposer" que ce que vous vouliez vraiment faire, c'était mettre le texte en italique plutôt que d'afficher une icône. Je viens de mettre des icônes dans un site web et je l'ai fait avec le code suivant

<img class="icon" src="electricity.jpg" alt="Electricity" title="Electricity">

De cette façon, j'ai toutes mes icônes dans une seule classe, de sorte que tout changement que je fais affecte toutes les icônes (disons que je les voulais plus grandes ou plus petites, ou avec des bords arrondis, etc.), le texte alt donne aux lecteurs d'écran la possibilité de dire à la personne ce qu'est l'icône plutôt que d'obtenir simplement "texte en italique, fin de l'italique" (je ne sais pas exactement comment les lecteurs d'écran lisent les écrans, mais je suppose que c'est quelque chose comme ça), et le titre donne également à l'utilisateur une chance de passer la souris sur l'image et d'obtenir une info-bulle lui disant ce qu'est l'icône au cas où il ne pourrait pas le comprendre. C'est beaucoup mieux que d'utiliser <i> - et il passe également la norme W3C.