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 span
pour afficher des icônes et cela semble fonctionner pour moi jusqu'à présent.
Mise à jour:
Bootstrap 3 utilise désormais span
des icônes. Doc officiel
la source
<i class="sm-reply"></i>
.<span>
être utilisé?Réponses:
Parce que c'est:
Horrible pratique. C'est un triomphe de la performance sur la sémantique.
la source
<tt>
= info-bulle et ainsi de suite ... tu veux m'aider à trouver ATSMOHE? "Contre l'utilisation abusive sémantique des éléments HTML"i
balise pour afficher les icônes est sémantique. En fait, Google suggère d'utiliser lai
balise avec des ligatures dans son guide des icônes de matériaux .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.la source
<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">
.La réponse de Quentin indique clairement que la
i
balise ne doit pas être utilisée pour définir des icônes.Mais, Holly a suggéré que cela
span
n'a pas de sens en soi et a voté pouri
au lieu despan
tag.Peu suggéré d'utiliser
img
car il est sémantique et contient unealt
balise. Mais, nous ne devrions pas également utiliserimg
car même videsrc
envoie une demande au serveur. Lisez iciJe 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
alt
balisespan
et la rend accessible aux utilisateurs malvoyants. C'est sémantique et ne pas abuser (pirater) une balise.la source
<img alt="...">
avec<span role="img">
rend tout pire. Ne pas utiliseraria-label
sur un élément SPAN, non focalisable. Cela ne fonctionnera pas toujours comme prévu. Ne l'utilisez pasrole
si 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-practicesMa conjecture: parce que Twitter voit la nécessité de prendre en charge les navigateurs hérités, sinon ils utiliseraient les
:before
/:after
pseudo-é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.la source
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:
ou
Assurez-vous simplement de normaliser la balise:
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.
la source
<!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.
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 suivantDe 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.la source
<i>
n'est pas obsolète.<span style="font-style:italic" />
vous, vous auriez pu simplement utiliser sa nouvelle alternative -<strong />
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.
la source
<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.