CSS condicional basado en una clase de modificador externo: ¿buena práctica?


9

Introducción / antecedentes: componentes CSS

Para un sitio web relativamente grande, estamos trabajando con SASS e intentamos administrar CSS en componentes. La idea básica de los componentes es que un componente debe tener el mismo aspecto en todas partes, independientemente de los elementos del contenedor más arriba en el DOM.

Entonces, queremos evitar cosas como esta (SASS):

// User picture component.
.user-picture {
  img {..}
}

// Override user picture for the frontpage.
body.page-front .user-picture img {..}

En cambio, si queremos que la imagen del usuario se vea diferente en la portada, tendría que ser un componente diferente. Por ejemplo, con herencia SASS, o con una mezcla:

// User picture component.
.user-picture {
  img {..}
}

// User picture on frontpage.
.user-picture-front {
  @extend .user-picture;
  img {..}
}

Luego, debemos ajustar el html en la página principal, para que use la versión diferente de la imagen del usuario.

Hasta aquí todo bien. Publiqué lo anterior como una ilustración de mi comprensión actual de los componentes CSS.

La pregunta: Clases modificadoras: ¿buenas prácticas?

Ahora nos encontramos con un problema: algunas páginas tienen un fondo oscuro (negro), por lo que el texto, los bordes y demás deben ser blancos.

Esto de alguna manera va más allá de los componentes: el mismo componente debe tener texto oscuro de forma predeterminada, pero texto blanco si está dentro de un contenedor con fondo oscuro.

Entonces tenemos esta increíble idea:

// Generic modifier class for all dark-background containers.
.white-on-black {
  // Generic text color change.
  color: white !important;
}

// Component.
.my-component {
  border: 1px solid blue;
  // Special for white-on-black.
  .white-on-black & {
    border-color: yellow;
  }
}

Así que tenemos una clase externa de "modificador" o "contexto" white-on-blackque modifica cómo se muestran los elementos internos.

La motivación es que el componente en sí no es responsable del fondo de un elemento contenedor más arriba en el DOM.

Esto funciona. El único problema es si tenemos un contenedor de fondo blanco dentro del contenedor de fondo oscuro. Pero esto aparte, funciona bien.

La pregunta es si esto es arquitectónicamente una buena práctica, con el trasfondo de tratar de mantener los componentes independientes entre sí.

La alternativa sería tener un componente diferente, por ejemplo my-component-on-dark-bg, que hereda my-componenty tiene un color diferente para el texto y los bordes. Pero aquí el código (por ejemplo, PHP) que produce el componente html necesita saber sobre el exterior, es decir, si se usa un bg oscuro. Suponiendo que el código PHP que representa el componente está separado del código PHP que representa el contenedor. Lo que todavía es manejable, pero podría ser un argumento para el patrón con una clase modificadora, como se describió anteriormente.

Notas

En realidad, estamos anteponiendo nuestras clases CSS con un prefijo específico del proyecto. Acabo de dejar esto aquí por simplicidad, y porque no es asunto de nadie en qué proyecto estoy trabajando :).

Respuestas:


1

Parece un diseño perfectamente defendible. En comparación con su alternativa propuesta:

  • Hay menos duplicación de código que crear un conjunto separado de componentes para blanco sobre negro.
  • Puede ser confuso y un poco complicado si tiene muchas modificaciones para el estado blanco sobre negro.

Creo que es una decisión acertada qué diseño se debe preferir, pero elegiría el diseño elegido si el número de modificaciones personalizadas de componentes individuales para blanco sobre negro fuera relativamente pequeño.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.