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.
<i class="sm-reply"></i>.