Si has usado algún framework de CSS, algún componente de jQuery UI o el último script para hacer sliders responsive sabrás por propia experiencia qué es la clasitis, una enfermedad muy extendida a la que se ha tratado de eliminar de muchas formas. Hoy os propongo la más drástica de todas: la “amputación” de las clases
El problema
Ya hemos visto, en un artículo anterior de Octuweb, que el hecho de escoger qué valores dar a nuestros atributos class puede suponernos un enorme dolor de muelas a los desarrolladores.
No es únicamente por su valor semántico, sino porque en los últimos tiempos, gracias al uso de frameworks css (Bootstrap, Foundation y similares) llegamos a tener tantos valores en el atributo class que es difícil leerlos y menos aún entenderlos.
Harry Roberts introdujo un interesante concepto para trabajar con los nombres de nuestras clases: agrupar los nombres de clases relacionadas dentro de corchetes ( [ ] ) para hacerlos más legibles.
Hubo más personas que sugirieron cosas parecidas: Ben Everard prefiere separar con “/” las clases relacionadas; Stephen Nolan con “|”.
El objetivo que pretenden es loable, hacer el código más legible, mas escaneable, pero creo que este tipo de técnicas demuestran que hay algo que estamos haciendo mal.
Eliminemos las clases
Desde hace unos cuantos años disponemos de una potentísima regla CSS llamada “el selector de atributos separados por espacios”. Veamos un ejemplo, las siguientes dos líneas son iguales, la primera es una definición para una clase a la manera habitual y la segunda con el selector de atributos separados por espacios:
[class~='dat-class'] { /* tus estilos */ };
Lo fabuloso de esta regla es que no está limitado al atributo class. Basándose en ella, Glen Maddern, Ben Schwarz y Ben Smithett han creado el “AMCSS Project” una iniciativa muy interesante que pretende sustituir las clases por los atribute modules o AM. Veamos un ejemplo para entender bien qué son y por qué son útiles. Empezaremos por un típico grid con clases:
.column-1 { /* 1/12 width, flotando */ }
.column-2 { /* 1/6 width, flotando */ }
.column-3 { /* 1/4 width, flotando */ }
.column-4 { /* 1/3 width, flotando */ }
.column-5 { /* 5/12 width, flotando */ }
/* etc */
.column-12 { /* 100% width, flotando */ }
Nada nuevo bajo el sol ¿verdad? Veamos el mismo ejemplo usando AM:
[am-Column~="1"] { /* 1/12 width, flotando */ }
[am-Column~="2"] { /* 1/6 width, flotando */ }
[am-Column~="3"] { /* 1/4 width, flotando */ }
[am-Column~="4"] { /* 1/3 width, flotando */ }
[am-Column~="5"] { /* 5/12 width, flotando */ }
/* etc */
[am-Column~="12"] { /* 100% width, flotando */ }
Vaya, esto es otra cosa ¿no? Lo primero que llama la atención es el prefijo am-. Es el core de AM, y sirve para asegurarnos de que no hay conflictos con atributos ya existentes. Podemos usar el prefijo que queramos, incluso si tenemos que validar nuestro HTML, podemos usar el prefijo data-, la idea es la misma.
Otro aspecto llamativo es que con AM los valores de nuestros atributos pueden ser un número (1,4 ó 12). Como definimos nuestro namespace somos libres de utilizar los valores que queramos y que no colisionarán con ningún otro valor de ningún otro namespace.
Veamos otro ejemplo más, para poder apreciar todas sus ventajas:
[am-Button~="large"] { /* large button styles */ }
[am-Button~="rounded"] { /* round button styles */ }
Vemos una de las principales ventajas de AM. La presencia de un atributo am-Button ya nos sirve para dale estilo. Los valores particulares de am-Button alteran y adaptan esos estilos básicos, sin necesidad de duplicar clases o utilizar el @extend de SASS.
¿Y esto va en serio?
Pues parece que sí. De momento ya han creado una especificación formal, una buena cantidad de documentación y unos cuantos ejemplos de uso con cuatro módulos.
¿Hasta dónde puede llegar esto? ¿Dejaremos de usar clases en nuestros desarrollos? ¿Qué os parece a vosotros?