Guía de Estilo

Hasta ahora, intentar estilizar un artículo, documento o publicación de blog con Tailwind ha sido una tarea tediosa que requería un ojo agudo para la tipografía y mucho CSS personalizado complejo.

Por defecto, Tailwind elimina todo el estilo predeterminado del navegador de párrafos, encabezados, listas y más. Esto resulta ser realmente útil para construir interfaces de usuario de aplicaciones porque pasas menos tiempo deshaciendo los estilos del agente de usuario, pero cuando realmente estás intentando estilizar algún contenido que proviene de un editor de texto enriquecido en un CMS o un archivo markdown, puede ser sorprendente y poco intuitivo.

De hecho, recibimos muchas quejas al respecto, con personas que regularmente nos preguntan cosas como:

¿Por qué Tailwind elimina los estilos predeterminados en mis elementos h1? ¿Cómo desactivo esto? ¿Qué quieres decir con que también pierdo todos los demás estilos base? Te escuchamos, pero no estamos convencidos de que simplemente desactivar nuestros estilos base sea lo que realmente quieres. No quieres tener que eliminar márgenes molestos cada vez que usas un elemento p en una parte de la interfaz de tu panel. Y dudo que realmente quieras que tus publicaciones de blog usen los estilos del agente de usuario tampoco: quieres que se vean increíbles, no horribles.

El plugin @tailwindcss/typography es nuestro intento de darte lo que realmente quieres, sin ninguno de los inconvenientes de hacer algo tonto como desactivar nuestros estilos base.

Agrega una nueva clase prose que puedes aplicar a cualquier bloque de contenido HTML estándar y convertirlo en un documento hermoso y bien formateado:

<article class="prose">
  <h1>Pan de ajo con queso: Lo que dice la ciencia</h1>
  <p>Durante años, los padres han promovido los beneficios para la salud de comer pan de ajo con queso a sus hijos, con el alimento ganando un estatus tan icónico en nuestra cultura que los niños a menudo se disfrazan de un pan cálido y con queso para Halloween.</p>
  <p>Pero un estudio reciente muestra que el aperitivo celebrado puede estar relacionado con una serie de casos de rabia que surgen en todo el país.</p>
</article>

Para más información sobre cómo usar el plugin y las características que incluye, lee la documentación.

Qué esperar de aquí en adelante

Lo que sigue a partir de aquí es solo un montón de tonterías absolutas que he escrito para probar el plugin en sí. Incluye todos los elementos tipográficos sensatos que se me ocurrieron, como texto en negrita, listas desordenadas, listas ordenadas, bloques de código, citas, e incluso cursivas.

Es importante cubrir todos estos casos de uso por algunas razones:

1. Queremos que todo se vea bien desde el principio.
2. Realmente solo la primera razón, ese es todo el punto del plugin.
3. Aquí hay una tercera razón ficticia, aunque una lista con tres elementos parece más realista que una lista con dos elementos.

Ahora vamos a probar otro estilo de encabezado.

La tipografía debería ser fácil

Así que ese es un encabezado para ti; con suerte, si hemos hecho bien nuestro trabajo, eso se verá bastante razonable.

Algo que una persona sabia me dijo una vez sobre la tipografía es:

La tipografía es bastante importante si no quieres que tus cosas se vean como basura. Hazlo bien y no será malo.

Probablemente también sea importante que las imágenes se vean bien aquí por defecto:

Contrario a la creencia popular, Lorem Ipsum no es simplemente texto aleatorio. Tiene raíces en un fragmento de literatura clásica en latín del 45 a.C., lo que lo hace tener más de 2000 años de antigüedad.

Ahora voy a mostrarte un ejemplo de una lista desordenada para asegurarme de que eso también se vea bien:

• Aquí está el primer elemento de esta lista.
• En este ejemplo, mantenemos los elementos cortos.
• Más tarde, usaremos elementos de lista más largos y complejos.

Y ese es el final de esta sección.

¿Qué pasa si apilamos encabezados?

También deberíamos asegurarnos de que eso se vea bien.

A veces tienes encabezados directamente uno debajo del otro. En esos casos, a menudo tienes que deshacer el margen superior en el segundo encabezado porque generalmente se ve mejor que los encabezados estén más cerca entre sí que un párrafo seguido de un encabezado.

Cuando un encabezado viene después de un párrafo…

Cuando un encabezado viene después de un párrafo, necesitamos un poco más de espacio, como ya mencioné anteriormente. Ahora veamos cómo se vería una lista más compleja.

• A menudo hago esto donde los elementos de la lista tienen encabezados.

  Por alguna razón, creo que esto se ve genial, lo cual es desafortunado porque es bastante molesto lograr que los estilos sean correctos.

  A menudo tengo dos o tres párrafos en estos elementos de lista también, por lo que la parte difícil es lograr que el espaciado entre los párrafos, el encabezado del elemento de lista y los elementos de lista separados tengan sentido. Bastante difícil, honestamente, podrías argumentar fuertemente que simplemente no deberías escribir de esta manera.

• Dado que esta es una lista, necesito al menos dos elementos.

  Ya expliqué lo que estoy haciendo en el elemento de lista anterior, pero una lista no sería una lista si solo tuviera un elemento, y realmente queremos que esto se vea realista. Por eso he agregado este segundo elemento de lista para que realmente tenga algo que mirar al escribir los estilos.

• Tampoco es una mala idea agregar un tercer elemento.

  Creo que probablemente habría estado bien usar solo dos elementos, pero tres definitivamente no es peor, y como parece que no tengo problemas para inventar cosas arbitrarias para escribir, también podría incluirlo.

Después de este tipo de lista, generalmente tengo una declaración o párrafo de cierre, porque se ve un poco raro saltar directamente a un encabezado.

El código debería verse bien por defecto.

Creo que la mayoría de las personas van a usar highlight.js o Prism o algo similar si quieren estilizar sus bloques de código, pero no estaría de más hacer que se vean bien desde el principio, incluso sin resaltado de sintaxis.

Aquí está cómo se ve un archivo tailwind.config.js predeterminado en el momento de escribir esto:

module.exports = {
  purge: [],
  theme: {
    extend: {}
  },
  variants: {},
  plugins: []
}

Espero que eso te parezca lo suficientemente bien.

¿Qué pasa con las listas anidadas?

Las listas anidadas básicamente siempre se ven mal, por lo que editores como Medium ni siquiera te permiten hacerlas, pero supongo que como algunos de ustedes van a hacerlo, tenemos que cargar con la responsabilidad de al menos hacer que funcionen.

1. Las listas anidadas rara vez son una buena idea.
   • Podrías sentir que estás siendo realmente "organizado" o algo así, pero solo estás creando una forma desagradable en la pantalla que es difícil de leer.
   • La navegación anidada en las interfaces de usuario también es una mala idea, mantén las cosas lo más planas posible.
   • Anidar toneladas de carpetas en tu código fuente tampoco es útil.
2. Dado que necesitamos más elementos, aquí hay otro.
   • No estoy seguro de si nos molestaremos en estilizar más de dos niveles de profundidad.
   • Dos ya es demasiado, tres está garantizado que será una mala idea.
   • Si anidas cuatro niveles de profundidad, perteneces a la cárcel.
3. Dos elementos no son realmente una lista, tres está bien.
   • Nuevamente, por favor no anides listas si quieres que las personas realmente lean tu contenido.
   • Nadie quiere mirar esto.
   • Estoy molesto de que incluso tengamos que molestarnos en estilizar esto.

Lo más molesto de las listas en Markdown es que los elementos <li> no reciben una etiqueta <p> hija a menos que haya varios párrafos en el elemento de lista. Eso significa que también tengo que preocuparme por estilizar esa situación molesta.

• Por ejemplo, aquí hay otra lista anidada.

  Pero esta vez con un segundo párrafo.

  • Estos elementos de lista no tendrán etiquetas <p>
  • Porque son solo una línea cada uno

• Pero en este segundo elemento de lista de nivel superior, sí las tendrán.

  Esto es especialmente molesto debido al espaciado en este párrafo.

  • Como puedes ver aquí, porque he agregado una segunda línea, este elemento de lista ahora tiene una etiqueta <p>.

    Esta es la segunda línea de la que estoy hablando, por cierto.

  • Finalmente, aquí hay otro elemento de lista para que sea más como una lista.

• Un elemento de lista de cierre, pero sin lista anidada, porque ¿por qué no?

Y finalmente una oración para cerrar esta sección.

Hay otros elementos que necesitamos estilizar

Casi olvido mencionar los enlaces, como este enlace al sitio web de Tailwind CSS. Casi los hicimos azules, pero eso es tan de ayer, así que optamos por gris oscuro, se siente más atrevido.

Incluso incluimos estilos para tablas, échales un vistazo:

También necesitamos asegurarnos de que el código en línea se vea bien, como si quisiera hablar sobre elementos <span> o contarte las buenas noticias sobre @tailwindcss/typography.

A veces incluso uso code en encabezados

Aunque probablemente sea una mala idea, e históricamente he tenido dificultades para hacer que se vea bien. Este truco de "envolver los bloques de código en backticks" funciona bastante bien, en realidad.

Otra cosa que he hecho en el pasado es poner una etiqueta code dentro de un enlace, como si quisiera contarte sobre el repositorio tailwindcss/docs. No me encanta que haya un subrayado debajo de los backticks, pero absolutamente no vale la pena la locura que requeriría evitarlo.

Aún no hemos usado un h4

Pero ahora lo hemos hecho. Por favor, no uses h5 o h6 en tu contenido, Medium solo admite dos niveles de encabezado por una razón, animales. Honestamente, consideré usar un pseudo-elemento before para gritarte si usas un h5 o h6.

No los estilizamos en absoluto desde el principio porque los elementos h4 ya son tan pequeños que tienen el mismo tamaño que el texto del cuerpo. ¿Qué se supone que hagamos con un h5, hacerlo más pequeño que el texto del cuerpo? No, gracias.

Aún necesitamos pensar en encabezados apilados.

Asegurémonos de no arruinar eso con elementos h4, tampoco.

Uf, con suerte hemos estilizado los encabezados anteriores a este texto y se ven bastante bien.

Agreguemos un párrafo de cierre aquí para que las cosas terminen con un bloque de texto de tamaño decente. No puedo explicar por qué quiero que las cosas terminen de esa manera, pero tengo que asumir que es porque creo que las cosas se verán raras o desequilibradas si hay un encabezado demasiado cerca del final del documento.

Lo que he escrito aquí probablemente sea lo suficientemente largo, pero agregar esta última oración no puede hacer daño.

Markdown con estilo GitHub

También he agregado soporte para Markdown con estilo GitHub usando remark-gfm.

Con remark-gfm, obtenemos algunas características adicionales en nuestro markdown. Ejemplo: literales de enlace automático.

Un enlace como www.example.com o https://example.com se convertiría automáticamente en una etiqueta a.

Esto también funciona para enlaces de correo electrónico: contact@example.com.