Escribir buen CSS

Siempre estoy tratando de aprender cosas nuevas. Sin embargo, también trato de aprender formas de mejorar la forma en que ya hago las cosas. Tanto en mi trabajo de tiempo completo como en proyectos paralelos de clientes, lo que siempre quise mejorar fue mi CSS. Siempre he sentido que soy bastante bueno cuando se trata de CSS, pero siempre me ha parecido complicado de leer y, a menudo, difícil de mantener.

Lo que he estado tratando de hacer es descubrir qué hace que un CSS sea bueno, legible y mantenible. Creo que se me ocurrieron (y encontré) algunas maneras de hacer todo esto posible.

Los problemas

Hay varias cosas que me molestan sobre CSS. Las molestias más comunes que tengo son:

• repetición de código común
• prefijos del navegador
• falta de comentarios
• selectores sobre calificados
• nombres de clase pobres

Cuando se trata de mis proyectos personales, asumo toda la responsabilidad de mi código. Rara vez comento mi CSS y, a menudo, lo trato como una ocurrencia tardía. Eso está mal.

Durante mucho tiempo pensé que los nombres de mis clases son "semánticos" y que solo soy yo haciendo cosas, por lo que no hay necesidad de explicar el código, ni pequeños "trucos", ni nada.

Volver al código en un proyecto de larga data demuestra rápidamente que esta teoría está muy equivocada.

Cuando se trata de código en el trabajo, no puedo asumir toda la culpa. De hecho, parte del problema es la cantidad de personas que han tenido sus manos allí. Actualmente, nuestro equipo tiene siete de nosotros que en algún momento hemos escrito CSS para nuestros sitios, con otros 6-8 que han ido y venido durante el años. Cada miembro del equipo tiene diferentes niveles de conocimiento y habilidad con respecto a CSS.

Además, como suele ser el caso con proyectos de larga duración, parte del código es antiguo . Mucho de esto es anterior a CSS3, o anterior a cualquier tendencia que fuera genial hace 5 años. En ambos casos, a menudo había diferentes formas de hacer las cosas en el momento en que fue escrito y, en algunos casos, una falta natural de conocimiento.

También aprendí que algunos programadores insisten en que su código es "autodocumentado". Si no está familiarizado con ese término, se traduce como "mi código no tiene comentarios".

Soluciones

Si bien nada es perfecto, creo que hay cosas que podemos hacer para mejorar nuestro código. Descubrí las Pautas CSS de Harry Roberts hace un tiempo. Se mantiene fiel a la promesa de "Consejos y pautas de alto nivel para escribir CSS sensato, manejable y escalable".

Comentarios

Si bien las pautas de CSS brindan detalles sobre los estilos de comentarios, personalmente solo trato de poner algo para decirme en el futuro lo que estaba pensando. Comienzo cada componente con un comentario que representa el título, los detalles sobre la intención del componente.

Cuando uso un preprocesador, diseño comentarios específicos para incluirlos con el CSS o para que el preprocesador los omita. Todavía estoy trabajando en esta parte y tratando de adquirir el hábito de poner algo , cualquier cosa .

Orientación a objetos

La orientación a objetos es un paradigma de programación que divide cosas grandes en cosas pequeñas. De Wikipedia:

La programación orientada a objetos (POO) es un paradigma de programación que representa el concepto de 'objetos' […] que suelen ser instancias de clases, [y] se utilizan para interactuar entre sí para diseñar aplicaciones y programas informáticos.

Cuando se trata de CSS, lo llamamos CSS orientado a objetos u OOCSS . El concepto básico separa la estructura del elemento, de la piel del elemento. Esto significa que podemos reutilizar fácilmente cualquier patrón de diseño recurrente, sin necesariamente reutilizar los detalles de implementación específicos al mismo tiempo. OOCSS se centra en gran medida en la reutilización del código, lo que nos hace más rápidos y puede mantener bajo el tamaño de nuestra base de código.

Pienso en aspectos estructurales como esqueletos; marcos comunes que dan construcciones conocidas como objeto . Estos objetos son patrones de diseño simples que están libres de cosméticos. Abstraemos la estructura de un conjunto de componentes para tener un objeto genérico.

Luego, opcionalmente, agregamos la capa de "piel" a nuestra estructura para que podamos darle a las abstracciones una apariencia y una sensación específicas. Por ejemplo (tomado de las Directrices CSS):

 /**
 * Un objeto de botón simple y sin diseño. Extiende este objeto con un aspecto `.btn--*`
 * clase.
 */
.btn {
    pantalla: bloque en línea;
    relleno: 1em 2em;
    alineación vertical: medio;
}

/**
 * Piel de botones positivos. Extiende `.btn`.
 */
.btn--positivo {
    color de fondo: verde;
    color blanco;
}

/**
 * Piel de botones negativos. Extiende `.btn`.
 */
.btn--negativo {
    color de fondo: rojo;
    color blanco;
}

Aquí vemos cómo la clase .btn simplemente proporciona estructura a un elemento, pero no tiene nada que ver con la cosmética. Podemos extender .btn con una segunda clase, como .btn--positve para darle a ese elemento un estilo más específico:

 <button class="btn btn--positivo">Aceptar</button>

Prefiero usar varias clases en mi HTML, en lugar de usar algo como @extend en un preprocesador. Esto me da más visibilidad en mi HTML, lo que me permite ver rápidamente qué clases se aplican a mi elemento. También significa que mis clases no están estrechamente ligadas a otros estilos en mi CSS. De alguna manera ayuda a OOCSS siguiendo los conceptos de encapsulación .

BEM

BEM ( Bloque, Elemento, Modificador ), es una metodología de front-end desarrollada en Yandex. BEM es en realidad una metodología muy completa y, sinceramente, no he profundizado en todos los detalles, pero lo que me preocupa es simplemente la convención de nomenclatura.

Estoy usando convenciones de nomenclatura similares a BEM. El concepto es el mismo, pero la sintaxis exacta puede diferir ligeramente.

BEM coloca las clases en tres grupos:

1. Bloque: la raíz o base de un componente
2. Elemento: un componente dentro de un bloque
3. Modificador: una variación o extensión del Bloque

Una analogía muy básica ( no un ejemplo):

 .perro {}
.cola de perro {}
.perro--pequeño {}

Los elementos se delimitan con dos guiones bajos (__) y los modificadores se delimitan con dos guiones (–).

En la analogía anterior, vemos que .dog es el Bloque, la raíz del elemento. Entonces, .dog__tail es un elemento, es una parte más pequeña de un bloque .dog . Por último, .dog--small es un modificador, una variación específica del bloque .dog . También puede aplicar modificadores a los elementos. por ejemplo, podríamos tener .dog__tail--short para especificar una variación en el elemento dog__tail .

En algunos casos, es posible que desee varias palabras para Bloques, Elementos o Modificadores. En cualquier caso, estos se separan con un solo guión (-), y las clases se escriben siempre en minúsculas .

preprocesadores

He pasado tiempo integrando preprocesadores CSS en mi flujo de trabajo y, hasta ahora, ha sido increíblemente valioso. Los preprocesadores de CSS toman el código que está escrito en un lenguaje preprocesado y lo convierten en el buen CSS antiguo. No son CSS, lo que significa que no están sujetos a las mismas reglas y limitaciones de CSS. Si bien CSS es excelente, no siempre nos permite hacer fácilmente las cosas que nos gustaría hacer.

Por ejemplo, una cosa que sería muy buena en CSS son las variables . Tal vez quiera que algo tenga el margen izquierdo de un elemento igual al ancho de otro, y de repente alguien decide que esos números deben cambiar. Dado que son el mismo número y su diseño puede depender de ese número, debe cambiarlo en más de un lugar. Pero con una variable podrías cambiarla en un solo lugar y hacer que se refleje en todo el diseño. Por supuesto, hay mucho más en los preprocesadores que solo variables, ¡pero eso es un comienzo!

Obviamente, no tienes que usar un preprocesador, pero creo que encontrarás que la mayoría de las personas que lo usan no regresarán. Sé que no lo haré. La ganancia en flexibilidad y la mayor legibilidad son algo a lo que simplemente no puedo renunciar. El simple hecho de poder usar variables y mixins es suficiente para mantenerme enganchado.

Hay varios preprocesadores disponibles, pero los únicos dos que realmente he visto y usado son LESS y SASS . Eche un vistazo y considere agregar uno de estos a su flujo de trabajo, no mirará hacia atrás.

Concluyendo

Mi verdadero punto aquí es que CSS puede ser mejor. Todo puede ser mejor. Alguien me dijo recientemente en un comentario en una publicación en Reddit que "CSS no tiene semántica". Estoy totalmente en desacuerdo. CSS 100%, sin duda puede ser semántico.

El uso de OOCSS y BEM, de hecho, le da a su CSS un significado muy semántico. Esto no significa que sea fácil desde el principio, pero vale la pena explorarlo. Combine eso con los preprocesadores de CSS y tendrá el potencial de un CSS muy legible, fácil de mantener y escalable .

También me gustaría señalar que esto no solo hace que su CSS (preprocesado o no) sea más legible, sino que también hace que su HTML sea más legible, al aplicar nombres de clase semánticos a los elementos.

TL;RD

Ok, tal vez eso fue mucho, para resumir, escribe mejor CSS haciendo esto:

CSS orientado a objetos :

• cada clase hace una cosa: lo hace bien, lo hace bien

Nombres de clase de estilo de bloque, elemento, modificador (BEM) :

• Bloque: .grid
• Elemento: .grid__item (2 guiones bajos)
• Modificador: .grid--wide (2 guiones)

Los preprocesadores son increíbles :

• échales un vistazo: LESS – SASS
• o encuentre otros: 8 preprocesadores CSS para acelerar el tiempo de desarrollo