
Incluso si se considera un experto en CSS, lo más probable es que en algún momento de un proyecto grande haya tenido que lidiar con una hoja de estilo intrincada y laberíntica que nunca deja de crecer. Algunas hojas de estilo pueden sentirse como una red de herencia desordenada y enredada.
Monstruo de espagueti
La cascada es increíblemente poderosa. Los pequeños cambios pueden tener grandes efectos, lo que dificulta saber cuáles serán las consecuencias inmediatas. La refactorización, el cambio y la eliminación de CSS se consideran riesgosos y se abordan con temor, ya que es difícil saber todos los lugares en los que se está utilizando.
Una cosa que a menudo es difícil de articular con nuevas herramientas es cuando exactamente ¿Empiezas a alcanzar esto? La respuesta es raramente (si alguna vez) inmediatamente y en todas las situaciones.
Una de esas situaciones, en mi experiencia limitada, es en equipos grandes con grandes bases de código. La sensación es que el CSS puede volverse demasiado grande y los miembros del equipo esencialmente le tienen miedo, y el CSS se vuelve, en broma, pero con precisión, “solo para agregar”.
Aparece una herramienta que cumple la promesa de enviar mucho menos CSS y de una manera que (después de una curva de aprendizaje) nadie volverá a temer… Puedo ver el atractivo.
– Chris Coyier
Atomic CSS simplifica las cosas
Ya no tenía que pensar en cómo organizar mi CSS. No tuve que pensar en cómo nombrar mis ‘componentes’, dónde trazar la línea entre un componente y otro, qué debería vivir dónde y, lo que es más importante, cómo refactorizar las cosas cuando surgieron nuevos requisitos.
– Callum Jefferies, Conclusiones de probar Tachyons CSS después de mucho tiempo usando BEM
Atomic CSS ofrece una metodología directa, obvia y simple. Las clases son inmutables, no cambian. Esto hace que la aplicación de CSS sea predecible y confiable, ya que las clases siempre harán exactamente lo mismo. El alcance de agregar o eliminar una clase de utilidad en un archivo HTML es inequívoco, lo que le brinda la confianza de que no está rompiendo nada más. Esto puede reducir la carga cognitiva y la sobrecarga mental.
Nombrar componentes es notoriamente difícil. Decidir un nombre de clase que sea significativo pero también lo suficientemente vago como para ser reutilizable lleva mucho tiempo y es mentalmente agotador.
Solo hay dos cosas difíciles en Ciencias de la Computación: invalidación de caché y nombrar cosas.
– Phil Karlton
Llegar a las abstracciones apropiadas es difícil. Nombrar clases de utilidad, por el contrario, es completamente sencillo.
/* naming utility classes */
.relative {
position: relative;
}
.mt10 {
margin-top: 10px;
}
.pb10 {
padding-bottom: 10px;
}
Las clases atómicas hablan por sí solas. Su intención y efecto son inmediatamente obvios. Mientras que llenar HTML con innumerables clases puede parecer desordenado, HTML es mucho más fácil de razonar que un muro impenetrablemente gigantesco e incomprensible de estilos enredados.
En un equipo de habilidades mixtas, tal vez involucrando a desarrolladores de back-end con interés y conocimiento limitados de CSS, hay menos posibilidades de que las personas arruinen la hoja de estilo.
Tomado de ryanair.com: una gran cantidad de CSS que hacen una sola cosa.
Lidiando con la variación estilística
Las clases de utilidad son perfectas para lidiar con pequeñas variaciones estilísticas. Si bien los sistemas de diseño y las bibliotecas de patrones pueden estar de moda en estos días, lo que este enfoque reconoce es que habrá continuamente nuevos requisitos y variaciones. Toda la charla sobre la reutilización de componentes a menudo no se refleja en los simulacros de diseño que se le presentan. Si bien la consistencia visual y de marca es buena, la amplia variedad de contextos en un sitio web grande hace que algunas variaciones sean inevitables y estén justificadas.
El equipo de desarrollo de Medium se alejó de los modificadores BEM, como se documenta en su blog.
¿Qué pasa si queremos que un componente se diferencie de otro solo en una pequeña forma? Si ha adoptado una convención de nomenclatura BEM, las clases de modificadores pueden salirse de control: innumerables modificadores que a menudo solo hacen una sola cosa. Tomemos los márgenes como ejemplo. Es poco probable que los márgenes de un componente permanezcan universalmente consistentes para un componente. El espaciado deseado depende no solo del componente sino también de su posición en una página y su relación con los elementos que lo rodean. La mayor parte del tiempo, los diseños contendrán elementos de interfaz de usuario similares pero no idénticos, que son difíciles de manejar con CSS tradicional.
A mucha gente no le gusta
Aaron Gustafson, editor jefe de A List Apart, exgerente de Web Standards Project, empleado de Microsoft.
Ingeniera de Mozilla Soledad Penades
Del creador de CSS Zen Garden
¿En qué se diferencia Atomic CSS de los estilos en línea?
Esta es la pregunta que siempre le hacen sus críticos al CSS atómico. Los estilos en línea se han considerado durante mucho tiempo una mala práctica, que rara vez se utilizan desde los primeros días de la web. Los críticos no están del todo equivocados al equiparar el CSS atómico con los estilos en línea porque ambos sufren el mismo problema principal. He aquí un ejemplo: ¿Qué pasa si queremos cambiar todo con un .black
clase para ser marina en su lugar? Podríamos hacer esto:
.black {
color: navy;
}
Eso es obviamente una idea terrible.
Los editores de texto son cosas sofisticadas en estos días. Se siente algo peligroso, pero sería bastante simple usar buscar y reemplazar para cambiar todas las instancias del .black
clase con un nuevo .navy
clase. El verdadero problema es cuando desea cambiar solo ciertas instancias de .black
ser – estar .navy
.
En los enfoques tradicionales de CSS, ajustar el estilo de un componente es tan fácil como actualizar un solo valor en una sola clase en un archivo CSS. Con atomic CSS, esto se convierte en la tediosa tarea de buscar en cada pieza de HTML para actualizar cada instancia de dicho componente. Sin embargo, los editores de código avanzados se vuelven, no hay forma de evitar esto. Incluso si está separando su marcado en plantillas reutilizables, esto sigue siendo un gran inconveniente. Quizás este trabajo manual valga la pena por la simplicidad de este enfoque. Actualizar archivos HTML con diferentes clases puede ser tedioso pero no es difícil. (Aunque hubo momentos en los que introduje temporalmente inconsistencias estilísticas al perder ciertas instancias del componente relevante al actualizar manualmente). Si un diseño cambia, es probable que deba editar manualmente las clases de todo su HTML.
Si bien el CSS atómico comparte el gran inconveniente de los estilos en línea, no son un paso atrás hacia el pasado. Las clases de utilidad son mejores que los estilos en línea en todo tipo de formas.
CSS atómico frente a estilos en línea
Las clases atómicas permiten la abstracción, los estilos en línea no.
Con las clases atómicas, es posible crear abstracciones que serían imposibles con los estilos en línea.
<p style="font-family: helvetica; color: rgb(20, 20, 20)">
Inline styles suck.
</p>
<p class="helvetica rgb202020">
Badly written CSS isn't very different.
</p>
<p class="sans-serif color-dark">
Utility classes allow for abstraction.
</p>
Los primeros dos ejemplos que se muestran arriba requerirían una búsqueda y reemplazo manual para actualizar el estilo si el diseño cambiara. Los estilos del tercer ejemplo se pueden ajustar en un solo lugar dentro de una hoja de estilo.
Estampación
Sass, Less, PostCSS, Autoprefixer… La comunidad CSS ha creado muchas herramientas útiles que no estaban disponibles para los estilos en línea.
Brevedad
En lugar de escribir estilos detallados en línea, las clases atómicas pueden ser breves abreviaturas de declaraciones. Es menos escribir: mt0
contra margin-top: 0
, flex
contra display: flex
, etc
especificidad
Este es un punto polémico. Si una clase o estilo en línea solo hace una sola cosa, es probable que desee que haga esa cosa. Algunas personas incluso han defendido el uso de !important
en todas las clases de servicios públicos para asegurarse de que anulan todo lo demás. Del mismo modo, los defensores de los estilos en línea ven su incapacidad para anularse (por algo que no sea !important) como un punto de venta: significa que puede estar seguro de que se aplicará el estilo. Sin embargo, una sola clase es lo suficientemente específica como para anular cualquier estilo base. La menor especificidad de las clases atómicas en comparación con los estilos en línea es algo bueno. Permite más versatilidad. Todos estaban acostumbrados a cambiar de clase en JavaScript para cambiar estilos. Los estilos en línea lo hacen más difícil.
Las clases en hojas de estilo pueden hacer cosas que los estilos en línea no pueden
Los estilos en línea no admiten consultas de medios, pseudoselectores, @supports o animaciones CSS. Tal vez tenga un solo efecto de desplazamiento que desea aplicar a elementos dispares en lugar de solo a un componente.
.circle {
border-radius: 50%;
}
.hover-radius0:hover {
border-radius: 0;
}
Las reglas de consulta de medios reutilizables simples también se pueden convertir en una clase de utilidad. Es común usar un prefijo de nombre de clase para tamaños de pantalla pequeños, medianos y grandes. Aquí hay un ejemplo de una clase flexbox que solo se aplicará en tamaños de pantalla medianos y grandes:
@media (min-width: 600px) {
.md-flex {
display: flex;
}
}
Esto no sería posible con un estilo en línea.
¿Quizás desee un icono o una etiqueta de pseudocontenido reutilizable?
.with-icon::after {
content: 'some icon goes here!';
}
Limitar las opciones puede ser algo bueno
Los estilos en línea pueden ser cualquier cosa. Esta libertad podría conducir fácilmente a la anarquía e inconsistencia del diseño. Al predefinir clases para todo, el CSS atómico puede garantizar una cierta cantidad de consistencia estilística. En lugar de improvisar colores y valores de una cantidad infinita de opciones, las clases de utilidad ofrecen un conjunto seleccionado de opciones predefinidas. Los desarrolladores eligen de este conjunto limitado de clases de utilidad de propósito único. Esta restricción puede eliminar el problema de una hoja de estilo en constante crecimiento y mantener la coherencia visual.
toma el box-shadow
como ejemplo. Un estilo en línea tendrá una cantidad casi ilimitada de opciones de desplazamiento, extensión, color, opacidad y radio de desenfoque.
<div style="box-shadow: 2px 2px 2px rgba(10, 10, 250, .4)">stuff</div>
Con un enfoque atómico, los autores de CSS pueden definir el estilo preferido, que luego se aplica simplemente, sin posibilidad de inconsistencia estilística.
<div class="box-shadow">stuff</div>
Atomic CSS no es todo o nada
No hay duda de que los marcos de clase de utilidad como Tachyons han ganado popularidad. Sin embargo, los enfoques de CSS no son mutuamente excluyentes. Hay muchos casos en los que las clases de servicios públicos no son la mejor opción:
- Si necesita cambiar muchos estilos para un componente en particular dentro de una consulta de medios.
- Si desea cambiar varios estilos con JavaScript, es más fácil abstraerlo en una sola clase.
Las clases de utilidad pueden coexistir con otros enfoques. Probablemente sea una buena idea definir estilos base y valores predeterminados sensatos globalmente. Si sigue duplicando la misma cadena larga de clases de utilidad, es probable que los estilos se abstraigan en una sola clase. Puede mezclar clases de componentes, pero hágalo solo cuando sepa que se reutilizarán.
Adoptar un enfoque de CSS que priorice los componentes significa que crea componentes para las cosas, incluso si nunca se reutilizarán. Esta abstracción prematura es la fuente de mucha hinchazón y complejidad en las hojas de estilo.
– Adam Wathan
Cuanto más pequeña es la unidad, más reutilizable es.
– Thierry Koblentz
En cuanto a la versión más reciente de Bootstrap, ahora se ofrece una gran cantidad de clases de utilidad, sin dejar de incluir sus componentes tradicionales. Cada vez más, los marcos populares están adoptando este enfoque mixto.