strong span negrita css xhtml accessibility semantic-markup screen-readers

css - span - ¿Cuándo usar<strong> y cuándo usar<b>?



span html (6)

¿Cómo podemos saber cuándo el cliente quiere poner énfasis en el texto y cuándo solo quiere poner el texto en negrita para fines de presentación / estética?

Lea el texto del cliente con comprensión .

  • use <strong> cuando el contexto dice que el texto en negrita es más importante que el otro (y está en línea)
  • use <b> si solo debe estar en negrita (incluso en la base de datos, el lector de fuentes o sin hojas de estilo). En este caso, se puede usar la audacia para llamar la atención de los lectores.

En caso de duda, pregunte al cliente qué quiso decir.

Para ahorrarle a usted y a usted una molestia, pídale al cliente que use estilos de formato en su editor. Esta es una característica muy útil, lástima que haya pocas personas que sepan qué es esta característica.

Editar:

Esto es fuerte y esto es audaz . ¿Alguna diferencia?

Todos los problemas comienzan aquí. Si los colores strong estuvieran por defecto en color ROJO (sin marca roja en SO), y peso normal, no habría preguntas como esta.

Posible duplicado:
¿Está bien usar <strong> en lugar de <b> a ciegas?

¿Cuándo usar <strong> y cuándo usar <b> u otras formas de dar un aspecto en negrita? strong tiene un valor semántico (y útil para el lector de pantalla mientras que b es una presentación (e incluso es válido en HTML 5).

mi pregunta no es cuál es la diferencia entre strong y b .

La pregunta es cuándo usar la etiqueta semántica y cuándo usar solo el texto en negrita

¿Debo usar siempre <strong> si los archivos de contenido del cliente (archivos MS word) tienen algunas palabras en negrita en los párrafos de contenido?

texto alternativo http://shup.com/Shup/365676/11051764618-My-Desktop.png

¿Cómo podemos saber cuándo el cliente quiere poner énfasis en el texto y cuándo solo quiere poner el texto en negrita para fines de presentación / estética?

Si es el trabajo del cliente decirnos, entonces, ¿cómo explicar este escenario al cliente para que nos brinde información clara sobre "cuándo solo quiere que el texto aparezca en negrita para fines de presentación / estética"?


El uso de CSS para definir un estilo que no sea el predeterminado en negrita para una etiqueta <strong> es comprensible.

Usar CSS de la misma manera en una etiqueta <b> sería más cuestionable.


No hay una respuesta "correcta" para esto (que es probablemente la razón por la que el marcado semántico no está en buen estado).

Dependiendo de la forma en que funcione su cliente, diría que su propuesta de reemplazar el contenido en negrita en los párrafos con <strong> , y todo lo demás con estilos de encabezado relevantes, es razonable. Puede ser una buena idea muestrear los documentos para establecer qué práctica se ha utilizado.


Primero pregunte al cliente "¿por qué ha resaltado estas palabras?" y úsalo para informar tu decisión. Si no puede obtener una respuesta clara, usaría <B>, ya que es mejor no dar a entender que hay palabras semánticas en las palabras resaltadas cuando en realidad no hay ninguna. El uso de <B> se puede usar como una clara indicación de que tiene un marcado de presentación insatisfactorio y, por lo tanto, es útil para los futuros mantenedores que se puede corregir libremente a la luz de nueva información sobre el motivo del resaltado.


Si está haciendo una conversión de un documento de Word a HTML, creo que <b> es una mejor opción, porque está expresando el hecho de que el texto estaba en negrita en el documento de Word. Word usa estilos para aplicar el significado semántico, por lo tanto, si está marcado con el estilo "Fuerte", entonces usa la etiqueta <strong> en el HTML.


Siempre he seguido una simple regla de oro:

  • <strong> significa "énfasis fuerte", e implica ningún estilo visual particular . Tiene significado semántico, pero podría parecerse a cualquier cosa.
  • <b> se utiliza para aplicar un efecto visual en negrita al texto, pero es una etiqueta de presentación como <font> y, por lo tanto, debe evitarse ( cuando sea posible ) a favor de CSS.