Este artículo es una traducción de "The CSS Mindset" del desarrollador austríaco Max Böck con su permiso expreso. ¡Gracias Max! Puedes seguirlo en Twitter. El énfasis (negritas) es nuestro.
¡Ah sí, CSS!. Rara es la semana en la que no es objeto de una acalorada discusión online: que si es muy difícil, que si es muy fácil, es impredecible, está anticuado...
No sé por qué CSS provoca tantas emociones diferentes en los desarrolladores, pero tengo una idea de por qué a veces puede parecer ilógico o frustrante: necesitas cierta mentalidad o manera de pensar para escribir un buen CSS.
En realidad, es probable que necesites ya una cierta mentalidad para dedicarte a escribir código en general, pero la naturaleza declarativa de CSS hace que sea particularmente difícil de "pillarle el truco", especialmente si piensas en él en términos de un lenguaje de programación "tradicional".
Otros lenguajes de programación suelen funcionar en entornos controlados, como en servidores. Esperan que ciertas condiciones se cumplan en todo momento y, por lo tanto, pueden entenderse como instrucciones concretas sobre cómo debe ejecutarse un programa.
CSS, por otro lado, funciona en un lugar (el navegador) que nunca se puede controlar totalmente, por lo que tiene que ser flexible por defecto. Se trata menos de "programar la apariencia" y más de traducir un diseño en un conjunto de reglas que comuniquen la intención que hay detrás del mismo. Deja suficiente espacio y el navegador hará el trabajo duro por ti.
Para la mayoría de las personas que escriben CSS profesionalmente, la mentalidad se vuelve natural después de un tiempo. Muchos desarrolladores tienen ese momento "¡ahá!" cuando las cosas por fin comienzan a hacer "clic" en su cabeza. No se trata solo de conocer todos los detalles técnicos, sino más bien de tener un sentido general acerca de las ideas que subyacen detrás del lenguaje.
He tratado de enumerar algunas de ellas aquí.
Todo es un rectángulo
Esto parece obvio, ya que el modelo de caja es probablemente una de las primeras cosas que todo el mundo aprende (o debería aprender) sobre CSS. Pero visualizar cada elemento del DOM como una caja es crucial para entender por qué las cosas se distribuyen de la manera en la que lo hacen. ¿Es un elemento en línea o en bloque? ¿Es un elemento "flex"? ¿Cómo crecerá/encogerá/moverá en diferentes contextos?
Abre tus herramientas del desarrollador y mueve el cursor sobre los elementos para ver las cajas que están generando, o utiliza un estilo "instrumental" como outline: 2px dotted hotpink para visualizar sus límites ocultos.
La cascada es tu amiga
La cascada - un concepto aterrador, lo sé. Repite "Cascada" tres veces frente a un espejo y en algún lugar, se romperá un estilo no relacionado.
Si bien hay razones legítimas para evitar la herencia por cascada, no significa que todo sea malo. De hecho, cuando se usa correctamente, puede hacer tu vida mucho más fácil.
La parte importante es saber qué estilos pertenecen al ámbito global y cuáles están mejor restringidos a un componente. También ayuda conocer qué valores predeterminados se transmiten para evitar la declaración de reglas innecesarias.
Tanto como sea necesario, lo menos posible
Trata de escribir la cantidad mínima de reglas necesarias para conseguir un determinado diseño. Menos propiedades significan menos herencia (en cascada), menos restricciones y menos problemas con sobreescrituras aguas abajo. Piensa en la esencia de lo que debería hacer tu selector, y luego intenta expresar solamente eso. No tiene sentido declarar el width: 100% en un elemento que ya es de bloque. No es necesario establecer position: relative si no necesitas un nuevo contexto de coordenadas.
Evita los estilos innecesarios, y evitas las consecuencias involuntarias.
Las versiones acortadas tienen efectos alargados
Algunas características de CSS se pueden escribir en notación acortada (se les suele llamar propiedades shorthand). Esto hace posible declarar un conjunto de propiedades relacionadas todas a la vez. Si bien esto es cómodo, debes tener muy en cuenta que si usas una propiedad acortada también estás declarando automáticamente el valor predeterminado para cada propiedad que no establezcas explícitamente. Si escribes background: white; en la práctica es como si estuvieses estableciendo todas estas propiedades:
background-color : white;
background-image : none;
background-position : 0% 0%;
background-size : auto auto;
background-repeat : repeat;
background-origin : padding-box;
background-clip : border-box;
background-attachment : scroll;
Es mejor ser explícito. Si lo que quieres es cambiar el color de fondo, usa tan solo background-color.
Sé siempre flexible
CSS se ocupa de gestionar una gran cantidad de variables desconocidas: el tamaño de la pantalla, el contenido dinámico, las capacidades del dispositivo... Y la lista continúa. Si tus estilos son demasiado cortos o restrictivos, es probable que una de estas condiciones variables te haga tropezar. Es por eso que un aspecto clave en la escritura de un buen CSS es adoptar su flexibilidad.
Tu objetivo es escribir un conjunto de instrucciones que sea lo suficientemente completo como para describir lo que quieres lograr, pero lo suficientemente flexible para que el navegador descubra cómo hacerlo solo. Es por eso que generalmente es mejor evitar los "números mágicos".
Los números mágicos son valores aleatorios "hardcodeados". Algo como esto:
.thing {
width : 218px ; /* ¿Por qué? */
}
Siempre que te encuentres pulsando la tecla de flecha en las herramientas del desarrollador, ajustando un valor de píxel para hacer que algo encaje, es probablemente un número mágico. Esta rara vez es la solución a un problema de CSS, porque restringe los estilos a un caso de uso muy específico. Si las restricciones cambian, ese número ya no te servirá.
En su lugar, piensa en lo que realmente quieres lograr en esa situación. ¿Alineación? ¿Una relación de aspecto? ¿Distribuyendo cantidades iguales de espacio? Todos estos tienen soluciones flexibles. En la mayoría de los casos, es mejor definir una regla para la intención, en lugar de codificar la solución calculada.
El contexto es clave
Para muchos conceptos de maquetación es obligatorio entender la relación entre los elementos y su contenedor. La mayoría de los componentes son conjuntos de nodos padre e hijo. Los estilos aplicados al padre pueden afectar a los descendientes, lo que podría hacer que hagan caso omiso de otras reglas. Tanto Flexbox como Grid y position:absolute son fuentes comunes de tales errores.
Cuando tenga dudas acerca de un elemento en particular que se comporta de forma diferente de lo que quisieras, mira el contexto en el que se encuentra. Es probable que algo en su árbol de elementos ascendentes le esté afectando.
El contenido cambiará
Ten siempre en cuenta que lo que ves es solo un estado de la interfaz de usuario dentro de un espectro más grande. En lugar de estilizar la cosa de la pantalla, intenta crear un "plano" o "mapa" del componente. Luego, asegúrate de que lo que le añadas no rompa tu estilo.
Las cadenas de texto pueden ser más largas de lo previsto o contener caracteres especiales, es posible que falten imágenes o que tengan dimensiones extrañas. Las pantallas pueden ser muy estrechas o extremadamente anchas. Esos son todos los estados que necesitas tener en cuenta de antemano y a los que anticiparte.
El error número uno cometido tanto por diseñadores como por desarrolladores es asumir que las cosas siempre se verán como en la maqueta estática. Te puedo asegurar, no va a ser así.
Encuentra patrones y reutilízalos
Cuando te propones convertir una maqueta de diseño en código, suele ser útil hacer un inventario previo de los diferentes patrones incluidos en el diseño. Analiza cada pantalla y toma nota de cualquier concepto que aparezca más de una vez. Puede ser algo pequeño como un estilo tipográfico, o grande como un patrón de maquetación determinado.
¿Qué se puede abstraer? ¿Qué es único? Pensar en las piezas de un diseño como cosas independientes las hace más fáciles de razonar y ayuda a dibujar los límites entre los componentes.
Usa nombres consistentes
Una parte sorprendentemente grande de la programación en general viene con buenos nombres para las cosas. En CSS, ayuda mucho utilizar alguna convención. Los esquemas de nombres como BEM o SMACSS pueden ser muy útiles. Pero incluso si no los usas, mantente fiel al uso de cierto vocabulario.
👉 Renuncia de responsabilidad
Entender todas estas cosas fue muy importante para mí, pero tu experiencia personal en cuanto a lo que más importa en CSS podría ser distinta. ¿Tuviste otro momento "¡ahá!" que te hizo entender mejor CSS? ¡Házmelo saber!