Tag: Atomic css

Metodologias CSS (y 5): Conclusiones

Vemos que los esquemas de lo que clásicamente se han considerado  “buenas practicas” de css resulta que no lo son siempre ni para todo el mundo y hay sangrientas  peleas  entre hermanos del frontend acerca de si es mejor añadir una clase al html  o poner un selector en el css.

 Dios nos dio el poder de resolver un problema con css de mil formas distintas y se nos ha ido de las manos 🙂

Hemos visto una forma de estructurar el css (Smacss) y tres metodologias para la nomenclatura/organización de las clases (BEM, DRY, Atomic).
Estas metodologias sirven para solucionar con distintas estrategias  una serie de problemas que da el css al escalar, basicamente:

  • Guerras de especificidad
  • Herencias no deseadas
  • Ligazon html-css

Desde mi punto de vista, si no tienes estos problemas, tu proyecto es pequeño, etc. quizá es mejor no utilizar ninguna y seguir las practicas clásicas, ya que cada metodología tiene sus inconvenientes acarreados. Planificando bien no debería uno tener ningún problema de los anteriores, es más, la herencia y especificidad pueden jugar a tu favor.

Otra cosa es un proyecto con mil y pico archivos scss y 94 developers como he leido que tiene Linkedin, eso no hay planificación previa que lo organice y ahi si que traerá ventajas adoptar un sistema de nomenclatura u otro.
¿Mejor añadir clases al html o selectores al css? ¿Tengo libre acceso al html? ¿lo tengo al css?¿Voy a usar preprocesadores? ¿somos un equipo pequeño o grande?
En función de las respuestas se elige uno, o ninguno y se adopta un mix de soluciones.

¿Tengo que compartir un único css entre muchos sitios con distintos htmls?
Quizá ATOMIC

¿Tengo que compartir un único html entre muchos sitios con distintos css sin acceso al html?
Quizá DRY

¿Tengo que mantener un sitio muy complejo con varios developers trabajando en el html/css ?
Quiza BEM

Todos los sistemas son un punto de compromiso distinto entre las distintas opciones que nos planteamos al hacer un css y las dos principales vias de ligar css y html:

-Clases semánticas acerca del contenido (.autor_bio), el CSS depende del HTML.
El HTML es “reestilable” sin tocarlo, pero el css no se puede reutilizar. (EJ: CSS Zen Garden)

-Clases semanticas acerca del diseño (.white_panel”), el HTML depende del CSS. 
El CSS es reutilizable pero el html no se puede reestilar sin tocarlo. (Bootstrap)

Aquí esta la experiencia de un hombre que conforme el proyecto creia se encontró con el problema que yo temo de BEM (entre otros), hay que hacer cientos de clases muy parecidas, acabo así:
https://medium.engineering/simple-style-sheets-c3b588867899

After more thought and some experimentation, we found a middle way: get rid of modifiers, leave non-atomic CSS only for low-level interface components (buttons, links, lists, and so on) and have the rest use these very specific atomic classes.

Al final esta es la via, tomar de cada sistema lo que a uno le interese cuando le interese. Nos podemos quedar con la jerarquia de css paralela que propone BEM, con el uso avanzado de grupos de DRY, con las utility class de Atomic y montar un sistema mixto adaptado a lo que se necesite.

Metodologías CSS (3): Atomic CSS

¿Atomic?

“Atomic” a secas no, mejor  “Atomic css” para no confundirse, porque existe otra metodología que se llama “Atomic Design” que no tiene nada que ver. O “Functional css” como se la llama también.

¿Y de que va esta vez?

Es el anticristo del css. su misión es destruirlo , pero no como BEM que solo lo mutila (cortandole la herencia y la especificidad), sino completamente. De hecho, en su ultima evolución, no usa archivos de hojas de estilo  propiamente dichas

¿Mande?

Todo el estilo se hace desde el html con clases que se generan dinámicamente con un procesador. Básicamente, es volver a los 90, cuando se ponia todo en el html, y se hacia  aquello de
<font face="verdana" color="red" size="3">Old school!</font>

Atomic es talibán del mandamiento “Cuanto más pequeño, mas reutilizable”  Funciona solo con clases reutilizables mínimas (atómicas), cada una de ellas preferiblemente con una sola propiedad y, en su variedad “programatic”  se generan al vuelo siguiendo unas convenciones.

Escribimos en el html:

<div class="Bgc(#0280ae) C(#fff) P(20px)">
 Y el procesador nos genera una hoja de estilos tal que así:
.Bgc\(#0280ae\) { background-color: #0280ae; }
.C\(#fff\) { color: #fff; }
.P\(20px\) { padding: 20px; }
 (Nota para novatos: lo de la barra \ es un caracter de escape, se usa para poder usar caracteres prohibidos en los nombres de clase)

Una de las ventajas es que no se tienen nunca clases sin utilizar en el css. Pero porque realmente no se tiene ni siquiera un css, muerto el perro acabo la rabia.

De hecho nunca editamos el css, un procesador va recorriendo el html y creando un css con las clases que se va encontrando.

Echadle un ojo a la referencia de uno de los frameworks que siguen este sistema:
https://acss.io/reference

Básicamente, han convertido cada propiedad de css en una especie de función.

Algunas ventajas que se aducen son:

  • que no hay que escribir una nueva regla con cada pequeño cambio css,
  • que es muy predecible
  • que es facil de leer ya que solo mirando el codigo html se sabe lo que hacen las clases
  • que las clases nunca dependen del contexto, la ventaja habitual de que se pueden mover unos módulos de una parte a otra o reutilizar hojas de estilo en diversos sitios.

Algunas de estas cosas son muy discutibles…

Algunos frameworks para usar este concepto tienen su cachondeo en el nombre como quarks.js, tachyons, etc. (son partículas subatomicas)

Por ejemplo quark.js propone trabajar así:

<div class="color-red fontSize-20"></div>
Realmente, hay muy poca diferencia con ponerlo todo en estilos inline.

¿y a ti te mola? 

No.  Es rarísimo, y va en contra de los principios morales de occidente en cuestión de css, de hecho el artículo que dio pie al concepto se llamaba:   “Desafiando las buenas practicas css”.
En las blasfemas palabras de su autor:

“Preferimos contaminar el html que el css”

Pero algo tendrá el agua cuando la bendicen, esto es (o era) usado por sitios como yahoo.

Como siempre es cuestión de balance y compromiso, ok, vas a hacer las hojas de estilo mas fáciles de mantener pero a cambio de embrollar el html.

Y situaciones donde sea aplicable.
Por ejemplo ninguno de estos sistemas que proponen añadir clases para cambiar el aspecto en vez de usarlas para localizar los elementos (añadiendo .float_right o similar en vez de hacer header >h1{float:right, por ejemplo ) serian fáciles de aplicar en un blog wordpress

Un case study de un hombre que pasó de BEM a atomic y explica por que y como:
https://hackernoon.com/full-re-write-with-tachyons-and-functional-css-a-case-study-part-1-635ccb5fb00b