Comme l'a dit une fois Phil Karlton, “There are only two hard things in Computer Science: cache invalidation and naming things.”

Je ne commenterais pas l'affrimation ci-dessus, mais la seconde partie m'a tourmenté pendant des années. My advice with regard to naming things in CSS is to pick a name that is sensible, but somewhat ambiguous: aim for high reusability. For example, instead of a class like .site-nav, choose something like .primary-nav; rather than .footer-links, favour a class like .sub-links.

La différence entre ces noms est que cahcun des premiers exemples est lié à un cas d'usage très spécifique : ils ne peuvent être utilisés respectivement que pour la navigation du site our pour les liens du footer. En utilisant des noms très légèrement plus ambigus, on augmente notre capacité à réutiliser ces composants dans différentes circonstances.

Pour citer Nicolas Gallagher:

Lier fortement la sémantique de vos noms de classes à la nature de leur contenu réduit déjà la capacité de votre architecture à être étendue ou utiliser par d'autres développeurs.

C'est à dire que nous devrions utiliser des noms raisonnables — des classes comme .border ou .red ne sont jamais conseillées — mais nous devrions éviter d'utiliser des classes qui décrivent la nature exacte du contenu ou/et de ses cas d'usage. Utiliser un nom de classe pour décrire un contenu est redondant du fait que le contenu se décrit lui-même.

Le débat concernant la sémantique à fait rage de nombreuses années, mais il est important d'adopter une approche olus pragmatique, raisonnable concernant le nommage des choses afin de travailler de manière efficace. Plutôt que de se focaliser sur 'la sémantique', attachons-nous davantage à un usage raisonné et durable — choisir des noms sur la base de leur maintenabilité, et non pour leur sens perçu.

Nommez les choses pour les personnes, ce sont en réalité les seules qui lisente vos classes (le reste ne fait qu'au mieux les comparer). Une fois encore, il est préférable de s'attacher à des classes réutilisables, recyclables plutôt que d'écrire pour des cas spécifiques. Prenons un exemple :

/**
 * Runs the risk of becoming out of date; not very maintainable.
 */
.blue {
  color: blue;
}

/**
 * Depends on location in order to be rendered properly.
 */
.header span {
  color: blue;
}

/**
 * Too specific; limits our ability to reuse.
 */
.header-color {
  color: blue;
}

/**
 * Nicely abstracted, very portable, doesn’t risk becoming out of date.
 */
.highlight-color {
  color: blue;
}

Il est important de faire la part des choses entre des noms qui ne décrivent pas ce que la classe amène, mais aussi qui ne décrivent pas explicitement les cas d'usage. Au lieu de .home-page-panel, choisissez .masthead; au lieu de .site-nav, préférez .primary-nav; au lieu de .btn-login, optez pour .btn-primary.

Nommez les composants avec agnosticisme et avec leur réutilisabilité en vue aide réellement les développeurs à construire et modifier les Interfaces Utilisateurs bien plus rapidement, et avec bien moins de ressources perdues. Cependant, il est parfois bénéfique de fournir un nommage plus spécifique ou signifiant avec des classes plus ambigues, particulièrement lorsque plusieurs classes agnostiques forment ensemble un composant plus complexe et spécifique qui pourrait bénéficier d'un nom plus signifiant. Dans ce scénario, on augmente les classes avec un attribut data-ui-component qui héberge un nom plus spécifique, par exemple :

<ul class="tabbed-nav" data-ui-component="Main Nav">

Ici nous avons le bénéfice d'une classe hautement réutilisable qui ne décrit pas — et, de ce fait, ne se lie pas à — une classe spécifique, et un sens ajouté grâce à notre attribut data-ui-component. La valeur de l'attribut data-ui-component peut prendre le format que vous voulez, like title case:

<ul class="tabbed-nav" data-ui-component="Main Nav">

Ou class-like:

<ul class="tabbed-nav" data-ui-component="main-nav">

Ou namespaced:

<ul class="tabbed-nav" data-ui-component="nav-main">

L'implémentation est largement question de préférence, mais le concept reste le même : Ajouter du sens spécifique et utile via un mécanisme qui n'inhibera pas votre capacité ou celle de votre équipe à recylcler et réutiliser le CSS.