CSS conditionnel basé sur une classe de modificateurs externes - bonne pratique?


9

Introduction / contexte: composants CSS

Pour un site Web relativement grand, nous travaillons avec SASS et essayons de gérer le CSS dans les composants. L'idée de base des composants est qu'un composant doit avoir la même apparence partout, indépendamment des éléments conteneurs plus haut dans le DOM.

Donc, nous voulons éviter des trucs comme ça (SASS):

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

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

Au lieu de cela, si nous voulons que l'image de l'utilisateur soit différente sur la première page, elle devra être un composant différent. Par exemple avec l'héritage SASS, ou avec un mixin:

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

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

Ensuite, nous devons ajuster le html sur la première page, afin qu'il utilise la version différente de l'image de l'utilisateur.

Jusqu'ici tout va bien. J'ai posté ce qui précède comme une illustration de ma compréhension actuelle des composants CSS.

La question: les classes de modificateurs - bonnes pratiques?

Nous rencontrons maintenant un problème: certaines pages ont un arrière-plan sombre (noir) et le texte, les bordures et les éléments doivent donc être blancs.

Cela va en quelque sorte au-delà des composants: le même composant doit avoir du texte sombre par défaut, mais du texte blanc s'il se trouve dans un conteneur avec un fond sombre.

Nous avons donc cette idée géniale:

// 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;
  }
}

Nous avons donc une classe externe "modificateur" ou "contexte" white-on-blackqui modifie la façon dont les éléments internes sont affichés.

La motivation est que le composant lui-même n'est pas responsable de l'arrière-plan d'un élément conteneur plus haut dans le DOM.

Cela marche. Le seul problème est que si nous avons un conteneur à fond blanc dans le conteneur à fond sombre. Mais cela mis à part, cela fonctionne bien.

La question est de savoir si c'est une bonne pratique sur le plan architectural, avec pour arrière-plan d'essayer de garder les composants indépendants les uns des autres.

Une alternative serait d'avoir un composant différent, par exemple my-component-on-dark-bg, qui hérite my-componentet a la couleur différente pour le texte et les bordures. Mais ici, le code (par exemple PHP) qui produit le composant html doit connaître l'extérieur, c'est-à-dire si un bg sombre est utilisé. En supposant que le code PHP qui rend le composant est distinct du code PHP qui rend le conteneur. Ce qui est toujours gérable, mais pourrait être un argument pour le modèle avec une classe de modificateurs, comme décrit ci-dessus.

Remarques

Nous préfixons actuellement nos classes CSS avec un préfixe spécifique au projet. Je viens de laisser cela ici pour plus de simplicité, et parce que ce n'est l'affaire de personne sur quel projet je travaille :).

Réponses:


1

Cela semble être une conception parfaitement défendable. Par rapport à votre alternative proposée:

  • Il y a moins de duplication de code que la création d'un ensemble distinct de composants pour le blanc sur noir.
  • Cela peut devenir déroutant et un peu désordonné si vous avez beaucoup de modifications pour l'état blanc sur noir.

Je pense que c'est un jugement qui doit être préféré, mais j'irais avec votre conception choisie si le nombre de modifications personnalisées de composants individuels pour le blanc sur noir était relativement faible.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.