¿Por qué las etiquetas <b> y <i> están en desuso?


98

Esta pregunta surgió en una de mis clases universitarias. El profesor sólo le dio la respuesta que era más descriptivo, pero parece como si <b>y <i>son bastante explícitos en su significado y es más fácil de escribir de <strong>y <em>.

¿Cuáles fueron los argumentos oficiales para la depreciación de estas etiquetas?


38
Estoy bastante seguro <b>y <i>no estoy en desuso.
Doval


44
Tiendo a razonar sobre esto así: ¿Quiero que un lector de pantalla lea esto de manera diferente o no? Si solo quiero elegir palabras para que un lector (no ciego) las pueda encontrar fácilmente, podría usarlas b, literalmente significa "esto está en negrita", no "esto está enfatizado". Pero el punto principal es que tienen un significado diferente: no hay desaprobación, solo que no era eso cuando solías hacerlo bo i, por lo general, querías decir strongo em.
Luaan

1
@MichaelT Recuerdo que cuando comencé a usar LaTeX, estaba confundido acerca de todas las diferentes formas en que el texto se podía poner en cursiva y en negrita al comenzar en un documento en blanco (sin paquetes de estilo).
Cole Johnson

@Luaan: Incluso si <i>y en <b>realidad no están en desuso, <tt>y lo <u>están, y la pregunta sería igual de aplicable a esos.
supercat

Respuestas:


135

El verano pasado, leí la especificación HTML5 completa, y todas las especificaciones HTML anteriores (incluso las abandonadas), y todas las especificaciones CSS que pude encontrar, y muchas especificaciones XML. Dado que me encantan los documentos de hipertexto semánticamente ricos, permítame darle la idea detrás de la semántica HTML relevante en HTML5.

Antes de HTML5

Antes de HTML5, iy de bhecho estaban fuera de moda. La razón era que esencialmente funcionaban como emy strong, respectivamente, pero con enfoque en la presentación y no en la semántica (lo cual es malo).

De hecho, isignificaba que el texto debería estar en cursiva (decía algo sobre cómo debería representarse el texto en pantalla). Por otro lado, emsignificaba que el texto debía enfatizarse (decía algo sobre la semántica del texto).

Hay una diferencia teórica importante aquí. Si lo usa em, el agente de usuario (= navegador) sabe que el texto debe enfatizarse, por lo que puede mostrarlo en cursiva si el documento se muestra en pantalla (o todo en mayúsculas si no es posible formatear, o incluso en negrita). el usuario lo prefiere), puede pronunciarlo de manera diferente si el documento se le habla al usuario, etc.

Observe que el énfasis realmente se trata de la semántica. Por ejemplo, las frases

  • El gato es mio. (= ¡no el perro!)
  • El gato es mio . (= ¡no el tuyo!)

No tienen el mismo significado.

La misma diferencia se aplica a b(fuente en negrita) y strong(énfasis fuerte).

Un principio general de la escritura digital en general, y de la autoría de hipertexto en particular, es que debe separar el contenido y el estilo. En la autoría de hipertexto, esto significa que el contenido debe estar en el archivo HTML, y el estilo debe estar en un archivo CSS (o varios archivos CSS). Un principio diferente pero relacionado es que el documento debe ser rico en semántica (como marcar encabezados, pies de página, listas, énfasis, direcciones, áreas de navegación, etc.). Esto tiene una serie de ventajas:

  • Es mucho más fácil para los programas de computadora interpretar el documento. Estos programas incluyen navegadores, aplicaciones de texto a voz, motores de búsqueda y asistentes digitales. (Por ejemplo, el navegador puede permitirle guardar una dirección en su libreta de direcciones, si solo puede encontrarla e interpretarla. Además, puede saber que Microsoft Word puede crear y actualizar automáticamente una tabla de contenido para usted si marca sus encabezados correctamente .)
  • Es mucho más fácil cambiar el estilo más adelante. (Si desea cambiar el color de todos los encabezados de tercer nivel en su documento de 860 páginas, puede cambiar una sola línea en la hoja de estilo. Si tuviera contenido mixto y presentación, tendría que revisar todo el documento manualmente Y es probable que se pierda uno o dos encabezados, lo que hace que el documento parezca poco profesional).
  • Puede usar diferentes hojas de estilo según las circunstancias (¿el documento se muestra en pantalla o se imprime en papel?). Incluso puede dejar que el usuario final elija el estilo ella misma. (Mi sitio web ofrece varias hojas de estilo alternativas. En IE y FF, puede cambiarlas usando el menú Ver).

Entonces, en resumen, iya no bse utilizan porque eran etiquetas HTML preocupadas por la presentación , lo cual es totalmente incorrecto.

En HTML5

En HTML5 iy bya no están en desuso. En cambio, se les da un significado semántico . Entonces, en realidad, ahora se trata de semántica, y no de presentación.

Como antes, solía emmarcar el énfasis: "El gato es mío". Pero lo usa ipara casi todos los demás casos en los que usaría cursiva en una obra impresa. Por ejemplo:

  • Se utilizan ipara marcar designaciones taxonómicas: "Me gusta R. norvegicus ".
  • Se utiliza ipara marcar una frase en un idioma diferente en comparación con el texto circundante: a la carta
  • Se usa ipara marcar una palabra cuando se habla de la palabra en sí: " beber es tanto un sustantivo como un verbo"

También es una buena idea utilizar el classatributo para especificar el uso preciso (también "microformato" y "microdatos" de Google). Y, por supuesto, en el segundo caso, realmente debería usar el langatributo para especificar el idioma correcto. (De lo contrario, por ejemplo , un agente de texto a voz podría pronunciar mal el texto).

Hace aproximadamente un año, la especificación HTML5 también decía que citedebería usarse para marcar nombres de libros, películas, óperas, pinturas, etc.

  • ¿Qué opinas de Nymphomaniac ?

Finalmente, desde hace mucho tiempo, dfnse usa para marcar la instancia definitoria de una frase en un texto (como una definición matemática o la definición de un término):

  • Un grupo es un conjunto X equipado con una sola operación binaria * tal que ...

Entonces, la cursiva en su libro impreso, que puede significar muchas cosas diferentes, está representada por cuatro etiquetas HTML5 diferentes, lo cual es realmente genial, porque la semántica es buena, ya que traté de convencerlo anteriormente. (Por ejemplo, puede pedirle a su navegador que haga una lista de todas las definiciones en el texto, para asegurarse de conocerlas todas antes del examen).

En cuanto a strongy b, la especificación HTML5 dice que strongdebe usarse para marcar una parte importante del texto, como una advertencia o alguna palabra muy importante para atrapar en una oración. Por otro lado, bdebe usarse para marcar cosas que deben ser fáciles de encontrar en el texto, como palabras clave. También lo uso bcomo encabezados en los elementos de la lista (LI).


1
Corrección: la etiqueta de definición es <dfn>, no <def>. De lo contrario, gran resumen completo de todos los problemas. Su sugerencia para usar <b>como encabezados en los elementos de la lista es interesante; el enfoque semántico es usar una lista de definiciones , pero como actualmente no hay navegadores compatibles display:run-in, el marcado de palabras clave en línea con <b>o <span>son lo mejor que puede hacer.
AmeliaBR

@AmeliaBR. Gracias por observar el error tipográfico (def). Acerca de las listas de definición: las listas de definición deben usarse para pares de nombre-valor, y siempre las uso para esto (eche un vistazo a mi libro de visitas , por ejemplo). También me encantó display:run-in, pero dado que su soporte está disminuyendo , debe usar floatel content:truco o el truco, consulte rejbrand.se/rejbrand/news.asp?ItemIndex=169 . Cuando hablo de usar bpara marcar 'encabezados' en listas, no me refiero a pares de nombre-valor, sino más bien a listas simples donde quiero usar un 'encabezado' en cada elemento.
Andreas Rejbrand

1
@SarahofGaia Hay al menos dos fallas de razonamiento que <b>garantizan texto envalentonado. 1) Lectores de pantalla, pantallas braille y otros medios para consumir texto para los que los glifos más gruesos son un concepto sin sentido. 2) b { font-weight: normal }, lo que significa que el estilo de visualización tampoco está fijo para <b>ninguno.
8bittree

1
Por último, usted es siempre libre para el suministro de su propio CSS si no confía en el navegador: b, strong { font-weight:bold; }. De esa manera puede estar tan seguro como podría estarlo. CSS es la forma de especificar el formato visual. HTML trata sobre el significado (contenido), CSS sobre la presentación visual del mismo.
Andreas Rejbrand

1
Esta respuesta me dio la razón por la que necesito cambiar mis etiquetas de fuente a CSS. Siempre me han gustado las etiquetas de fuente en negrita y todo eso, ahora entiendo por qué no debería usarlas. Gracias
Andreas

58

Como dice Doval, no están en desuso. Ellos todavía existen , pero deben ser utilizados de manera diferente de lo que mucha gente, donde solían antes de HTML5.

Se trata de html 'semántico'. Debería describir "qué" es, en lugar de cómo debería verse. El navegador o, en teoría, cualquier otro medio de visualización (digamos una aplicación de lectura para invidentes) debería poder decidir cómo se debe interpretar exactamente.

Esto es similar por qué no debería usar nombres de clase CSS como "rojo" y usar clases más descriptivas que describan la idea funcional detrás del uso de un color diferente aquí. Más tarde, puede decidir que el verde es mejor (y tal vez cualquier cosa "fuerte" debería mostrarse usando color rojo en lugar de texto en negrita). O un usuario daltónico puede tener algunas configuraciones especiales del navegador donde los colores se reemplazan por otros medios.


1
¿Hay alguna situación en la que sea preferible usar <b> en lugar de <strong>? ¿O es <strong> siempre una etiqueta "más semántica"?
LanceLafontaine

44
Aproximadamente podría usar <b> para cosas que deberían estar "resaltadas" pero no "enfatizadas", como palabras clave en un texto. En la documentación técnica, a menudo se encuentran diferentes estilos de texto para mostrar ciertos atributos, como en los libros de programación, ejemplos de código o términos técnicos. Para tales casos de uso, como un término técnico <b> o <i> podrían usarse.
thorsten müller

3
@LanceLafontaine Eche un vistazo al estándar oficial .
Rufflewind

44
@ thorstenmüller Creo que también es un mal ejemplo ... es el caso del libro de texto en el que la administración decide más tarde que en lugar de negrita quieren sus atributos en letra de máquina de escribir y no en negrita sino subrayados, en cuyo caso el uso <span class="keyword">...</span>en primer lugar le ahorra muchos problemas.
CompuChip

2
@LanceLafontaine <b>es un caso extremo, pero hay ejemplos sólidos para usar <i>en casos en los que no <em>es apropiado: nombres científicos de especies o palabras latinas adoptadas en inglés ( podría usar un espacio con un atributo de idioma, pero eso tiene todo tipo de otras implicaciones: - un lector de pantalla puede cambiar las voces por un idioma diferente). También se puede usar para poner en cursiva los títulos de otras obras, aunque se debe usar el enfoque semánticamente correcto <cite>.
AmeliaBR

41

La verdadera historia es eso by iprimero fueron obsoletos, desaprobados, maldecidos y anatematizados como "presentacionales" en varios borradores HTML5 (en términos generales), pero luego se dieron cuenta de que estas etiquetas son ampliamente utilizadas y también generadas por muchos programas de autoría. En lugar de simplemente permitirlos, desarrollaron nuevas definiciones "semánticas" para ellos, para poder permitir los elementos pero al mismo tiempo pretender ser estrictos sobre el marcado "presentacional". Las nuevas definiciones han variado de un borrador a otro y son oscuras: apenas se pueden encontrar dos personas que las entiendan e interpreten de la misma manera.

Lo sentimos, no hay referencias. La descripción anterior es el resultado de seguir los cambios y leer los borradores y las discusiones, a menudo entre líneas. No están diciendo explícitamente la causa. Sigo pensando que es la historia real.

La conclusión es: seguir adelante. No hay nada útil aquí. Los elementos by ihacen lo mismo que siempre: ponen la fuente en negrita o cursiva, respectivamente, con las advertencias habituales. Esta es la realidad que debe tener en cuenta, no la "semántica" quasischolastic que no tiene impacto en los navegadores, motores de búsqueda u otro software.


3
Dicho esto, puedes seguir la semántica quasischolastic simplemente tratándola <b>como un tipo divertido <span>que, por defecto, se muestra en negrita. Luego, si puede molestarse, asigne también un classatributo a sus usos para que, cuando sea necesario, pueda cambiar el estilo de varias cosas a la vez que lo usaron porque tienen una semántica común. Es quasischolastic en el sentido de que la gente pensará que estás casi en la cabeza por hacer b.productname {font-weight: normal; font-style: italic; }después de que cambiaste de opinión sobre la presentación y aprovechaste tu sabia elección del marcado semántico ;-)
Steve Jessop

1
@SteveJessop: Para aquellos pocos de nosotros en el mundo que todavía nos preocupamos por el tamaño del archivo, decir <b>this</b>parece mucho más razonable que <span class="bold">this</b>(la sobrecarga de ocho bytes de la primera es bastante molesta; la sobrecarga de 23 bytes de la segunda parece una locura). Me pregunto por qué HTML nunca definió ninguna representación de formato corto <@quack>this</@>como equivalente a <span class="quack">this</span>?
Supercat

44
@supercat: para eso está la codificación de transferencia: gzip. O tal vez XML + XSLT, dependiendo exactamente dónde y cómo desea introducir una notación más concisa para "quack".
Steve Jessop

77
@supercat class='bold'? El maestro Suku de The Codeless Code hablaría contigo sobre el uso de nombres de clase tan pobres . Considere este su último boldRedText .

2
En los días de los módems 14.4, CSS era una idea que aún no se había implementado o implementado en ningún agente de usuario. Estos elementos HTML son simplemente un antiguo legado cruft con el que nos quedaremos atrapados para siempre.
Michael Hampton

11

Las etiquetas <b>y se <i>originaron con los conceptos de "negrita" y "cursiva". El problema es que estos pueden ser completamente sin sentido para algunos agentes de usuario. Por ejemplo, ¿cómo suena "cursiva" en un lector de pantalla para una persona ciega?

Reemplazándolos por <strong>y <em>quitando el enlace directo a los conceptos tipográficos. En cambio, el agente de usuario puede representarlos como lo considere conveniente.


2
Estrictamente hablando, el agente de usuario puede renderizar <b>y, <i>sin embargo, también lo considera conveniente.
Jonathan Eunice

8

Las etiquetas <b>y <i>son esenciales cuando literalmente necesita texto en 'negrita' o 'cursiva'.

Si está escribiendo una ecuación en HTML donde un ' I ' en cursiva tiene un significado diferente de un 'I' sin cursiva, es importante poder hacer esa distinción.

Pienso en ellos de la misma manera que pienso <sup>o <sub>etiquetas - no se puede representar correctamente el significado de una ecuación sin necesidad de utilizar este tipo de etiquetas 'apariencia'.

El enfoque purista sería usar MathML o TeX, pero el soporte del navegador aún no existe ...


14
Desearía que las personas que presionan por el marcado "semántico" reconozcan que en algunos casos las etiquetas antiguas eran más semánticamente correctas que cualquier otra alternativa. Si el texto de un documento hace referencia a ciertas palabras subrayadas, entonces mostrar esas palabras de cualquier otra manera que no sea subrayando sería semánticamente incorrecto. Si uno está importando texto de un sistema que pone algo de él in a monospaced typefacepero que no distingue por qué, entonces usar uno de los "reemplazos" <tt>implicaría falsamente que el código que realiza la importación sabía más de lo que sabía sobre el propósito.
Supercat

Estoy de acuerdo con la idoneidad de by ien contextos matemáticos (y físicos), pero dicho uso no se menciona en borradores HTML5. Cuando planteé esta pregunta, me respondieron seriamente que en su lugar se usarían los caracteres especiales Unicode (letras en negrita matemática y letras en cursiva matemática).
Jukka K. Korpela

1
@supercat: el reclamo general (que reconozco que no siempre es aplicable) es que no debe emitir cheques que el agente de usuario no pueda cobrar. En particular, no debe escribir una página que diga que el lector de pantalla de alguien hablará en una fuente monoespaciada (imagino que una voz de robot sería apropiada: en realidad nunca he usado un lector de pantalla). Por supuesto, esto ignora que las páginas de la mayoría de las personas no funcionan en lo más mínimo en lectores de pantalla, por lo que no tiene sentido que paguen ningún precio por una accesibilidad hipotética que no les importa. Pero el W3C descuida deliberadamente ese hecho como una cuestión de principios.
Steve Jessop

En el caso de la importación de código, supongo que la respuesta canónica (si no es satisfactoria) es class="source-X-asserts-it-should-be-monospace", distinguiéndolo así del texto que es semánticamente diferente en el sentido de que alguna otra fuente afirma por razones desconocidas que debería ser monoespacio. En efecto, esto es auditar las cosas que HTML considera malas, en lugar de simplemente traducir la maldad al HTML.
Steve Jessop

1
@SteveJessop: En otras palabras, deberíamos mejorar <TT>, lo que sugirió directamente que el texto se establezca en una fuente monoespacial contrastante, con un marcado que, después de unas pocas capas de indirección, indicará que el texto debe mostrarse en una fuente particular que sucede a ser monoespacio. Mientras que yo no esperaría que todos los lectores de pantalla para hacer algo útil con <tt>, yo esperaría que tendrían un tiempo mucho más fácil con <tt>que <span class="styleNameThisImportUtilityPicked">.
Supercat

0

Los principios de diseño que subyacen a las etiquetas HTML es que deben ser "semánticos", es decir, deben indicar significado e intención en lugar de instrucciones de bajo nivel.

La prueba clásica es "¿se pueden usar significativamente las etiquetas en un navegador para invidentes"?

Por lo tanto, para un navegador basado en audio, la "i" para cursiva es bastante inútil ya que no se puede tener una cursiva. Sin embargo, la etiqueta "em" es significativa ya que un dispositivo de audio puede enfatizar una frase de muchas maneras: aumentando el tono, aumentando el volumen o cambiando el acento. Un renderizador Braille podría enfatizar elevando los puntos cambiando el espacio, cambiando el tamaño o agregando vibración.


Como usted dice, no puede tener una escritura en cursiva, pero puede tener texto en cursiva donde el hecho de que esté en cursiva tiene un significado semántico, por ejemplo, ecuaciones ...
SAL

2
"Por lo tanto, para un navegador basado en audio, la" i "para cursiva es bastante inútil ya que no se puede escribir en cursiva". ... Sí, y así es <img>porque no puedes hablar una imagen, y un sistema sin hardware de sonido no puede presentarse <audio>. A veces, la presentación es el propósito de un elemento, y no necesita ser universalmente compatible (y a diferencia de otros elementos potencialmente no compatibles, <i>no necesita texto alternativo porque el hecho de que esté en cursiva es la única información perdida). El verdadero problema es cuando las personas dicen icuándo quieren decir em .
nmclean

@SAL: ¿Por qué no se puede tener "habla en cursiva"? Si el habla normal se habla con un valor de "tono" de 100, el texto dentro de una <i>etiqueta usa un tono de 120 y el texto dentro de una <b>etiqueta usa 80, y el texto dentro de una <tt>sincronización del discurso con una máquina de escribir sintetizada que produce el texto permitiría al oyente para distinguir fácilmente esas formas de marcado. El trabajo sería mucho más difícil si, en lugar de usar una <i>etiqueta, el texto usara algo <span class="whatever">que causara que partes del texto se mostraran usando "Acme SemiScript" en lugar de "Waldorf Sans" [algunas familias de fuentes ...
supercat

... no tiene una buena fuente en cursiva, pero a veces una fuente solo en cursiva puede verse bien cuando se configura dentro del texto escrito con otra familia de fuentes].
Supercat

@supercat Estás describiendo un discurso enfatizado, no un discurso en cursiva. Si quieres un tono diferente, entonces debes usar em, como dijo nmclean. Si lo quieres en cursiva, usa i. No importa que un lector de pantalla no sepa qué hacer, porque no tiene nada que hacer. Los títulos de los libros suelen estar en cursiva, pero no los pronuncia de manera diferente.
DCShannon
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.