CSS condizionale basato sulla classe del modificatore esterno - buona pratica?


9

Introduzione / background: componenti CSS

Per un sito Web relativamente grande, stiamo lavorando con SASS e stiamo provando a gestire CSS nei componenti. L'idea di base dei componenti è che un componente dovrebbe apparire uguale ovunque, indipendentemente dagli elementi contenitore più in alto nel DOM.

Quindi, vogliamo evitare cose come questa (SASS):

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

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

Invece, se vogliamo che l'immagine dell'utente appaia diversa in prima pagina, dovrebbe essere un componente diverso. Ad esempio con eredità SASS o con un mixin:

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

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

Quindi abbiamo bisogno di regolare l'html in prima pagina, in modo che utilizzi la diversa versione dell'immagine dell'utente.

Fin qui tutto bene. Ho pubblicato quanto sopra come illustrazione della mia attuale comprensione di ciò che riguardano i componenti CSS.

La domanda: classi modificatore - buone pratiche?

Ora stiamo riscontrando un problema: alcune pagine hanno uno sfondo scuro (nero), quindi il testo, i bordi e le cose devono essere bianchi.

Questo in qualche modo va oltre i componenti: lo stesso componente dovrebbe avere testo scuro per impostazione predefinita, ma testo bianco se si trova all'interno di un contenitore con sfondo scuro.

Quindi abbiamo questa fantastica 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;
  }
}

Quindi abbiamo una classe "modificatore" o "contesto" esterna white-on-blackche modifica la modalità di visualizzazione degli elementi interni.

La motivazione è che il componente stesso non è responsabile dello sfondo di un elemento contenitore più in alto nel DOM.

Questo funziona L'unico problema è se abbiamo un contenitore di sfondo bianco all'interno del contenitore di sfondo scuro. Ma a parte questo, funziona bene.

La domanda è se questa è una buona pratica architettonica, con lo sfondo del tentativo di mantenere i componenti indipendenti l'uno dall'altro.

L'alternativa sarebbe quella di avere un componente diverso, ad esempio my-component-on-dark-bg, che eredita my-componente ha un colore diverso per testo e bordi. Ma qui il codice (ad esempio PHP) che produce il componente html deve conoscere l'esterno, cioè se viene usato un dark bg. Supponendo che il codice PHP che esegue il rendering del componente sia separato dal codice PHP che esegue il rendering del contenitore. Che è ancora gestibile, ma potrebbe essere un argomento per il modello con una classe modificatrice, come descritto sopra.

Appunti

In realtà stiamo prefissando le nostre classi CSS con un prefisso specifico del progetto. Ho appena lasciato questo qui per semplicità, e poiché non sono affari di nessuno su quale progetto sto lavorando :).

Risposte:


1

Sembra un design perfettamente difendibile. Rispetto alla proposta alternativa:

  • La duplicazione del codice è inferiore rispetto alla creazione di un set separato di componenti per il bianco su nero.
  • Potrebbe diventare confuso e un po 'disordinato se hai molte modifiche per lo stato bianco su nero.

Penso che sia un appello al giudizio quale design dovrebbe essere preferito, ma andrei con il design scelto se il numero di modifiche personalizzate dei singoli componenti per il bianco su nero fosse relativamente piccolo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.