Software Crafters® 2025 | Creado con 🖤 para elevar el nivel de la conversación sobre programación en español | Legal
¡Me encanta CSS!. Quien me conoce lo sabe, seguro que se notará en este artículo, y estoy orgulloso de ello. No pienso entrar en la guerra de si es un lenguaje de programación o no. Para mí es un lenguaje de estilos y "ATENCIÓN SPOILER" CSS es parte de la Web. Es por ello que me sorprende la gran cantidad de personas que se definen como Frontends o FullStack pero dicen: "Ah! no, yo CSS no lo toco, eso no es programar".
Esa frase da para otro artículo, pero no quiero desviarme del objetivo de este, hablar de CSS para Crafters. Sí, me permito añadir la palabra crafters (artesano/a) junto a CSS. Y espero que al final del artículo consiga convencerte de que realmente podemos añadir artesanía a cualquier cosa que queramos trabajar de forma cuidadosa.
Hojas de Estilo en Cascada (del inglés Cascading Style Sheets) o CSS es el lenguaje de estilos utilizado para describir la presentación de documentos HTML o XML (incluyendo varios languages basados en XML como SVG, MathML o XHTML). CSS describe como debe ser renderizado el elemento estructurado en la pantalla, en papel, en el habla o en otros medios. - MDN web docs
Artesanía se refiere tanto al trabajo de la persona artesana (crafter), como al objeto o producto obtenido en el que cada pieza es distinta a las demás. - Wikipedia
Pero en nuestro contexto vamos a hacer referencia a la Artesanía de Software según la definición del manifiesto de la Artesanía de Software.
Veamos una lista de las cosas a tener en cuenta y herramientas que tenemos disponibles para ser auténticas/os artesanas/os del CSS.
Como en cualquier otro lenguaje de programación, existen guías de estilos. Tiene todo el sentido, ya que una guía de estilo no es más que una convención para escribir código legible, mantenible y escalable por uno o varios equipos.
Hay varias guías de estilos en CSS, y todas ellas propuestas por gente muy influyente en el desarrollo de la web.
Un ejemplo de sintaxis
/* Bad CSS */ .selector, .selector-secondary, .selector[type=text] { padding:15px; margin:0px 0px 15px; background-color:rgba(0, 0, 0, 0.5); box-shadow:0px 1px 2px #CCC,inset 0 1px 0 #FFFFFF } /* Good CSS */ .selector, .selector-secondary, .selector[type="text"] { padding: 15px; margin-bottom: 15px; background-color: rgba(0,0,0,.5); box-shadow: 0 1px 2px #ccc, inset 0 1px 0 #fff; }
No hay una mejor que otra. Como he comentado antes son convenciones, reglas a seguir por las personas que forman parte del equipo. Por lo que nos tenemos que sentir cómodas, ser ágiles y pracmáticas. He trabajado en varios equipos, y proyectos, he utilizado casi todas ellas. Es una decisión de equipo, pero eso sí, una vez hemos decidido una (ya sea una de ellas o una mezcla de varias) debemos ser consistentes y aplicarla en nuestro desarrollo.
Hoy en día es una tarea muy simple, ya que podemos configurar el linter para que al guardar los cambios nos "reformatee" el código según las reglas que hayamos decidido seguir. Aquí encontraréis las que estamos utilizando en SUI Components, utilizando Sass como preprocesador.
En CSS no nos podemos librar de uno de los dos grandes problemas en las Ciencias de la Computación, nombrar cosas. Si llevas un tiempo en el desarrollo seguro que te has llevado más de una sorpresa con el nombrado de variable, funciones o clases.
A la hora de desarrollar en las hojas de estilo tenemos el mismo problema, tanto para el nombrado de selectores de clases, las custom properties, como las variables, funciones o mixins de los preprocesadoes, que nos ofrecen una sintaxis de programación.
Como solución a estos problemas aparecen una serie de convenciones para, como en el punto anterior, conseguir un código más legible, mantenible y escalable. Vamos a ver algunas de ellas (algunas muy conocidas y otras no tanto)
La primera en ver la luz (2009) fue OOCSS de Nicole Sullivan, donde Nicole ofrecía una nomenclatura orientada a objeto, extendiendo las clases.
Un ejemplo de la propuesta de Nicole
.media { @extend %baseSpacing; @include clearfix-me(micro); > .mediaImg { float: left; margin-right: 10px; > img { display: block; } } > .mediaImgExt { float: right; margin-left: 10px; margin-right: 0; } > .mediaBody { @include clearfix-me(facebook); } }
Pero la más popular ha sido BEM (Block Element Modifier) del equipo de desarrollo de Yandex (la versión Rusa de Google). La popularidad que ha ganado BEM, en mi opinión, se debe a la simplicidad de la solución y a la gran documentación disponible desde el principio. Una de las cosas que supieron hacer es reaccionar a las peticiones de la comunidad y adaptar las "Naming rules" a unas "Alternative naming schemes".
Personalmente he utilizado BEM en más de un proyecto y en cuanto lo hemos utilizado en un equipo, hemos llegado a hacer alguna modificación para sentirnos cómodos. Recordad que son convenciones, las podemos adaptar a nuestras necesidades.
Un ejemplo de implementación de BEM
<ul class="mainMenu"> <li class="menu__item">...</li> <li class="menu__item">...</li> <li class="menu__item menu__item_size_m">...</li> </ul>
/* Block */ .mainMenu { ... } /* Element */ .menu__item { ... } /* Modifier */ .menu__item_size_m { ... }
En SUI Components y los productos de Adevinta Spain estamos utilizando SUIT CSS de Nicolas Gallagher. Llegamos a la conclusión de utilizar esta convención porque tiene un enfoque orientado a componente y creemos que ganamos en legibilidad. Cosa que es de agradecer en proyectos de gran tamaño y con un equipo de gente grande.
Ejemplo de implementación de SUIT CSS
<div class="sui-AtomCard"> <div class="sui-AtomCard-media"> ... </div> <div class="sui-AtomCard-info"> ... </div> </div>
/* ComponentName */ .sui-AtomCard { /* Descendent Name */ &-media { ... } &-info { ... } /* Modifier Name */ &--vertical { ... } &--responsive { ... } /* State Of Component */ &.is-highlight { ... } }