¿Debo usar la etiqueta <i> para iconos en lugar de <span>? [cerrado]

He investigado la fuente de Facebook, usan la <i>etiqueta para mostrar iconos.

Además, hoy busqué en Bootstrap de Twitter. También usa<i> etiquetas para mostrar iconos.

Pero,

De la especificación HTML5 :

El elemento I representa una extensión de texto en una voz o estado de ánimo alternativo, o compensado de otra manera con la prosa normal, como una designación taxonómica, un término técnico, una frase idiomática de otro idioma, un pensamiento, el nombre de un barco u otro prosa cuya típica presentación tipográfica está en cursiva.

¿Por qué están usando <i> etiqueta para mostrar iconos?

¿No es una mala práctica?

¿O me estoy perdiendo algo aquí?

Estoy usando spanpara mostrar iconos y parece estar funcionando para mí hasta ahora.

Actualizar:

Bootstrap 3 ahora se usa spanpara iconos. Doc oficial

¿Por qué están usando la <i>etiqueta para mostrar iconos?

Porque es:

• Corto
• I significa icono (aunque no en HTML)

¿No es una mala práctica?

Pésima práctica. Es un triunfo del rendimiento sobre la semántica.

Estoy saltando aquí un poco tarde, pero me encontré con esta página al reflexionar sobre mí. Por supuesto, no sé cómo Facebook o Twitter lo justificaron, pero aquí está mi propio proceso de pensamiento sobre lo que vale.

Al final, llegué a la conclusión de que esta práctica no es tan poco semántica (¿es una palabra?). De hecho, además de la brevedad y la buena asociación de "i is for icon", creo que en realidad es la opción más semántica para un icono cuando una <img>etiqueta directa no es práctica.

1. El uso es consistente con la especificación.

Si bien puede que no sea lo que el W3 tenía en mente principalmente, me parece que la especificación oficial <i>podría acomodar un icono con bastante facilidad. Después de todo, el símbolo de flecha de respuesta dice "responder" de otra manera. Expresa un término técnico que puede ser desconocido para el lector y que generalmente se escribe en cursiva. ("Aquí en Twitter, esto es lo que llamamos una flecha de respuesta "). Y es un término de otro idioma: un lenguaje simbólico.

Si, en lugar del símbolo de flecha, Twitter usara <i>shout out</i>o <i>[Japanese character for reply]</i>(en una página en inglés), eso sería consistente con la especificación. Entonces por qué no <i>[reply arrow]</i>? (Estoy hablando estrictamente de semántica HTML aquí, no de accesibilidad, a lo que llegaré).

Hasta donde puedo ver, la única parte de la especificación violada explícitamente por el uso del icono es la frase de "extensión de texto" (cuando la etiqueta no contiene texto también). Está claro que la <i>etiqueta está destinada principalmente al texto, pero ese es un detalle bastante pequeño en comparación con la intención general de la etiqueta. La pregunta importante para esta etiqueta no es qué formato de contenido contiene, sino cuál es el significado de ese contenido.

Esto es especialmente cierto cuando considera que la línea entre "texto" e "icono" puede ser casi inexistente en los sitios web. El texto puede parecerse más a un ícono (como en el ejemplo japonés) o un ícono puede parecer texto (como en un botón jpg que dice "Enviar" o una foto de gato con un título superpuesto) o el texto puede reemplazarse o mejorarse con una imagen a través de CSS. Texto, imagen: ¿a quién le importa? Todo es contenido. Mientras todos, los humanos con discapacidades, los navegadores con discapacidades, las arañas de los motores de búsqueda y otras máquinas de diversos tipos puedan comprender ese significado, hemos hecho nuestro trabajo.

Por lo tanto, el hecho de que los escritores de la especificación no pensaron (o eligieron) aclarar esto no debería desviarnos de hacer lo que tiene sentido y es coherente con el espíritu de la etiqueta. La <a>etiqueta fue originalmente destinado a llevar al usuario a otro sitio, pero ahora podría aparecer una caja de luz. Gran grito, ¿verdad? Si alguien hubiera descubierto cómo abrir una caja de luz al hacer clic antes de que la especificación se pusiera al día, todavía debería haber usado la <a>etiqueta, no una <span>, incluso si no era del todo coherente con la definición actual, porque se acercaba más y era sigue siendo coherente con el espíritu de la etiqueta ("algo sucederá cuando haga clic aquí"). El mismo trato <i>: cualquier tipo de cosa que pongas dentro de ella, o por muy creativa que la uses,

2. La <i>etiqueta agrega significado semántico a un elemento de icono.

La opción alternativa para llevar una clase de ícono es <span>, por supuesto, que no tiene ningún significado semántico. Cuando una máquina pregunta <span>qué contiene, dice: "No sé. Podría ser cualquier cosa". Pero la <i>etiqueta dice: "Tengo una forma diferente de decir algo de la forma habitual, o tal vez un término desconocido". No es lo mismo que "Tengo un ícono", ¡pero está mucho más cerca de lo que <span>estaba!

3. Eventualmente, el uso común hace lo correcto.

Además de lo anterior, vale la pena considerar que los lectores de máquina (ya sea motor de búsqueda, lector de pantalla o lo que sea) en cualquier momento pueden comenzar a tener en cuenta que Facebook, Twitter y otros sitios web usan la <i>etiqueta como íconos. No les importa la especificación tanto como les importa extraer el significado del código por cualquier medio necesario. Por lo tanto, podrían usar este conocimiento de uso común para simplemente registrar que "puede haber un ícono aquí" o hacer algo más avanzado como activar una mirada al CSS para obtener una pista del significado, o quién sabe qué. Entonces, si elige usar los <i>íconos for en su sitio web, puede estar proporcionando más significado que la especificación.

Además, si este uso se generaliza, probablemente se incluirá en la especificación en el futuro. ¡Entonces revisarás tu código, reemplazando <span>s por <i>'s! Por lo tanto, puede tener sentido abordar lo que parece ser la dirección de la especificación, especialmente cuando no está claramente en conflicto con la especificación actual. El uso común tiende a dictar las reglas del idioma más que al revés. Si tienes la edad suficiente, ¿recuerdas que "sitio web" era la ortografía oficial cuando la palabra era nueva? Los diccionarios insistieron en que debe haber un espacio y la Web debe estar en mayúscula. Había razones semánticas para eso. Pero el uso común decía: "Lo que sea, eso es estúpido. Estoy usando 'sitio web' porque es más conciso y se ve mejor". Y en poco tiempo

4. Así que sigo adelante y lo uso.

Por lo tanto, <i>proporciona más significado a las máquinas debido a la especificación, brinda más significado a los humanos porque asociamos fácilmente "i" con "icono", y tiene solo una letra de largo. ¡Ganar! Y si se asegura de incluir texto equivalente dentro de la <i>etiqueta o justo al lado (como lo hace Twitter), los lectores de pantalla entienden dónde hacer clic para responder, el enlace se puede usar si CSS no se carga, y los lectores humanos con buena la vista y un navegador decente ven un bonito icono. Con todo esto en mente, no veo el inconveniente.

La respuesta de Quentin dice claramente que i etiqueta no debe usarse para definir iconos.

Pero, Holly sugirió que eso spanno tiene sentido en sí mismo y votó a favor en ilugar de spanetiqueta.

Pocos sugirieron usar img ya que es semántico y contiene altetiqueta. Pero, no deberíamos usarlo también imgporque incluso vacío srcenvía una solicitud al servidor. Leer aquí

Creo que la forma correcta sería

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

Esto resuelve el problema de no altetiquetar spany lo hace accesible para usuarios con discapacidad visual. Es semántico y no utiliza mal (piratea) ninguna etiqueta.

Mi suposición: debido a que Twitter ve la necesidad de admitir navegadores heredados, de lo contrario estarían usando los :before/ :afterpseudo-elementos.

Los navegadores heredados no admiten esos pseudoelementos que mencioné, por lo que deben usar un elemento HTML real para los iconos, y dado que los iconos no tienen una etiqueta 'exclusiva', simplemente fueron con la <i>etiqueta, y todos los navegadores admiten esa etiqueta

Ciertamente podrían haber usado un <span>, tal como usted (que está TOTALMENTE bien), pero probablemente por la razón que mencioné anteriormente más las mencionadas por Quentin , también es la razón por la que Bootstrap está usando la <i>etiqueta.

Es una mala práctica usar marcas adicionales por motivos de estilo, por eso los pseudoelementos se inventaron los , para separar el contenido del estilo ... pero cuando ve la necesidad de admitir navegadores heredados, a veces se ve obligado a hacer este tipo de cosas.

PD. El hecho de que los íconos comiencen con una 'i' y que haya una <i>etiqueta es una coincidencia.

Tomo un enfoque totalmente diferente a las respuestas de los demás aquí por completo. Permítanme prefijar mi solución y argumentar afirmando que a veces los estándares y las convenciones están destinados a romperse, especialmente en el contexto de las definiciones de etiquetas léxicas HTML estándar.

No hay nada que le impida crear elementos personalizados que se autodescriban para su propósito.

Tanto los navegadores modernos como incluso IE 6+ (con shim) pueden admitir cosas como:

<icon class="plus">

o

<icon-add>

Solo asegúrate de normalizar la etiqueta:

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

y use una cuña si necesita admitir IE9 o anterior (vea la publicación a continuación).

Mira esta publicación de StackOverflow:

¿Hay alguna manera de crear su propia etiqueta html en HTML5?

Para ampliar mi argumento, tanto las Directivas angulares de Google como los nuevos proyectos de Polymer utilizan el concepto de etiquetas HTML personalizadas.

Pensé que esto se veía bastante mal, porque estaba trabajando en una plantilla de Joomla recientemente y seguía recibiendo la plantilla que fallaba en el W3C porque estaba usando la <i>etiqueta y eso había quedado obsoleto, ya que su uso original era poner en cursiva algo, que ahora se hace a través de CSS ya no HTML.

Realmente es una mala práctica porque cuando lo vi revisé la plantilla y cambié todas las <i>etiquetas a ella, <span style="font-style:italic">y luego me pregunté por qué la plantilla entera se veía extraña.

Esta es la razón principal por la que es una mala idea usar la <i>etiqueta de esta manera: nunca se sabe quién va a mirar su trabajo después y "asumir" que lo que realmente estaba tratando de hacer es poner en cursiva el texto en lugar de mostrar un icono. Acabo de poner algunos íconos en un sitio web y lo hice con el siguiente código

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

de esa manera tengo todos mis íconos en una clase, por lo que cualquier cambio que haga afecta a todos los íconos (digamos que los quería más grandes o más pequeños, o bordes redondeados, etc.), el texto alternativo brinda a los lectores de pantalla la oportunidad de decirle a la persona qué el ícono es en lugar de simplemente obtener "texto en cursiva, fin de cursiva" (no sé exactamente cómo los lectores de pantalla leen pantallas, pero supongo que es algo así), y el título también le da al usuario la oportunidad de pasar el mouse la imagen y obtenga información sobre herramientas que les diga cuál es el icono en caso de que no puedan resolverlo. Mucho mejor que usar <i>, y también pasa el estándar W3C.

También encontré que esto era útil cuando quería colocar un icono con posicionamiento absoluto dentro de una <a>etiqueta de enlace .

<img>Primero pensé en la etiqueta, pero el estilo predeterminado de esas etiquetas dentro de los enlaces generalmente tiene un estilo de borde y / o efectos de sombra. Además, se siente mal usar una <img>etiqueta sin definir un atributo "src", mientras que estoy usando una declaración de hoja de estilo de imagen de fondo para que la imagen no se fantasma y arrastre.

En este punto, está pensando en etiquetas como <span>o <i>, en cuyo caso <i>tiene tanto sentido como este tipo de icono.

En general, creo que su beneficio además de ser intuitivo es que requiere ajustes mínimos de la hoja de estilo para que esta etiqueta funcione como un ícono.