Sergio Xalambrí

Escribiendo CSS de la forma correcta

Como desarrollador FrontEnd me encuentro constantemente utilizando CSS. Este lenguaje para dar estilos a páginas web tiende a empezar siendo algo simple y volverse muy complicado conforme avanza el desarrollo del sitio (mantener 100 líneas de CSS es fácil, mantener decenas de miles no).

Para evitar este tipo de problemas fui desarrollando distintas prácticas para mejorar mi código, probando prácticas usadas por otros desarrolladores e incorporando lo que me resultaba útil a mi flujo de trabajo.

Las siguientes son todas las prácticas que fui desarrollando con el tiempo, como aclaración utilizo el pre-procesador LESS por lo que mucho de lo que sigue está basado en que se utilizan pre-procesadores.

Sintaxis

Empecemos hablando de la sintaxis, cada desarrollador comúnmente tiene las suyas propias dependiendo de donde aprendieron y se suelen quedar con esa sintaxis.

Con el tiempo fui desarrollando mi propia sintaxis para escribir el código, algunas de las reglas que definí son:

Orden de declaración

Para el orden de declaración me resulta mucho más cómodo usar el orden alfabético, esto resulta muy cómodo para poder buscar luego una propiedad, por ejemplo si querés buscar un z-index sabes que siempre está al final de las declaraciones. Otra razón para usar este orden es que algunos editores (como Sublime Text) tienen una opción para ordenar alfabéticamente tocando una sola tecla o con dos clicks.

@imports

En CSS tradicional los @import son anecdóticos, son más lentos de cargar que un <link> en el HTML y no unen de verdad el CSS, sino que hace una nueva petición al servidor para bajar el segundo CSS.

En los pre procesadores en cambio el @import se vuelve una herramienta muy poderosa ya que estos son utilizados por los compiladores para buscar una segunda hoja de estilos e incorporarla al CSS final, quedando un único CSS que combina muchos archivos de LESS.

Media queries

Para ubicar las media queries hay muchas formas diferentes, una de las primeras es colocar los media queries al final del documento fijándote en cada archivo individualmente, otra es crear 3 media queries (mobile, tablets y desktop) y ubicar los estilos que aparecen en 2 o más de las versiones fuera de las media queries y en la que no modificar esa regla desde la media query.

Actualmente el método que utilizo consiste en colocar justo después de cada selector la media query de ese selector, gracias a los pre procesadores puedo colocar la media query dentro del selector como si fuese otra declaración.

Prefijos

Para esto también hay muchas opciones, una muy buena es usar prefix-free de Lea Verou, otra es usar mixins dentro del pre procesador que se encarguen de agregar los prefijos de cada navegador y por último usar algún plugin para tu editor que los agregue por vos.

Para sitios me parece mejor la segunda opción, el uso de mixins. Dejo siempre una lista de mixins para todas las propiedades que tengas prefijos para poder usarlas fácilmente en cualquier proyecto.

Para aplicaciones en cambio es preferible usar prefix-free y olvidarse de los prefijos, aunque tengas que cargar otro archivo JS, este solo pesa 2kb y te ahorra muchas líneas de CSS.

Declaraciones multi línea e individuales

Cuando se declaran las propiedades de un estilo estas las coloco siempre en su propia línea, quedando la primer línea del selector y la llave de apertura ({), cada propiedad en una línea propia y una última línea para la llave de cierre (}).

En el caso de estilos de una sola propiedad coloco todo en una sola línea dejando un espacio entre las llaves y la declaración.

Propiedades abreviadas

Muchas veces se aconseja el uso de las propiedades abreviadas para reducir la cantidad de líneas de código, usar margin: x x x x; en vez de declarar cada margen por separado.

Esto es genial cuando se quieren declarar los estilos para todos los márgenes (o paddings, o propiedades del background o lo que sea) pero cuando solo necesitas declarar el margen inferior (por poner un ejemplo) esto no tiene mucho sentido ya que estarías declarando todos los márgenes solo para declarar uno solo.

Para esto es mejor usar la forma no abreviada (margin-bottom en el ejemplo) y dejar la forma abreviada para cuando tenga sentido.

Anidación

Es mejor tratar de evitar la anidación siempre que se pueda, en lugar de anidar es mucho mejor crear clases con prefijos, por ejemplo .btn y .btn-success es mejor que tener .btn y .btn .success.

Solamente considero que vale la pena anidar cuando querés dar estilos a una etiqueta directamente sin usar clases (cosa que es mejor tratar de evitar de todas formas).

Comentarios

Los comentarios tienen que ser simples, de una línea y no más de 80 columnas. Tiene que haber al menos un comentario por cada modulo o componente creado explicando para que sirve ese componente.

Las clases de utilería también tiene que tener un pequeño comentario explicando su función.

Nombre de clases

Los nombres de las clases deben estar en inglés siempre, y para los nombres de clases la mejor metodología que encontré es usar la siguiente estructura:

.moduleName-subElement {
}
.moduleNamemodifier {
}
.moduleName.is-state {
}

Para las clases de utiliería quedarían:

.u-name {
}
.u-name-xs {
}
.u-name-sm {
}
.u-name-md {
}
.u-name-lg {
}

Un ejemplo:

.btn {
}
.btnlg {
}
.btnsuccess {
}
.btn-icon {
}
.btn.is-disabled {
}

Como ven en el ejemplo tenemos un botón, que puede estar modificado para ser grande o ser un botón de éxito, dentro puede tener un ícono y también puede estar desactivado.

Organización

Por último la organización del código, para esto uso la metodología de SMACSS que propone dividir el código de la siguiente forma:


Esta es la forma que, con el tiempo, encontré más cómoda para escribir mi código en CSS, tratando de reutilizar código y de mantener un código lo más organizado posible.