Media queries, OOCSS y SASS

Por Ernesto Jiménez · 7 marzo, 2014
Publicado en Diseño web
media-queries-oocss

Desde que me hice mi propio framework de CSS he seguido la práctica habitual de reunir todas las media queries al final del resto de reglas.

Al principio, cuando me basé en Less Framework definía por defecto los módulos para pantallas grandes y después hacía los ajustes para dimensiones menores.

Después adopté SASS y mejoré la estructura de archivos agrupando las reglas CSS por categorías: una clasificación tímida, en la que me limité a separar un archivo de reset, la maqueta, módulos y tipografía. Las media queries seguían cayendo al final del documento.

Entonces descubrí Hammer for Mac para compilar los archivos SASS y, con él, el framework Rock Hammer de Andrew Clarke. Su enfoque mejoraba la manera de trabajar en dos puntos clave:

1. primero definimos los estilos para la versión móvil y después ampliamos a pantallas más grandes (mobile first)
2. establecía variables de SASS para definir los breakpoints

¿Sabéis dónde quedaban estas reglas? Exacto, al final del archivo .css.
En paralelo a esta evolución fui poniendo en orden todos estos conceptos bajo el enfoque de OOCSS con el imprescindible libro SMACSS (Scalable and Modular Architecture for CSS), de Jonathan Snook.

Media queries y OOCSS

La separación de código que propone el CSS orientado a objetos mejora el flujo de trabajo y acaba con muchas pesadillas en el mantenimiento de nuestros estilos. ¿Cuál es la mejor manera de tratar las media queries bajo este enfoque? La intención es mantener los estilos que pertenecen a un elemento concreto con el resto de reglas que lo definen.

De esta manera lo óptimo sería:

Así si tenemos que modificar el módulo .boton-secundario nos encontramos con su definición completa en un mismo lugar. Desde luego es una tarea repetitiva pero aquí viene SASS para salvarnos, una vez más.
Podemos definir el módulo:

Y anidado en su definición añadir la media query para escritorio:
Así tendríamos nuestro módulo claramente definido en un mismo bloque de código.
Esto da como resultado:

Sea cual sea el módulo estará definido en un archivo en nuestra carpeta de módulos. Podemos dejar los archivos de breakpoints para definir los elementos generales del sitio, los que afectan a la estructura de la maqueta general, los de layout.

Un mixin para atraerlos a todos

Si habéis creado variables para definir los breakpoints (bp2: 30 em, bp3: 37.5 em) podéis crear un mixin que reconozca estas variables:
Con esto podremos definir nuestro módulo completamente:


Jonathan Snook recomienda poner cada módulo en un archivo independiente y en él las reglas que modifican al propio módulo, incluyendo las media queries. El uso de este mixin nos ayuda en esta tarea y conservamos la flexibilidad del uso de las variables que de definen los breakpoints de nuestro proyecto.

¿Te ha gustado el post? Puedes seguirme en Twitter o en Facebook donde seguimos hablando de estrategia de contenidos y marketing digital