Consejos para la estructura de CSS para sitios web comerciales (o cualquiera en ese sentido)

Publicado: 2020-12-17

CSS y HTML son fáciles de entender. Sin embargo, se necesitan años de práctica para aprender sobre los mejores enfoques arquitectónicos al crear sitios web (y aplicaciones) de una manera que los haga reutilizables, mantenibles en el futuro y mantenga felices a los desarrolladores.

¿Qué se entiende aquí por arquitectura? Es la estructura del código CSS. La forma en que lo separa en archivos, las reglas detrás de los nombres de las clases, la profundidad de los selectores, la forma en que se distribuye en cascada, lo que se hereda, cómo configura los componentes, las páginas, los elementos y los modificadores.

Aplicar las mejores prácticas a todos estos componentes del sitio web con cientos de páginas, varios tipos de contenido, vistas de pantalla, casos extremos, y con la consideración de agregar más en la parte superior y modificar los existentes es la parte difícil.

Construya con componentes, no con páginas

Esta es una de las partes principales a considerar. No debes diseñar según la página en la que te encuentres. No hagas estilos .homepage… {}. Si su página tiene una sección, modifique el estilo de la sección. Con eso, también puede reutilizarlo en otras páginas. Si tiene un botón, modifique el estilo del botón como .button {} y reutilícelo en otro lugar. Es válido para todas las vistas.

Este es el consejo más común y el enfoque de mejor rendimiento (hasta ahora) que puede utilizar.

Estilo con componentes en mente

Ahora bien, ¿cómo gestiona las diferencias específicas de la página? ¿Porque esta es la razón más común para diseñar por página? Bueno, hay algunos enfoques:

Usa modificadores.

En "BEM", la "M" significa Modificador. Este es el aspecto del modificador .block__child. Incluso si no usa BEM, existen modificadores de todos modos. Si hay una variación en un componente o una sección, agréguele un modificador.

Idealmente, el diseñador debe ser reflexivo y mantener las variaciones al mínimo para mantener limpio el código, pero no debe tener miedo de agregar más. Idealmente, las variaciones solo deberían sobrescribir algunas propiedades y deberían funcionar con el mismo marcado. Es una buena manera de abordar los componentes en la fase HTML: agregue las etiquetas que necesitará y manténgalas consistentes en todo el sitio. No agregue nuevos debido a una clase modificadora.

Modificador de elemento de bloque

Estilo de componentes para niños.

El otro enfoque es el estilo basado en el contexto. Un botón es siempre un botón, tiene su clase .button y todo, pero aún puede ajustarlo si es parte de otro componente. En general, esta no es una buena idea ya que crea inconsistencias, pero también es un caso de uso bastante realista. De lo contrario, terminaría con 20 modificadores con nombres extraños.

Los estilos contextuales son cuando se aplica estilo a un componente solo si es hijo de otro. Tomemos una tarjeta de artículo, por ejemplo. Tiene sus estilos por defecto. Pero si es parte de una sección colorida con algo de texto al lado, el diseño requiere que la tarjeta tenga algunos otros elementos alrededor (como formas animadas, etc.).

En ese caso, aplica el estilo con el selector .parent .card {}. Solo tendrá que sobrescribir algunas propiedades como lo haría con un modificador. Cuando hace eso, la tarjeta en sí no agrega más complejidad a sus estilos, pero aún se comportará correctamente en ese caso de borde específico.

Cuando piensa en esto, también puede ver cómo se puede aplicar "por página". Si hay algunos casos extremos extraños en el diseño y hay algunas diferencias menores con respecto a las vistas de componentes estándar (y la forma en que todos interactúan juntos), entonces puede diseñarlo con el selector .homepage {}. Solo tenga en cuenta que debe usar eso con moderación. Según nuestra experiencia, estos estilos rara vez superan unas pocas líneas de código.

Nota importante para agregar: Los estilos basados ​​en el contexto NO son una buena práctica en general. Idealmente, ni siquiera debería necesitar eso. La mayoría de las veces, tendría modificadores que deberían hacer el trabajo lo suficientemente bien. Aunque es realista en algunas versiones, sumergirse demasiado en un buen código abstraído con reglas estrictas puede resultar demasiado caro.

Trabajar en secciones

La mayoría de los sitios web comerciales (y muchos otros) separan el contenido en secciones. Cada sección es un componente por sí solo con una clase modificadora que define las distintas propiedades. Una sugerencia para ir con la estructura de las clases sería:

Páginas de destino separadas en secciones

  • section.section-container: este podría ser el "nombre del componente" si lo desea, que contiene los rellenos / márgenes consistentes o lo que sea necesario.
  • section.section-border-top - es un modificador. Esto no usa BEM, pero puede "traducirlo" a section-container-border si es necesario.
  • section.section-welcome - sería el nombre de la sección.

La convención de nomenclatura nuevamente es irrelevante aquí. Con tales secciones, obtendría la libertad de ajustar los estilos a los componentes reutilizables en los casos extremos creados por el diseño (ya sea debido a inconsistencias que deben seguirse o simplemente a vistas más complicadas).

Separación de archivos

Lo más probable es que utilice Sass u otro preprocesador similar. En términos de separación de archivos, hay muchos enfoques, pero el que tomamos sigue la siguiente estructura general:

  • General: lo general generalmente consiste en un código de configuración como hacer que una cuadrícula funcione, estilos para etiquetas HTML, restablecimientos / normalizadores, algunos estilos específicos de CMS y similares.
  • Páginas: los estilos de página como se explicó anteriormente. Idealmente, debería mantener muy poco código aquí.
  • Componentes: el núcleo de la compilación: los diversos componentes residen aquí. Un consejo es que puede tener "elementos" o "misceláneos" que quepan en trozos más pequeños de componentes en un archivo en lugar de 80 archivos. Los más grandes, por supuesto, idealmente deberían ir en archivos separados.
  • Diseño: estilos globales, por ejemplo, en el encabezado, pie de página y luego diseños de página, modificadores de la cuadrícula, etc.
  • Complementos: cualquier cosa externa que se genere a partir de un complemento, extensión o lo que sea. Es bueno separarlos, ya que luego puede reutilizarlos en otros proyectos.

Mantenga limpios los selectores

Una buena señal de un código limpio es lo simple que parece. Sin propiedades extrañas, todo tiene su propósito, hay poca sangría. Los selectores de "apariencia inteligente" cuando no son necesarios no hacen que su código sea "genial". Si puedes sustituir algo como #container> .row div [rel = ”algo”] con .rel-algo (imagina que es un nombre de clase significativo), entonces deberías actualizar un poco el marcado. El objetivo de esto es hacer que todo sea más simple.

Mantenga las hendiduras bajas. Rara vez necesitas ir más de tres niveles. Veamos, por ejemplo, una clase .entry:


.entrada { ... }
.entry-title {...}

Vea que realmente no hay necesidad de sangrar .entry-title dentro de .entry. Más tarde, cuando agregue un modificador al archivo, puede tener .entry-modifier {} y .entry-modifier .entry-title {}

Con este enfoque, sobrescribir estilos en el futuro es mucho más fácil. Echemos un vistazo a otro ejemplo común: tiene el marcado de nav.site-nav> ul.list-menu> li.list-items * 5> a (emmet)

Ahora, para estilizar, todo lo que necesitas es:


.site-nav {}: componente 1

.list-menu {} - componente 2
.list-menu .list-item {}
.list-menu a {}

Si tenía más componentes adentro, como menús desplegables adicionales, puede anidarlos directamente dentro de .list-menu. No es necesario escribir .site-nav .list-menu .list-item .dropdown {} (4 niveles de profundidad) cuando puede tener dos niveles de .list-menu .dropdown {}

Escribir nombres de clases más abstractos para modificadores

Este se aplica a la mantenibilidad. Un ejemplo común que encontraría en publicaciones similares sería no establecer una variable de color en $ rojo, sino en $ primario o $ secundario.

La razón es que cuando se necesita un cambio en la línea, la variable $ red saldrá azul. Tiene mucho más sentido que quieras cambiar tu color primario , no tu color rojo , ¿verdad?

Lo mismo se aplicaría a otros tipos de colores y propiedades. Digamos que tiene líneas que separan algún contenido (como la etiqueta <hr>). Nombra ese .line-dash porque está discontinuo. Tiene mucho sentido. Pero luego viene un cambio y hay que puntuarlo. ¿Vas y le cambias el nombre a .line-dotted? Este no es un modificador, este es el componente. En lugar de esto, podría nombrarlo como .line-separator. Y luego, si desea ser específico, puede agregar un modificador para .dotted o .dashed. Este tipo de denominación es a menudo lo que lleva más tiempo al construir un sitio.

En resumen

Hay innumerables buenas y malas prácticas. Una forma de lograr mejores resultados es definir reglas y seguirlas. Es difícil idear tales reglas, por lo que una buena sugerencia sería navegar por la web e intentar recopilar toda la información posible sobre arquitectura, como convenciones de nomenclatura, buenas prácticas, cómo escribir código mantenible y más.

Producir un buen código requiere mucho tiempo y cientos de miles de líneas de código. Mientras hace todo eso, siempre pregúntese "¿Esa escala?", "¿Puedo reutilizarlo?", "¿Sobreescribí demasiado?", "¿Tiene sentido nombrarlo así?" Cuanto más lo haga, más óptimas serán sus decisiones y más mejorará su velocidad de trabajo.

Una inversión en buenos fundamentos resultará en menos ida y vuelta en sus proyectos y cualquier cambio futuro que deba ocurrir será mucho más fácil de implementar.