BEM La tête la première !

Un block est :

• Une portion d'une page
• Dont le style est indépendant
• Dont le fonctionnel est indépendant

/* syntax */
.block-name { ... }

/* example */
.top-menu { ... }

Un élément est :

• Une portion d'un block
• Il est dépendant de son block
• Il ne peut pas être utilisé sur un autre block

/* syntax */
.block-name__element-name { ... }

/* example */
.top-menu__tab { ... }

Un modifieur :

• modifie les propriétés d'une entité (block ou élément)
• s'utilise de pair avec une entité
• une entité peut avoir plusieurs modifieurs

/* syntax */
.block-name--modifier-name { ... }
.block-name__element-name--modifier-name { ... }

/* example */
.top-menu__tab--active { ... }

<nav class="top-menu">
  <a class="top-menu__tab">Tab 1</a>
  <a class="top-menu__tab">Tab 2</a>
  <a class="top-menu__tab top-menu__tab--active">Tab 3</a>
  <a class="top-menu__tab">Tab 4</a>
</nav>

On retient :

• Block est le noeud racine
• Element compose un block __
• Modifier altère un block ou un élément --

• CSS est simple à apprendre

• CSS est difficile à maîtriser
• CSS est difficile à maintenir

Les symptômes possibles :

• Le temps de développement
• La taille des feuilles de style
• Les aller-retours de bugs
• L'arrivée de nouveau collaborateurs
• Les travaux réservés aux expert

Les électrochocs qui poussent à changer :

• Le responsive
• La marque-blanche
• Les performances front-end
• Le temps de développement

Les noms de classe peuvent être ambigus

<form class="search full">
    <input class="input dropdown">
    <button class="button">
        Search
    </button>
</form>

BEM explicite le rôle de chacun

<form class="search-form c-search-form--full">
    <input class="search-form__input / js-dropdown">
    <button class="button">
        Search
    </button>
</form>

BEM explicite aussi les problèmes de jointures

<form class="search-form c-search-form--full">
    <input class="search-form__input / js-dropdown">
    <button class="button">
        Search
    </button>
</form>

<form class="search-form c-search-form--full">
    <input class="search-form__input / js-dropdown">
    <span  class="search-form__action">
        <button class="button">
            Search
        </button>
    </span>
</form>

BEM permet de regrouper les styles par block.

• Un fichier par block
• Qui contient tous ses éléments et modifieurs
• Qui contient que ses éléments et modifieurs

Si on ne connaît pas toutes les règles d'un fichier :

• On rajoute à la fin du fichier
• On duplique
• On introduit des incohérences
• Les nouvelles ressources pleurent

.news .title { ... }

.news .title { ... }
/* ... */
#sidebar .news .title { ... }

.news .title { ... }
/* ... */
#sidebar .news .title { ... }
/* ... */
.widget .news .title { ... }

.news .title { ... }
/* ... */
#sidebar .news .title { ... }
/* ... */
.widget .news .title,
#sidebar .widget .news .title { ... }

BEM limite l'effet boule de neige :

.news__title { ... }
/* ... */
.news__title--sidebar { ... }
/* ... */
.news__title--widget { ... }

On retient :

• Adopter une méthodologie est indispensable.
• BEM donne du sens aux classes
• BEM Isole les styles, réduit les zones de travail
• BEM Limite la spécificité des sélecteurs, une seule classe !

C'est bien de préfixer ses classes BEM avec c- ?

<nav class="c-menu"></nav>

<nav class="c-menu"></nav>

Oui.

1. On explicite l'usage de BEM même sur les blocks
2. On peut isoler des styles existants, migration douce
3. On peut s'isoler des feuilles externes

La home Du Figaro, c'est :

• 4 525 sélecteurs
• 3 492 noeuds HTML

On peut enlever la classe si elle est redondante avec l'élément ?

<button class="c-button"></button>
/* or */
<button></button>

<button></button>

Non.

1. On explicite l'usage de BEM
2. On permet la réutilisation des styles des boutons ailleurs
3. On permet l'utilisation d'autres styles sur des boutons

On peut enlever le nom du block des modifieurs ?

<div class="c-search-form c-search-form--full"></div>
/* or */
<div class="c-search-form full"></div>

<div class="c-search-form full"></div>

Non.

1. On explicite le sens des modifieurs
2. On uniformise les sélecteurs
3. On s'isole du reste du monde

On peut n'utiliser que le modifieur ?

<div class="c-search-form c-search-form--full"></div>
/* or */
<div class="c-search-form--full"></div>

<div class="c-search-form--full"></div>

Non.

1. On permet l'utilisation de plusieurs modifieurs
2. On simplifie l'ajout et la suppression via JavaScript

Est-ce qu'un modifieur de block peut affecter un élément ?

.c-search-form--full .c-search-form__input { … }

.c-search-form--full .c-search-form__input { … }

Oui.

C'est une exception où ne peut pas limiter la spécificité des sélecteurs.

Est-ce la bonne façon de déclarer les éléments d'élément ?

.c-search-form__label__icon { … }

.c-search-form__label__icon { … }

Non. Il n'y a pas d'élément d'élément. On préfère :

.c-search-form__label-icon { … }
.c-search-form__icon { … }

On retient :

• On préfixe ses classes
• Les éléments d'éléments n'existent pas
• On respecte les règles

BEM est une méthodologie tout terrain :

• Toutes les tailles de projet
• Toutes les tailles d'équipes
• Toutes les stacks techniques
• ...

Surtout BEM respecte la philosophie des CSS

• BEM est facile à apprendre

Alors on évite les opérateurs entre les classes :

.block--big-title > .block__title { … } /* non */
.block--big-title .block__title { … }   /* oui */

Pour limiter la spécificité des sélecteurs,

on préfère les modifieurs d'éléments aux modifieurs de blocks :

<div class="block">
    <div class="block__title block__title--big"></div>
</div>

Pour limiter la dépendance entre plusieurs règles CSS,

on préfère encore plus créer un nouveau sélecteur :

<div class="block">
    <div class="block__big-title"></div>
</div>

Tout le principe de BEM est basé sur l'isolation des styles.

Attention aux partage de code :

• @extends en Sass
• @mixins en Sass

C'est aussi valable pour l'implémentation des blocks :

<div class="block">
    <div class="block__big-title"></div>
</div>

.c-alert--info,
.c-alert--warning,
.c-alert--error {
    padding: 5px 10px;
}

On ne peut pas styler un composant avec son contexte.

.c-sidebar .c-article { ... } /* non */

Il faut concevoir différement, pas juste changer la façon décrire.

.c-article--sidebar { ... } /* non */

Sinon vous aller juste limiter la réutilisation de votre code.

Décrivez plutôt quel changement visuel vous souhaitez.

Il faut d'abord éviter le sur-découpage.

Se laisser guider par l'usage :

• Si deux blocks sont toujours utilisés ensemble,
  c'est sûrement le même block
• Si un élément peut être utilisé ailleurs,
  c'est sûrement un block différent

Quelle est la taille maximale d'un block ?

• A : 50 lignes de CSS
• B : 100 lignes de CSS
• C : 200 lignes de CSS
• D : ça dépend

On retient :

• Les modifieurs ne sont pas la norme
• On accepte de se répéter
• On découpe en fonction de l'usage
• On ne se dimensionne pas soit-même

Vous ne devriez utiliser que des mixins qui ne sont pas spécifiques à votre projet :

• clearfix
• ellipse de texte
• texte caché accessible
• ...

Vos mixins ne doivent pas générer de sélecteurs !

On peut concaténer nos classes en Scss :

.block {
    &__element {
        ...
        &--modifier { ... }
    }
}

Ceci génére le code CSS suivant :

.block { ... }
.block__element { ... }
.block__element--modifier { ... }

Mais un modifieur de block peut limiter cette écrite :

.block {
    &__element { ... }
    &--modifier &__element { ... }
}

Les variables peuvent être accesibles depuis un autre block :

$block-height: 50px;
.block {
    &__element { height: $block-height; }
}
/* Leak */
.other-block { height: $block-height; }

Pour isoler vos variables :

.block {
    $height: 50px;
    &__element { height: $height; }
}
/* Doesn't work. No leak! */
.other-block { height: $height; }

On peut alors sauvegarder notre block dans une variable :

.block {
    $block: &;
    &__element {
        ...
      #{$block}--modifier & { ... }  
    }
}

Attention, à ne pas abuser de la concaténation qui rend impossible les fonctionnalités de rechercher / remplacer

Si vous voulez des variables locales sans concaténation :

.block {
    $height: 50px;
    @at-root {
      .block__element { height: $height; }
    }
}

On retient :

• On limite les mixins
• On isole les variables
• On choisit si on souhaite concaténer ou non

BEM a de gros avantages :

• Le concept simple à comprendre
• La mise en place est souple
• Ce n'est pas lié à un outils
• BEM est compatible avec les autres méthodologies

On lui reproche :

• Trop de redondance
• Trop de nommage
• Des problèmes de scalabilité avec le nombre de blocks

Une idée est d'importer des règles d'OOCSS :

• Séparer la structure de l'habillage (CSS)
• Séparer le conteneur du contenu (HTML)

<div class="c-menu">
    <div class="l-grid">
        <div class="l-grid__cell">
            <a class="c-menu__tab"></a>
        </div>    
    </div>
</div>

Une autre idée est de remplacer les modifieurs BEM par des classes atomiques :

• Les modifieurs sont difficiles à nommer
• Les modifieurs sont complexes

<div class="c-article">
    <h1 class="c-article__title u-uppercase"></h1>
    <div class="c-article__status u-green"></div>
</div>

On retient :

• BEM n'est pas une impasse
• Il faut aller voir ce qui se fait ailleurs
• Il faut trouver sa méthodologie