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


572

J'ai regardé la source de Facebook, ils utilisent la <i>balise pour afficher les icônes.

Aujourd'hui, j'ai également examiné le Bootstrap de Twitter. Il utilise également des <i>balises pour afficher les icônes.

Mais,

De la spécification HTML5 :

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

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

N'est-ce pas une mauvaise pratique?

Ou est-ce que je manque quelque chose ici?

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

Mise à jour:

Bootstrap 3 utilise désormais spandes icônes. Doc officiel


5
Exemple: La réponse ci - dessous , flèche tweets sur Twitter: <i class="sm-reply"></i>.
kay - SE is evil

2
Pourquoi ne devrait-il pas <span>être utilisé?
Jashwant

6
Il me semble que pour la sémantique et l'accessibilité, la balise img devrait toujours être utilisée pour les icônes, avec le texte de remplacement.
nroose

12
@nroose Mon opinion à ce sujet est que les images utilisées pour les icônes ne font pas partie du contenu, mais du style de la page (contrairement, par exemple, à l'image d'une vache sur la page wikipedia sur les vaches). Par conséquent, ils doivent être définis dans le CSS, pas comme une image dans une balise img.
CJStuart

6
Je ne pense pas que les décisions sémantiques en HTML5 doivent être considérées comme "basées sur l'opinion".
Aaron

Réponses:


597

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

Parce que c'est:

  • Court
  • je représente l'icône (mais pas en HTML)

N'est-ce pas une mauvaise pratique?

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


87
C'est mon premier jour pour apprendre le bootstrap de twitter et il est regrettable qu'ils ne suivent pas les meilleures pratiques.
Jashwant

25
certaines personnes vont même plus loin et abusent d'autres éléments, comme <tt>= info-bulle et ainsi de suite ... tu veux m'aider à trouver ATSMOHE? "Contre l'utilisation abusive sémantique des éléments HTML"
Christoph

18
Ces sites Web ont des millions de pages vues chaque jour. S'ils économisent 100 octets de données chaque fois qu'un client demande une page avec cette pratique, ils économisent une quantité importante de bande passante.
Dalmas

62
Pour économiser 100 octets, ils devraient inclure 16 icônes et ne pas activer la compression .
Quentin

7
Avec l'utilisation de ligatures , l'utilisation de la ibalise pour afficher les icônes est sémantique. En fait, Google suggère d'utiliser la ibalise avec des ligatures dans son guide des icônes de matériaux .
Aust

269

Je saute ici 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 mon propre processus de réflexion pour ce qu'il vaut.

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

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

Bien que ce ne soit peut-être pas ce que le W3 avait principalement en tête, il me semble que la spécification officielle <i>pourrait accueillir une icône assez facilement. Après tout, le symbole de la flèche de réponse indique "répondre" d'une autre manière. Il exprime un terme technique qui peut ne pas être familier au lecteur et serait généralement en italique. ("Ici sur Twitter, c'est ce que nous appelons une flèche de réponse .") Et c'est un terme d'une autre langue: une langue symbolique.

Si, au lieu du symbole de la flèche, Twitter utilisait <i>shout out</i>ou <i>[Japanese character for reply]</i>(sur une page en anglais), cela serait conforme à la spécification. Alors pourquoi pas <i>[reply arrow]</i>? (Je parle ici uniquement de sémantique HTML, pas d'accessibilité, ce à quoi je reviendrai.)

Pour autant que je puisse voir, la seule partie de la spécification explicitement violée par l'utilisation des icônes est la phrase "span of text" (lorsque la balise ne contient pas de texte également). Il est clair que la <i>balise est principalement destinée au texte, mais c'est un détail assez petit par rapport à l'intention globale de la balise. La question importante pour cette balise n'est pas le format du contenu qu'elle contient, mais la signification de ce contenu.

Cela est particulièrement vrai lorsque vous considérez que la ligne 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 "Soumettre" ou une photo de chat avec une légende superposée) ou le texte peut être remplacé ou amélioré avec une image via CSS. Texte, image - qui s'en soucie? Tout est contenu. Tant que tout le monde - les humains avec des déficiences, les navigateurs avec des déficiences, les araignées des moteurs de recherche et d'autres machines de toutes sortes peuvent comprendre ce sens, nous avons fait notre travail.

Donc, le fait que les rédacteurs de la spécification n'aient pas pensé (ou choisi) de clarifier cela ne devrait pas nous empêcher de faire ce qui a du sens et est conforme à l'esprit du tag. La <a>balise était à l'origine destinée à emmener l'utilisateur ailleurs, mais maintenant elle pourrait faire apparaître une lightbox. Big whoop, non? Si quelqu'un avait compris comment faire apparaître une lightbox au clic avant que la spécification ne soit rattrapée, il aurait quand même dû utiliser la <a>balise, pas un <span>, même si elle n'était pas entièrement cohérente avec la définition actuelle - car elle était la plus proche et était toujours conforme à l'esprit du tag ("quelque chose se passera lorsque vous cliquerez ici"). Même chose avec <i>- quel que soit le type de chose que vous y mettez, ou quelle que soit la façon dont vous l'utilisez,

2. La <i>balise ajoute une signification sémantique à un élément icône.

L'option alternative pour transporter une classe d'icônes en elle-même est <span>, ce qui n'a bien sûr aucune signification sémantique. Quand une machine demande <span>ce qu'elle contient, elle dit: "Je ne sais pas. Ça pourrait être n'importe quoi." Mais la <i>balise dit: «Je contiens une façon différente de dire quelque chose que la façon habituelle, ou peut-être un terme inconnu." Ce n'est pas la même chose que "Je contient une icône", mais c'est beaucoup plus proche que ce que <span>j'ai obtenu!

3. Finalement, l'usage courant fait l'affaire.

En plus de ce qui précède, il convient de considérer que les lecteurs de machine (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 <i>balise pour les icônes. Ils ne se soucient pas autant de la spécification que de l'extraction de sens du code par tous les moyens nécessaires. Ainsi, ils pourraient utiliser cette connaissance de l'usage courant pour simplement enregistrer qu '"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 sens, ou qui sait quoi. Donc, si vous choisissez d'utiliser les <i>icônes pour sur votre site Web, vous donnez peut-être plus de sens que la spécification.

De plus, si cette utilisation se généralise, elle sera probablement incluse dans la spécification à l'avenir. Ensuite, vous allez parcourir votre code, en remplaçant <span>s par <i>des! Il peut donc être judicieux de se rallier à ce qui semble être la direction de la spécification, surtout quand elle n'est pas clairement en conflit avec la spécification actuelle. L'utilisation courante a tendance à dicter les règles de langue plus 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 le Web devait être capitalisé. Il y avait des raisons sémantiques à cela. Mais l'usage courant disait: «Quoi qu'il en soit, c'est stupide. J'utilise« site Web »parce qu'il est plus concis et semble meilleur. Et avant longtemps,

4. Je vais donc de l'avant et je l'utilise.

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 ce n'est qu'une lettre. Gagner! Et si vous vous assurez d'inclure un texte équivalent à l'intérieur de la <i>balise ou juste à côté (comme le fait Twitter), les lecteurs d'écran comprennent où cliquer pour répondre, le lien est utilisable si CSS ne se charge pas, et les lecteurs humains avec une bonne la vue et un navigateur décent voient une jolie icône. Avec tout cela à l'esprit, je ne vois pas l'inconvénient.


33
Mais il existe déjà des moyens de le faire sans abuser <i>: utilisez n'importe quel élément de texte, y compris des boutons ou des liens, et ajoutez une icône en utilisant un graphique d'arrière-plan et du rembourrage, de la même manière que pour l'utilisation <i>. Le code HTML ressemblerait <a ...>Reply</a>, ce qui est sémantique, la page stylisée affiche une icône en plus. Si l'icône est le seul élément principal , il doit s'agir d'un <img src="..." alt="Reply">.
décomposer

36
@Holly, vous l'avez pris d'un côté complètement différent, mais désolé, je ne suis pas d'accord avec chaque ligne que vous avez dite.
Jashwant

11
Le vide (même une icône) n'est pas du texte, cependant, et le texte est ce qui est spécifiquement écrit dans la spécification.
Ry-

17
Spécifiquement écrit dans la spécification signifie jack. Vous le savez et tout le monde le sait. C'est un guide. Rien de plus. Pensez-vous que IE se soucie de la spécification? Ils s'améliorent. Pensez-vous que tous les navigateurs essaient de perfectionner les spécifications? Pensez-vous que tout le monde sur la planète utilise correctement <code> nav, en-tête, pied de page, section, côté, ... n </code>? Nan. Je vais page après page où à part est un remplacement pour <code> <div class = "sidebar"> </code> Et vous savez quoi? La façon dont les gens continuent à utiliser est ce qui va définir la "sémantique" à l'avenir.
o_O

17
Grands arguments, je pense que vous m'avez convaincu. Particulièrement convaincant est le n ° 3, «l'usage courant fait le bien». Tout comme avec le langage courant, si tout le monde commence à utiliser un mot de cette manière, cela devient l'usage standard. La spécification HTML est un document évolutif depuis un certain temps maintenant, et y adhérer de manière dogmatique est tout simplement stupide. Adhérer à une convention commune est, à mon avis, une voie plus durable. De plus, l'élément <i> est presque obsolète à ce stade, donc je me sens bien de lui donner une nouvelle vie sémantiquement riche! Je suis curieux de voir comment la spécification évoluera avec cet usage, comme je le pense sans aucun doute.
Logic Artist

59

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

Mais, Holly a suggéré que cela spann'a pas de sens en soi et a voté pour iau lieu de spantag.

Peu suggéré d'utiliser imgcar il est sémantique et contient une altbalise. Mais, nous ne devrions pas également utiliser imgcar même vide srcenvoie une demande au serveur. Lisez ici

Je pense que la bonne façon serait,

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

Cela résout le problème de l'absence de altbalise spanet la rend accessible aux utilisateurs malvoyants. C'est sémantique et ne pas abuser (pirater) une balise.


6
@GeorgeMauer, tous les concepteurs html / web qui se respectent se soucient des balises alt. la spécification est là pour une raison. comme les rampes dans les bâtiments, les balises alt, title et aria existent pour une raison.
osiris

3
@osiris tient maintenant, les spécifications changent tout le temps. Je suis d'accord que c'est bon à suivre, mais vous devez prendre en compte l'intention sous-jacente. Cela étant dit, depuis la recherche, je suis d'accord avec vous car ce n'est pas seulement pour les lecteurs d'écran / images manquantes / info-bulles - il y a en fait une sémantique que je n'étais pas au courant. MDN: "L'omission de cet attribut indique que l'image est une partie clé du contenu, mais aucun équivalent textuel n'est disponible. La définition de cet attribut sur la chaîne vide indique que cette image n'est pas une partie clé du contenu; les navigateurs non visuels peuvent omettre le rendu. "
George Mauer

3
En guise de remarque, je crois que le rôle correct de l'aria pour une icône est la présentation . Pas img .
Sylvain Leroux

2
@SylvainLeroux, je pense que si l'icône est utilisée dans un bouton avec du texte, alors le rôle est la présentation. Mais si seule une icône est utilisée dans le bouton (pas de texte), son rôle est img.
Jashwant

2
IL NE LE REND PAS ACCESSIBLE! L'avez-vous testé avec des lecteurs d'écran?! Remplacement solution nativement accessible <img alt="...">avec <span role="img">rend tout pire. Ne pas utiliser aria-labelsur un élément SPAN, non focalisable. Cela ne fonctionnera pas toujours comme prévu. Ne l'utilisez pas rolesi vous ne savez pas ce que vous faites. La surutilisation d'ARIA aggrave tout pour tout le monde. Rendre un produit inaccessible et rendre le code plus difficile à lire et à maintenir. Et qu'en est-il du référencement? ARIA est bon mais utilisez à bon escient - accessibility-developer-guide.com/knowledge/aria/bad-practices
Hrvoje Golcic

12

Ma conjecture: parce que Twitter voit la nécessité de prendre en charge les navigateurs hérités, sinon ils utiliseraient les :before/ :afterpseudo-éléments.

Les navigateurs hérités ne prennent pas en charge 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 sont simplement allés avec la <i>balise et tous les navigateurs prennent en charge cette balise.

Ils auraient certainement pu utiliser un <span>, tout comme vous (ce qui est TOTALEMENT bien), mais probablement pour la raison que j'ai mentionnée ci-dessus et celles mentionnées par Quentin , c'est aussi pourquoi Bootstrap utilise la <i>balise.

C'est une mauvaise pratique lorsque vous utilisez un balisage supplémentaire pour des raisons de style, c'est pourquoi des pseudo-éléments ont été inventés, pour séparer le contenu du style ... mais quand vous voyez la nécessité de prendre en charge les navigateurs hérités, parfois vous êtes obligé de faire ce genre de des choses.

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


3
Pas vraiment, si vous regardez le code à l'intérieur du I est un élément avant
DCdaz

12

J'adopte une approche totalement différente des réponses de tous les autres ici. Permettez-moi de préfixer ma solution et d'argumenter en déclarant que parfois les normes et les conventions sont censées être brisées, en particulier dans le contexte des définitions de balises lexicales HTML standard.

Il n'y a rien pour vous empêcher de créer des éléments personnalisés qui sont auto-descriptifs pour son objectif.

Les navigateurs modernes et même IE 6+ (avec shim) peuvent prendre en charge des éléments tels que:

<icon class="plus">

ou

<icon-add>

Assurez-vous simplement de normaliser la balise:

 icon { display:block; margin:0; padding:0; border:0; ... }

et utilisez une cale si vous devez prendre en charge IE9 ou une version antérieure (voir le post ci-dessous).

Découvrez ce post StackOverflow:

Existe-t-il un moyen de créer votre propre balise html en HTML5

Pour approfondir mon argument, les directives angulaires de Google et les nouveaux projets Polymer utilisent le concept de balises HTML personnalisées.


2
Et puis vous allez au validateur W3C, et entrez <!doctype html> <html lang="en"> <head> <title>Hello</title> </head> <body> <icon></icon> </body> </html>et vous obtenez une seule erreur, disantError: Element icon not allowed as child of element body in this context.
Digital Ninja

6

Je pensais que cela semblait assez mauvais - parce que je travaillais sur un modèle Joomla récemment et que le modèle échouait W3C parce qu'il utilisait la <i>balise et qu'il était obsolète, car son utilisation initiale était de mettre en italique quelque chose, ce qui est maintenant fait via CSS plus HTML.

Cela fait vraiment une mauvaise pratique parce que quand je l'ai vu, j'ai parcouru le modèle et changé toutes les <i>balises à la <span style="font-style:italic">place, puis je me suis 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 la <i>balise de cette façon - vous ne savez jamais qui va regarder votre travail par la suite et "supposez" que ce que vous essayez vraiment de faire est de mettre le texte en italique plutôt que d'afficher un icône. Je viens de mettre quelques 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 classe, donc tout changement que j'apporte affecte toutes les icônes (disons que je les voulais plus ou moins grandes, ou des bordures arrondies, etc.), le texte alternatif donne aux lecteurs d'écran la possibilité de dire à la personne ce que l'icône est plutôt que de simplement obtenir "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 l'image et obtenez une info-bulle leur indiquant ce qu'est l'icône au cas où ils ne pourraient pas le comprendre. Beaucoup mieux que d'utiliser <i>- et il passe également la norme W3C.


7
<i>n'est pas obsolète.
user2867288

3
La balise "img" ne fonctionne pas pour les icônes de police. Je veux dire que c'est le cas, mais votre navigateur envoie une demande à votre site chaque fois qu'elle est analysée.
Navin

1
Au lieu de <span style="font-style:italic" />vous, vous auriez pu simplement utiliser sa nouvelle alternative -<strong />
ewino

@ewino Je pense que vous voulez dire <em> </em> qui est le remplacement sémantique pour mettre l'accent sur les mots (plutôt que d'appliquer simplement l'italique)
amklose

Vous avez en effet raison :-)
ewino

2

J'ai également trouvé cela utile lorsque je voulais placer une icône avec un positionnement absolu à l'intérieur d'une <a>balise de lien .

J'ai d'abord pensé à la <img>balise, mais le style par défaut de ces balises à l'intérieur des liens a généralement un style de bordure et / ou des effets d'ombre. De plus, il ne convient pas d'utiliser une <img>balise sans définir d'attribut "src" alors que j'utilise une déclaration de feuille de style d'image d'arrière-plan afin que l'image ne se fantôme pas et ne glisse pas.

À ce stade, vous pensez à des balises comme <span>ou <i>- dans ce cas, <i>cela a autant de sens que ce type d'icône.

Dans l'ensemble, je pense que son avantage, en plus d'être intuitif, est qu'il nécessite un minimum d'ajustements de feuille de style pour que cette balise fonctionne comme une icône.


Voici pourquoi je pense que c'est une mauvaise pratique. Historiquement, <B> était pour Bold et <I> pour itallic. Donc, si vous avez utilisé <i>, vous créez une balise métallique vide qui n'est pas à quoi elle sert. Ceux-ci ont été remplacés par <strong> et <em> Donc, pour les navigateurs anciens, je suppose que vous ne voudriez pas marquer une page avec des balises métalliques vides, et qu'en est-il des lecteurs d'écran pour les aveugles, ces icônes à l'intérieur du lien ne devraient-elles pas disons TEXTE. <span> est donc un meilleur choix, car vous pouvez mettre la taille de la police à zéro et avoir également l'icône.
user1712691

1
@ user1712691 Il est un mythe commun <b>et <i>ont été remplacés par <strong>et <em>respectivement. Mais la vérité est, <b>et <i>n'est pas dépréciée, et a pris de nouvelles significations sémantiques. Lisez les spécifications officielles pour en savoir plus.
chharvey
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.