Cómo crear una hoja de estilo.
Buenos hábitos.

A pesar de que las CSS son relativamente fácil y escribir, pueden resultar complicadas de mantener. La especificidad, el alcance global y la falta de orientación nos puede fácilmente conducir a la inconsistencia, a la duplicación de código y al exceso de compilación.

En mis consultorías como desarrollador front end freelance doy máxima prioridad a la tarea de organización y estructura de los estilos. Es mi punto cero.  Aquí voy a compartir una serie de recomendaciones que viene de mi experiencia junto con las expectativas que tengo hacia mi visión de hojas de estilo bien organizadas y documentadas. Esto te puede ayudar a ir más rápido, lo que significa menos frustración y una mayor productividad.

En ocasiones he tenido que leer código de otro desarrollador, o peor aún, de un conjunto de desarrolladores, encontrándome con el intento de averiguar qué se pretendía hacer, por qué no se hizo de otra manera, por qué tanta complejidad. ¡¡Es una lucha con mucho dolor!!

Cómo crear una hoja de estilo correcta

Así que vamos a ver esos pilares sobre el cual se basa un código CSS bien hecho, documentado y estructurado.

Niveles de comentarios

Cuando llega el momento de modificar una hoja de estilo que llevas semanas, meses o incluso años sin abrirla, es posible que te preguntes, “¿Por qué he creado este estilo? ¿Qué hace?”. Como en cualquier proyecto, es buena práctica dejar notas para contestar sobre lo que hiciste y por qué. Afortunadamente no es necesario hacerse de un bloc de notas sino que usamos directamente los comentarios de CSS.

Los comentarios pueden tener la longitud máxima de un tweet (140 caracteres), tampoco es necesario comentar todo ya que propiedades como color, familia de fuentes, color del borde, etc., se explican por sí mismas. Pero sí es útil un comentario cuando un estilo no resulta ser tan obvio.

Personalmente uso 3 niveles de comentarios:

Comentarios Nivel 1

El comentario que yo defino de nivel 1 se encarga de encabezar la hoja de estilo y definir su cometido.

/* -----------------------------------------------------------------------------
 * BUTTONS
 * ----------------------------------------------------------------------------- */

Pongamos el caso que quieres definir los estilos de unos botones y te creas una hoja de estilo para ellos (buttons.css). En tu primera línea definirás un comentario con la sintaxis que te propongo arriba.

Comentarios Nivel 2

Un comentario de nivel 2 encabeza variaciones de estilos del componente que estás estilando.

/* Alternate buttons
 * ----------------------------------------------------------------------------- */

En este caso podrías utilizar el nivel 2 para definir botones de diferentes colores y tamaños.

Comentarios Nivel 3

El último nivel de comentario te sirve para dejar cualquier nota que resulte útil para comprender un estilo: :disabled, :hover, :focus, etc.

/* Disabled */

Un ejemplo completo podría ser:

See the Pen ayrpqY by Marco (@marco3w) on CodePen.dark

Convenciones de escritura en CSS

Cuanto más escribes hojas de estilo, más valoras el uso de las convenciones. La nomenclatura es una de las actividades más difíciles y disputadas por un desarrollador. ¡Llega casi a ser todo un arte!

Existen convenciones que puedes seguir como BEM, OOCSS, SMACSS o ACSS. He visto casos, y yo mismo lo he hecho dentro de algunos grupos de trabajo, en los que se aplican los principios de estas metodologías pero donde se modifican sus reglas basándose en las preferencias de los desarrolladores involucrados. En este caso documentar qué reglas seguir es una buena práctica para crear un código robusto y extensible sin quebraderos de cabeza.

Esto nos lleva a una cuestión más amplia de guías de estilo CSS. La convención en la nomenclatura solo es una parte de la estrategia de nuestro CSS. Existen más partes que pueden ser:

  • ¿Cómo dividir el código?
  • ¿Cómo estructurar los ficheros?
  • ¿Cómo ordenar las propiedades?
  • ¿Cómo formatear el código (sangría, declaraciones de las reglas)?
  • ¿Cómo vincular clases CSS y JavaScript?

…y otras reglas como:

  • No anidar más de 3 niveles de profundidad.
  • Evitar los selectores con ID.
  • Utilizar !important solamente para clases de utilidad.
  • etc.

Todo este conjunto constituye una guía de estilo CSS completa. Crear un estándar en la estructura y un estilo de programación ayudará a tener una lectura fluida del código. Equivale a decir que un vocabulario común entre los desarrolladores de un mismo grupo de trabajo genera una total coherencia.

Arquitectura CSS

La mayoría de los proyectos escalables siguen algún tipo de arquitectura en términos de ordenación de estilos. En un código bien documentado, se deben mencionar los principios fundamentales que el proyecto sigue para estructurar y dividir estilos, por ejemplo cómo organizar los CSS externos.

Harry Roberts en una charla acerca de la gestión de CSS en un proyecto nos deja estas palabras:

La arquitectura de las CSS en este momento parece estar de moda. Es algo que sin duda has escuchado mencionar muchas veces durante el último año, y con razón: las UIs (y los equipos que las construyen) se están volviendo más grandes y complicadas que nunca.

Hay una serie de aspectos en las CSS que las hacen problemáticas. Son declarativas, lo cual significa que no hay lógica o flujo de control para contarle a otros desarrolladores acerca del estado o de la construcción del proyecto. Funciona en un espacio de nombres globales, lo que significa que tendremos colisiones, fuga de estilos y regresiones involuntarias. Utiliza herencias, haciendo que todo sea algo interdependiente y frágil. Por último, el inevitable modelo de especificidad puede causar problemas cuando los selectores luchan entre sí por el protagonismo.

Lo que Harry introduce es un concepto para la arquitectura de CSS llamado ITCSS. Si estás trabajando en un proyecto de grandes dimensiones, es probable que alguien ya haya definido principios o ideas similares que buscan resolver estos problemas. Así que en un código bien documentado es bueno dejar constancia de esto en alguna parte.

Un tweet que leí hace poco viene al caso:

“Observa patrones, no excepciones. El aficionado ve la excepción. El profesional ve la regla.”

Resumiendo, una buena arquitectura se considera lo suficientemente clara cuando responde a la pregunta: ¿Dónde añado nuevos estilos o una nueva hoja de estilo?

Componentes CSS: descripción y ejemplos

Una de las buenas prácticas más comunes es separar los módulos lógicos en componentes CSS (o “bloques” según BEM). Algunos de ellos pueden ser reutilizables, otros no. Lo importante es que sean los componentes básicos de nuestro proyecto. Por lo tanto, describir lo que son debe ser una prioridad máxima en un código bien documentado.

Lo ideal sería organizarlos, agruparlos, nombrarlos y establecer reglas entre estos componentes para generar un resumen de todos. Un componente CSS bien descrito no sólo incluye información sobre lo que hace el componente, sino que también incluye otra información valiosa como el marcado HTML de ejemplo y el contexto en el que debe ser utilizado. Si vamos un paso más allá llegamos a la cuestión de las Librerías de Patrones. Una librería (o biblioteca) de patrones es una colección de componentes reutilizables que se pueden emplear de forma conjunta para crear un sitio web.

Con un sistema modular, la arquitectura basada en componentes aporta un gran valor a tu proyecto.

El objetivo de una biblioteca de patrones es mostrar lo que se puede construir con los patrones (componentes) existentes. Vamos a echar un vistazo a la información adicional que además se podría mostrar junto a cada patrón.

Vitaly Friedman compartió un buen resumen sobre cómo llevar la biblioteca de patrones un nivel más allá. Argumenta que concentrarse en los componentes no es suficiente:

Uno de los principales problemas con las librerías de patrones es que, aunque proporcionan una visión general de los componentes, a menudo dejan mucho espacio a la interpretación. Los componentes pueden combinarse de diversas maneras, de forma consistente e inconsistente. Es fantástico poder ver qué tipo de botones e iconografía tenemos a disposición y qué tipos de tablas y etiquetas de precios se pueden usar, pero ¿qué pasa si necesitas diseñar o construir una interfaz que contenga todos estos componentes a la vez, y quizás otro que aún no exista en la biblioteca?

Una lista de módulos por sí sola no transmitirá ningún contexto o especificación sobre cómo los módulos deben (y no deben) ser utilizados.

En base al post de Friedman y la Anatomía de un patrón en una biblioteca de patrones de Brad Frost, aquí van algunas ideas que tal vez podría acompañar cada uno de nuestros patrones, a parte de su nombre exclusivo, una muestra de código HTML y una descripción del propósito del componente.

Básicas

  • Etiquetas o categorías: Las etiquetas o categorías asignadas para el componente. Los desarrolladores podrían etiquetar sus componentes con etiquetas de estado como: en curso, en revisión, aprobado, etc.
  • Previsualización responsive: Vista previa real y redimensionable del componente utilizando el fragmento de código que se utiliza en producción. Como alternativa, una captura de pantalla.
  • Contexto, versiones, miembros del equipo involucrados o responsables. En un gran equipo, la propiedad de los componentes y qué miembros del equipo los han estado desarrollando activamente podrían ser realmente útiles para el mantenimiento y desarrollo futuro.

Avanzadas

  • Impacto en el rendimiento: A veces el CSS puede resultar pesado. Un indicador de rendimiento o una sección de “señales de advertencia” que describe no sólo el impacto del rendimiento, sino también los contratiempos más comunes cuando el patrón se utiliza incorrectamente.
  • Implicaciones de accesibilidad: Indicador de los requisitos de accesibilidad. Algunos componentes pueden requerir más trabajo para mantener la accesibilidad, especialmente si interactúan con otros componentes.
  • Componentes relacionados: Una rápida visión general de los componentes relacionados o de la familia de componentes a la que pertenece un componente determinado. Podrías usar una explicación de cuándo usar un componente, cuándo no y por qué.
  • Proponer alternativas de otros componentes cuando existen.

La lista puede seguir y seguir hasta donde tenga sentido para su caso de uso específico.

Conclusiones

Un código CSS bien documentado refuerza su consistencia, aumenta la capacidad de mantenimiento y ayuda al equipo a construir un vocabulario compartido. Debe entrar en tus hábitos como prerrequisito para el diseño y desarrollo eficiente de CSS. Además, basándome en mi experiencia, indudablemente conduce a un mejor rendimiento. Soy un gran fan de estos principios porque son la garantía de una ejecución profesional de un proyecto.

¿Tienes alguna otra sugerencia para mejorar estos hábitos para escribir un buen código CSS? Deja tu comentario y estaré agradecido.

Éste post ha sido creado sobre la base de What Does a Well-Documented CSS Codebase Look Like?

Photo by Vladimir Kudinov

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *