Tag: DRY 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 (4): DRY CSS

¿CSS seco? ¿como el Martini?

No, Dont Repeat Yourself, nacio en el 2012.

¿Y de que va?

De no repetirse, de no repetirse, de no repetirse.

Bueno, para no repetir código tengo sass, variables, extends…

DRY dice que preprocesar es caca. Que no es css de verdad. Que dependes de librerias externas. (todo esto es muy muy discutible) y que se puede conseguir solo con css quimicamente puro.

La filosofia es no repetir las propiedades en cada clase sino agrupar las propiedades en grupos y asignar las clases a esos grupos.

Esta metodología no sataniza los selectores de herencia como las anteriores, lo necesita por su forma de funcionar, ya que uno de sus principios es tocar el html lo menos posible.
No usa las clases para definir el diseño sino para referirse al contenido, es decir, no usa cosas como .left sino .header

¿Que eso de los grupos?

Los grupos son conjuntos de propiedades css que van juntas, y le asignas las clases que las necesiten
Ya agrupamos  cuando varias clases comparten las mismas propiedades, pues hacer DRY es coger este concepto y llevarlo al talibanismo.
Aquí no haces clases y asignas propiedades, sino que haces grupos de propiedades y asignas las clases.Si tienes 5 elementos que usan el fondo blanco, habitualmente defines las 5 clases/selectores y añades en cada una: background:#FFF. O bien añades una “utility class”, (una clase que sirve para una función especifica y “universal”, como .light_background{background:#FFF} )Hemos dicho que DRY no quiere tocar el html, así que la utility class descartada, lo que se hace siempre según este sistema es

#LIGHT_BACKGROUND,
 .clase1 ul,
 .clase2 h2,
 .clase3,
 .clase4 li p,
 .clase5 .top
{
 background:#FFF
 }
Ojo, el id es solo para nombrar el grupo de propiedades, es para forzar que salga el nombre el grupo al inspeccionar un elemento. DRY dice que si tienes una sola clase asignada a un conjunto de propiedades, probablemente estes haciendo algo mal
DRY propone primero hacer una lista de grupos (separados en colores, texto, formas, estructuras y módulos), y luego asignar las clases según pertenezcan a uno u otro.
Los grupos se nombran en mayusculas según la función que hacen (#TEXT_RED, #MARGIN_BIG, #FLOAT_LEFT) y las clases semánticamente según su contenido (.top, .user .featured)Primero hacer grupos de propiedades:

{background:white;
 font-size:20px}
{background: grey;
 padding:20px}
{font-family: impact}

Luego nombrar esos grupos logicamente y en mayusculas utilizando ids que no se usan en el html:

#WHITE_PANEL
{background:white;
 font-size:20px}
  #GREY_PADDED
{ background: grey;
padding:20px}
#HEADINGS
{font-family: impact}

y luego asignar las clases necesarias.

 #WHITE_PANEL,
.menu-toggle,.post-term a,.term-link a,.site-title-text,.taxonomy-list-title .term-name
{background:white;
 font-size:20px}
  #GREY_PADDED,
.screen-title,.cycled-feature h3,.text
{ background: grey;
padding:20px}
#HEADINGS ,
h3,big,.footer h2,.cycled-feature .entry
{font-family: impact}

Echadle un ojo a este css y lo vereis enseguida:
https://s3.amazonaws.com/static.globalvoices/css/gv-news.css?updated=20171001

Que es de esta web:
https://es.globalvoices.org/

Si veis el html vereis que eso de “tocar el html lo menos posible” tampoco se cumple mucho…

 ¿Y que ventajas tiene?

– Css mas cortos.
– Promueve buenas practicas de diseño  ya que tienes que pensar en patrones de diseño en vez de en elementos sueltos
– Solo usa css “puro”, sin preprocesadores
– Al ver todas las clases afectadas por una propiedad es más fácil ver las interdependencias y herencias, sabes a quien afectara una propiedad al cambiarla
– No necesita editar el html, puede servir para “estilar” sitios donde no tienes acceso (o es difícil) a la fuente html, como wordpress.
– Es compatible con otras metodologías como smacss , ya que solo se mete en como organizar clases y selectores

¿Y como se apaña con el responsive?

Tienes que duplicar los grupos en cada punto de ruptura con las nuevas propiedades.

¿Y tu que piensas?

Lo veo flojo.
Y que llevar tan al extremo el hecho de no repetir código arrastra inconvenientes en otros aspectos. Creo que es más sencillo y legible usar preprocesadores y gastar unos kbs más si hace falta. Si no ves problema en usar preprocesadores para no repetir código este sistema pierde muchos puntos…

Al final hay listas kilometricas de clases asignadas a una propiedad que a mi modo de ver traslada el problema de sitio más que solucionarlo.

Tambien es verdad que se hace muy raro porque obliga a pensar al revés, desde la propiedad > clase > grupo en vez de elemento > clase > propiedad como estamos habituados por la filosofía de css.

A pesar de todo creo que tiene cosas interesantes y hay que tenerla en cuenta si no para seguirla al 100, quizá para aplicar algunos conceptos como los grupos definidos de propiedades.

Una presentación sobre el sistema donde se ven sus principios y forma de funcionar: