
La fonction `calc()` de CSS nous permet de calculer des valeurs de propriétés. Par exemple, au lieu de déclarer des valeurs fixes pour la largeur d'un élément, nous pouvons utiliser `calc()` pour spécifier que la largeur sera le résultat de l'addition de deux valeurs numériques (ou plus).

```
.foo {
    width: calc(100px + 50px);
}
```

<h2>Pourquoi calc( ) ?</h2>

Si vous avez déjà utilisé des préprocesseurs comme Sass, l'exemple qui précède vous est sans doute familier (<span aria-hidden="true" data-icon="&#9758;"></span> _NdT : sinon, voir le [guide de style Sass](https://sass-guidelin.es/fr/)_).

```
.foo {
    width: 100px + 50px;
}

// Ou en utilisant des variables Sass
$width-one: 100px;
$width-two: 50px;
.bar {
    width: $width-one + $width-two;
}
```

Toutefois, la fonction `calc()` est une meilleure solution, pour deux raisons.

D'abord parce qu'elle permet de mélanger des unités différentes. En particulier, nous pouvons utiliser des pourcentages et des unités de viewport avec des unités absolues telles que les pixels. Par exemple nous pouvons créer une expression qui va soutraire une valeur en pixels à une valeur en pourcentage.

```
.foo {
    width: calc(100% - 50px);
}
```

Dans cet exemple, l'élément `foo` aura toujours une largeur de 50px inférieure à 100% de son élément parent.

Ensuite parce qu'avec `calc()` la valeur calculée est l'expression elle-même et non la valeur résultant de l'expression. Je m'explique&nbsp;: lorsqu'on construit des expressions mathématiques avec les préprocesseurs, la valeur passée au navigateur est la valeur _résultant de l'expression_&nbsp;:

```
// Valeur spécifiée en SCSS
.foo {
    width: 100px + 50px;
}

// Le SCSS est compilé en CSS
// La valeur passée au navigateur :
.foo {
    width: 150px;
}
```

Avec `calc()` la valeur parsée par le navigateur est _l'expression elle-même_&nbsp;:

```
// Valeur spécifiée en CSS
.foo {
    width: calc(100% - 50px);
}

// Valeur calculée dans le navigateur
.foo {
    width: calc(100% - 50px);
}
```

Du coup les valeurs sont dynamiques et s'adaptent aux changements de viewport. Nous pouvons avoir un élément avec une hauteur de viewport moins une valeur absolue, il s'adaptera aux changements du viewport.

<h3>Utiliser calc( )</h2>

On peut utiliser la fonction `calc()` pour additionner, soustraire, multiplier ou diviser des valeurs numériques de propriétés&nbsp;: les data types `<length>`, `<frequency>`, `<angle>`, `<time>`, `<number>`, ou `<integer>`.

Voici quelques exemples :

```
.foo {
    width: calc(50vmax + 3rem);
    padding: calc(1vw + 1em);
    transform: rotate( calc(1turn + 28deg) );
    background: hsl(100, calc(3 * 20%), 40%);
    font-size: calc(50vw / 3);
}
```

<h3>Imbriquer les calc( )</h3>

On peut même imbriquer les fonctions `calc()`. Les fonctions entre parenthèses seront traitées comme de simples expressions. Si nous prenons par exemple&nbsp;:

```
.foo {
    width: calc( 100% / calc(100px * 2) );
}
```

la valeur calculée de cette fonction sera :

```
.foo {
    width: calc( 100% / (100px * 2) );
}
```

<h3>Compatibilité</h3>

La fonction `calc()` est largement supportée. Pour voir la compatibilité à la date de lecture de cet article, vous pouvez consulter —&nbsp;comme toujours&nbsp;— [CanIUse](https://caniuse.com/#feat=calc).

Si un navigateur n'est pas compatible, toute l'expression propriété-valeur est ignorée. Par conséquent la solution de rechange (_fallback_) est simple à mettre en oeuvre, il suffit de fournir une valeur statique qui sera utilisée à la place.

```
.foo {
    width: 90%; /* Fallback pour les anciens navigateurs */
    width: calc(100% - 50px);
}
```

<h2>Quand utiliser calc( ) ?</h2>

On peut utiliser cette fonction dans diverses situations.

<h3>Exemple 1 - Centrer des éléments</h3>

`calc()` nous offre une solution de plus au problème classique du [centrage horizontal et vertical](/articles/centrer-en-css-un-guide-complet/) des éléments à l'intérieur d'un conteneur. Si nous connaissons les dimensions de l'élément enfant, une solution typique est d'utiliser des marges négatives pour déplacer l'élément de la moitié de sa hauteur et de sa largeur&nbsp;:

```
// Avec un élément .foo ayant pour hauteur et pour largeur 300px
.foo {
    position: absolute
    top: 50%;
    left: 50%;
    marging-top: -150px;
    margin-left: -150px;
}
```

Avec la fonction `calc()` nous obtenons le même résultat en n'utilisant que les propriétés `top` et `left`.

```
.foo {
    position: absolute
    top: calc(50% - 150px);
    left: calc(50% - 150px);
}
```

De telles méthodes sont sans doute moins nécessaires maintenant que nous avons [Flexbox](/tags/flexbox/), cependant dans des cas où Flexbox ne peut être utilisé, par exemple si l'élément doit avoir une position absolue ou fixe, cette méthode reste utile.

<h3>Exemple 2 - Créer une dimension de grille à partir de root</h3>

On peut utiliser la fonction `calc()` pour créer une grille basée sur le viewport avec l'unité `rem`. Pour cela, on définit dans l'[élément racine](https://developer.mozilla.org/fr/docs/Web/CSS/:root) (_root_) la font-size comme une fraction de la largeur du viewport.

```
html {
	font-size: calc(100vw / 30);
}
```

Maintenant `1 rem` correspond à 1/30 de la largeur du viewport. Tous les textes dans notre page seront mis à l'échelle automatiquement en fonction du viewport et la même quantité de texte apparaîtra toujours à l'écran quelle que soit sa taille&nbsp;:

<p>
<video width="780" style="width: 100%;" autoplay="" loop="" muted="" playsinline="" poster="https://res.cloudinary.com/ireaderinokun/image/upload/c_scale,q_59,w_780/v1486662717/ezgif.com-optimize_w09wsb.jpg">
    <source type="video/webm" src="https://res.cloudinary.com/ireaderinokun/image/upload/f_auto/v1486662717/ezgif.com-optimize_w09wsb.webm">
    <img src="https://res.cloudinary.com/ireaderinokun/image/upload/c_scale,q_59,w_780/v1486662717/ezgif.com-optimize_w09wsb.jpg" alt="image d'un écran redimensionné, montrant comment le texte s'adapte tout en restant aux mêmes proportions">
</video>
</p>

Si nous donnons à d'autres éléments non-textuels des dimensions en unités `rem`, ìls se comporteront de la même manière.

<h3>Exemple 3 - Clarté</h3>

Enfin, `calc()` peut s'avérer utile pour rendre les calculs plus évidents à comprendre. Si vous voulez qu'un groupe d'éléments aient pour dimension 1/6 de la largeur de leur conteneur parent, vous pourriez l'écrire ainsi&nbsp;:

```
.foo {
	width: 16.666666667%;
}
```

Mais pour les lecteurs de votre CSS, ce serait bien plus clair ainsi&nbsp;:

```
.foo {
	width: calc(100% / 6);
}
```

**Ressources complémentaires en français**

- [La fonction calc() en CSS](https://www.alsacreations.com/article/lire/1630-la-fonction-calc-en-css.html), par Raphaël Goetter
- [calc()](https://developer.mozilla.org/fr/docs/Web/CSS/calc) dans MDN


Comment fonctionne calc()


L'imbrication de sélecteurs est une fonctionnalité des préprocesseurs CSS d'utilisation courante. Tellement courante qu'elle peut devenir problématique. Kitty Giraudel, notre grand spécialiste de Sass, défend une position originale et radicale.

Il y a quelques jours, j'ai envoyé un tweet au sujet de l'imbrication des sélecteurs (_selector nesting_) pour dire qu'ils me créaient plus de problèmes qu'ils n'en résolvaient.

Certains étaient d'accord, d'autres non, mais en tout cas cela a permis d'échanger des idées intéressantes et je me suis dit que j'en ferais bien un petit article.

## Qu'est-ce que l'imbrication de sélecteurs?

L'imbrication de sélecteurs est une fonctionnalité des préprocesseurs CSS qui permet d'emboîter des sélecteurs à l'intérieur d'autres sélecteurs pour créer des raccourcis d'écriture. Par exemple&nbsp;:

```scss
.parent {
  color: red;

  .child {
    color: blue;
  }
}
```

...sera compilé en ceci&nbsp;:

```CSS
.parent {
  color: red;
}

.parent .child {
  color: blue;
}
```

Dans cet exemple, `.child` est emboîté dans `.parent` afin d'éviter la répétition du sélecteur parent.

Ça peut-être tout à fait utile, mais j'ai le sentiment que cette fonctionnalité est très largement sur-utilisée au point que nous en arrivons aujourd'hui à devoir résoudre des problèmes créés par une imbrication inconsidérée.

## Où est le problème de l'imbrication?

En soi, il n'y a pas de problème, la fonctionnalité a un sens. Le problème, comme souvent, est dans la façon dont nous utilisons cette fonctionnalité. Permettez-moi de commencer par deux exemples.

Le premier est de [Micah Godbolt](http://www.phase2technology.com/blog/everything-you-need-to-know-about-sass-3-4/)&nbsp;:

```SCSS
.tabs {
  .tab {
    background: red;
    &:hover {
      background: white;
    }
    .tab-link {
      color: white;
      @at-root #{selector-replace(&, '.tab', '.tab:hover')}{color: red;}
    }
  }
}
```

Le second est de [Zi Qiu](http://sassmeister.com/gist/306744db88c2b6deef78) :

```SCSS
.root {
  width: 400px;
  margin: 0 auto;

  .links {
    .link {
      display: inline-block;

      & ~ .link {
        margin-left: 10px;
      }

      a {
        padding: 10px 40px;
        cursor: pointer;
        background: gray;

        &:hover {
          background: blue;
          color: white;
          font-size: 700;
        }

        .icon {
          margin-right: 5px;
          @include selector-modifier(-2 ':hover', 1 suffix '.zh'){
            color: red;
            background: green;
          }
          @include selector-modifier(-2 ':hover', 1 suffix '.en') {
            color: yellow;
            background: green;
          }
        }
      }
    }
  }
}
```

Une précision pour commencer : Ce code est intelligent. Je ne prétends en aucune façon qu'il s'agisse d'un mauvais code, et je suppose qu'il fonctionne exactement comme il faut.

Maintenant, si je vous demande ce que ces deux exemples sont censés réaliser&nbsp;? En y jetant un coup d'oeil rapide, seriez-vous capable de le dire&nbsp;?

Moi non plus. Parce que c'est compliqué.

### L'imbrication complique le code

Les deux exemples qui précèdent utilisent des fonctions de sélecteurs (de Sass 3.4) pour réécrire partiellement le contexte du sélecteur courant (`&`).

Donc, si je ne me trompe pas, ils utilisent du code supplémentaire afin d'écrire moins de code, et ajoutent une couche de complexité. Pourquoi ne pas écrire un code simple dès l'origine&nbsp;?

Je l'ai déjà dit&nbsp;: les fonctions de sélecteurs ne sont pas faites pour une utilisation standard. Je crois que Chris Eppstein et Natalie Weizenbaum ont dit explicitement qu'ils ajoutaient cette fonctionnalité pour aider les développeurs de frameworks.

_Remarque : si vous trouvez un cas d'utilisation légitime pour les fonctions de sélecteurs, qui résoud vraiment un problème, je vous serais reconnaissant de me le montrer, ça m'intéresserait beaucoup_.

### Le sélecteur de référence est ambigu

Dans Sass, le sélecteur de référence (`&`) peut parfois être ambigu. Selon la façon dont on l'utilise, il peut produire un résultat totalement différent. Voici une série d'exemples simples.

```SCSS
/* SCSS */
.element {
  &:hover {
    color: red;
  }
}

/* CSS */
.element:hover {
  color: red;
}
```

```SCSS
/* SCSS */
.element {
  &hover {
    color: red;
  }
}

/* CSS */
.element:hover {
  color: red;
  }
```

```SCSS
/* SCSS */
.element {
  & .hover {
    color: red;
  }
}

/* CSS */
.element .hover {
  color: red;
  }
```

```SCSS
/* SCSS */
.element {
  &-hover {
    color: red;
  }
}


/* CSS */
.element-hover {
  color: red;
}
```

```SCSS
/* SCSS */
.element {
  &.hover {
    color: red;
  }
}


/* CSS */
.element.hover {
  color: red:
}
```

```SCSS
/* SCSS */
.element {
  .hover& {
    color: red;
  }
}

/* Syntax Error */
Invalid CSS after ".hover": expected "{", was "&"`
`"&" may only be used at the beginning of a compound selector.
```

```SCSS
/* SCSS */
.element {
  &:hover & {
    color: red;
  }
}

/* CSS */
.element:hover .element {
  color: red;
}
```

```SCSS
/* SCSS */
.element {
  &:hover {
    & {
      color: red;
    }
  }
}

/* CSS */
.element:hover {color: red;
}
```

Et nous restons ici dans la simplicité en n'utilisant qu'un seul sélecteur. Inutile de préciser que lorsque vous multipliez les références à l'intérieur d'une règle, les choses peuvent vite devenir complexes.

En fait, certaines opérations fonctionnent, d'autres non (remarquez le message d'erreur dans l'un des exemples). Certains génèrent un sélecteur composé, d'autres non. En fonction du projet, en fonction de l'expérience Sass du prochain développeur qui utilisera le code, ces choses peuvent s'avérer difficiles à débugger.

### Des sélecteurs introuvables

Là, je commence à devenir tatillon. Mais il y a quelque chose que je n'aime pas et qui consiste à utiliser l'imbrication pour créer des sélecteurs du type BEM

```SCSS
.block {
  /* Some CSS declarations */
  &--modifier {
    /* Some CSS declarations for the modifier */
  }
  &__element {
    /* Some CSS for the element */
    &--modifier {
      /* Some CSS for the modifier of the element */
    }
  }
}
```

Avant d'expliquer pourquoi je n'aime pas cela, regardons comment ce code est compilé&nbsp;:

```CSS
.block {
  /* Some CSS declarations */
}
.block--modifier {
  /* Some CSS declarations for the modifier */
}
.block__element {
  /* Some CSS for the element */
}
.block__element--modifier {
   /* Some CSS for the modifier of the element */
}
```

D'un côté, ça permet d'éviter la répétition de `.block` dans chaque sélecteur, ce qui pourrait être dommage quand vous avez des noms de blocs comme `.profil-utilisateur`.

Mais d'un autre côté, ça crée de nouveaux sélecteurs sortis de nulle part et sur lesquels aucune recherche n'est possible&nbsp;: que se passe-t-il si un développeur veut trouver le CSS de `.block__element`&nbsp;? Il y a des chances qu'il le cherche à partir de son environnement de développement et qu'il ne trouve rien parce que ce sélecteur n'a jamais été créé comme tel.

En fait, j'ai l'impression que je ne suis pas le seul à penser ainsi. [Kaelig](https://twitter.com/kaelig), qui a travaillé un temps au Guardian, a envoyé un tweet allant dans le même sens.

De plus, je pense qu'il est meilleur de répéter le nom de base. De cette manière, on voit clairement ce qui se passe.

Je devrais ajouter que les source maps peuvent aider dans une certaine mesure, mais ils ne changent rien au fait qu'on ne peut effectuer de recherche sur la base du code.

## Quand peut-on imbriquer?

Si vous-même et votre équipe êtes à l'aise avec la complexité, on peut toujours imbriquer&nbsp;!

Si vous me posez la question, mon sentiment est que l'ajout de pseudo-classes et de pseudo-éléments est à peu près le seul cas où ça vaut la peine. Par exemple&nbsp;

```SCSS
.element {
  /* Some CSS declarations */
  &:hover,
  &:focus {
    /* More CSS declarations for hover/focus state */
  }
  &::before {
    /* Some CSS declarations for before pseudo-element */
  }
}
```

C'est le meilleur cas d'utilisation de l'imbrication de sélecteurs. Non seulement il permet d'éviter la répétition du même sélecteur, mais en plus il permet de définir l'étendue de cet élément (états et enfants virtuels) à l'intérieur du même ensemble de règles CSS. Enfin, `&` n'est pas ambigu&nbsp;: il signifie `.element`, ni plus, ni moins.

Un autre cas d'utilisation intéressante de l'imbrication est lorsque vous voulez appliquer quelques styles personnalisés à un sélecteur _simple_ en fonction du contexte. Par exemple lorsqu'on utilise les hooks CSS de Modernizr&nbsp;:

```SCSS
.element {
  /* Some CSS declarations */
  .no-csstransforms & {
    /* Some CSS declarations when CSS transforms are not supported */
  }
}
```

Dans ce scénario, j'ai l'impression qu'il est clair que `.no-csstransforms &` sert à contextualiser le sélecteur courant à chaque fois que les transformations CSS ne sont pas supportées. Cela dit, c'est quand même à la limité de ce que je considère acceptable.

## Quelles sont les recommandations?

Écrire un CSS simple. Reprenons l'exemple de Micah, qui est un peu compliqué, mais pas suffisamment pour être difficile à réécrire.

Le code d'origine, dont l'objectif est d'appliquer des styles à une table&nbsp;:

```SCSS
.tabs {overflow: hidden;

  .tab {
    background: red;

    &:hover {
      background: white;
    }

    .tab-link {
      color: white;

      @at-root #{
        selector-replace(&, '.tab', '.tab:hover') {
        color: red;
      }
    }
  }
}
```

...pourrait être écrit ainsi&nbsp;:

```SCSS
.tabs {
   overflow: hidden;
}

.tab {
background: red;

&:hover {
  background: white;
  }
}

.tab-link {
  color: white;

  .tab:hover &
  {
    color: red;
  }
}
```

Je ne peux pas imaginer une seule raison de préférer la première version du code. Elle est non seulement plus longue mais également moins explicite et elle utilise des fonctionnalités Sass qui ne sont pas nécessairement connues de tous les développeurs.

Remarquez que le résultat en CSS n'est pas exactement identique car nous avons aussi simplifié le code. Plutôt que d'avoir des sélecteurs de la taille de `.tabs .tab .tab-link`, nous avons utilisé `.tab-link`, plus simple.

Sur ce point, on n'est plus vraiment dans une discussion sur l'imbrication des sélecteurs, mais plutôt sur les conventions de nommage et sur la méthodologie des sélecteurs. Lorsqu'on utilise BEM par exemple, on nomme les choses selon ce qu'elles sont, plutôt que selon l'endroit où elles sont, ce qui aboutit souvent à des sélecteurs simples (c'est à dire non composés), et donc à moins d'imbrication.

Selon les [directives CSS](http://cssguidelin.es/#css-selectors) de Harry Roberts&nbsp;:

Il est important lorsqu'on écrit du CSS de donner la bonne portée à nos sélecteurs, et de sélectionner la bonne chose pour les bonnes raisons (...) Étant donnée la nature toujours changeante de la plupart des projets UI, et la tendance à aller vers des architectures basées sur des composants, il est de notre intérêt d'appliquer un style aux choses en fonction non de l'endroit où elles sont, mais de ce qu'elles sont.

Une bonne règle générale, s'agissant des sélecteurs CSS, est _plus on fait court et mieux c'est_. Non seulement à tout niveau (performance, simplicité, portabilité, intention, etc.) mais il se trouve qu'il est beaucoup plus simple d'éviter les accidents d'imbrication de sélecteurs lorsque les sélecteurs sont courts.

## Pour conclure

À chaque fois que je dis que l'imbrication de sélecteurs n'est pas une bonne idée, les gens me disent &ldquo;mais je n'ai jamais rencontré un tel problème&rdquo;, &ldquo;je l'utilise tous les jours sans problème&rdquo;, &ldquo;c'est parce que tu fais des trucs de dingue avec ça&rdquo;. Bien sûr, il n'y a pas de problème avec la fonctionnalité elle-même.

Les préprocesseurs ne produisent pas de mauvais code, ce sont les mauvais développeurs qui le font. Et ici, on ne parle même pas du résultat produit, mais de ce qu'on entre initialement. Le code devient de moins en moins lisible lorsqu'on y ajoute des couches de complexité supplémentaires. L'imbrication des sélecteurs est l'une d'elles.

On nous a donné l'imbrication et nous en avons abusé. Puis on nous a donné les fonctions de sélecteurs pour réparer la confusion que nous avions créée. Tout ça est erroné.

Utilisez Sass, ou n'importe quel préprocesseur, pour simplifier votre code, pas pour le rendre plus complexe.


L'imbrication des sélecteurs dans Sass


Depuis quelque temps vous jouez avec Sass, ça vous plaît bien et ça répond à la plupart de vos besoins, mais il y a ce truc que vous ne comprenez toujours pas très bien&nbsp;: _l'interpolation_ -&nbsp;insérer des valeurs à l'intérieur d'autres valeurs. Eh bien nous allons y mettre un peu de clarté/

## Interpo... quoi ?

L'interpolation, qu'on appelle aussi _interpolation de variable_ ou _substitution de variable_ n'est pas une originalité de Sass, en fait on la trouve dans de nombreux langages (PHP, Perl, Ruby, Tcl, Groovy, Unix shells...). On parle souvent d'_interpoler une variable_ ou d'_interpoler une expression_. Pour le dire vite, interpoler consiste à évaluer une expression ou une chaîne de caractères contenant une ou plusieurs variables, et à remplacer lesdites variables par leurs valeurs correspondantes stockées en mémoire.

Hmmm...

Bon, prenons un exemple. Si vous avez des notions de PHP, ce sera facile à comprendre. Admettons que vous vouliez afficher une chaîne de caractères contenant une variable. La façon habituelle de le faire est&nbsp;:

```php
$description = "awesome";
echo "Tuts+ is " . $description . "!";
```

Ceci n'est pas une interpolation. C'est une _>concaténation_ de caractères. En gros, on accroche ensemble trois chaînes de caractères&nbsp;: `"Tuts+ is "` , `"awesome"` et `"!"`. Mais nous pourrions tout aussi bien utiliser l'interpolation&nbsp;:

```php
$description = "awesome";
echo "Tuts+ is ${description}!";
```

Les accolades qui entourent la variable indiquent à PHP d'afficher la valeur de la variable à l'intérieur de la chaîne de caractères. Remarquez au passage qu'il faut des guillemets pour que ça marche en PHP (comme dans la plupart des langages).

Voilà pour l'interpolation de variable ou d'expression. Vous pouvez utiliser la concaténation ou l'interpolation, comme vous voulez, mais disons que l'interpolation apporte un surcroît de douceur syntactique.

## Et Sass là-dedans ?

Regardons maintenant comment fonctionne la substitution de variable dans Sass.

Les noms de variables, dans Sass comme dans PHP, portent le préfixe `$`. La comparaison s'arrête là, car pour l'interpolation Sass et PHP se comportent différemment. La raison est que Sass est construit en Ruby, qui utilise `#{}` pour la substitution d'expression.

En Sass vous feriez&nbsp;:

```scss
$description: 'awesome';
@warn "Tuts+ is #{$description}!";
```

Remarquez qu'avec Sass le signe `$` n'est pas supprimé dans le nom de la variable, contrairement à PHP. Celle-ci est simplement encapsulée, avec `$`, à l'intérieur de `#{}`. À remarquer également le fait que vous pouvez interpoler n'importe quel type de variable, pas uniquement des chaînes de caractères. Par exemple&nbsp;:

```scss
$answer: 42;
@warn "The Answer to the Ultimate Question of Life, the Universe, and Everything is #{$answer}.";
```

## Quand utiliser l'interpolation ?

Maintenant que nous avons compris ce qu'est l'interpolation et comment elle fonctionne dans Sass, il est temps de passer à des cas d'utilisation. Pour le premier, nous allons reprendre ce que nous venons de faire avec la directive `@warn`, qui affiche un contenu dans la console.

### Chaînes de caractères

Supposons que vous ayez une _map_ de couleurs que vous avez appelée `$colors` (une _map_ est une variable qui emmagasine des paires de clés/valeurs, comme une table ou un [array](http://en.wikipedia.org/wiki/Array)), mais que vous en ayez assez de taper `map-get($colors, ...)`&nbsp;: vous construisez une petite fonction `color()` qui va chercher la couleur correspondant à la clé passée en argument. C'est très simple&nbsp;:

```scss
// _config.scss
$colors: (
  'primary': tomato,
  'secondary': hotpink,
);
// _function.scss
@function color($key) {
  @return map-get($colors, $key);
}

// _component.scss
.el {
  background-color: color(primary);
}
```

Pas mal, mais il faudrait y ajouter un message d'alerte au cas où la clé n'existerait pas, ou si vous faites une faute de frappe (au passage, cette [introduction au traitement des erreurs](http://webdesign.tutsplus.com/tutorials/an-introduction-to-error-handling-in-sass--cms-19996) peut vous intéresser). Pour ce faire, on utilise la directive `@warn` à l'intérieur de la fonction `color()`.

```scss
@function color($key) {
  @if not map-has-key($colors, $key) {
    @warn "Key not found.";
  }
  @return map-get($colors, $key);
}
```

OK, et maintenant si vous avez envie d'identifier la clé qui n'a pas été trouvée&nbsp;:

```scss
@function color($key) {
  @if not map-has-key($colors, $key) {
    @warn "Key `#{$key}` not found.";
  }
  @return map-get($colors, $key);
}
```

Et boum, voilà notre interpolation de variable. Appeler `color(awesomeness)` enverra le message suivant dans la console&nbsp;: `Key 'awesomeness' not found`.

C'est bien, mais nous ne connaissons pas réellement le contexte. Pour nous aider à l'avenir, nous pourrions ajouter le nom de la table (map) à l'intérieur du message d'erreur.

```scss
@function color($key) {
  @if not map-has-key($colors, $key) {
    @warn "Key `#{$key}` not found in $colors map.";
  }
  @return map-get($colors, $key);
}
```

Dans ce cas, puisque la variable `$colors` n'a pas été interpolée, son nom sera affiché dans le message d'erreur. `Key 'awesomeness' not found in $colors map.`

### Fonctions CSS

Jusqu'à présent, nous avons vu le cas d'utilisation le plus banal de substitution de variable&nbsp;: afficher le contenu d'une variable à l'intérieur d'une chaîne de caractères. C'est un bon exemple, mais il y en a un encore meilleur&nbsp;: les variables dans les fonctions CSS, par exemple dans [`calc()`](http://www.alsacreations.com/article/lire/1630-la-fonction-calc-en-css.html).

Admettons que vous vouliez dimensionner votre container principal en fonction de la largeur du sidebar. Comme vous êtes un développeur consciencieux, vous avez enregistré cette largeur dans une variable, vous pouvez donc écrire ceci&nbsp;:

```scss
$sidebar-width: 250px;
.main {
  width: calc(100% - $sidebar-width);
}
```

Et là, surprise ! Ça ne marche pas. Il n'y a pas d'erreur Sass, mais votre container n'est pas dimensionné comme il faut. Si vous inspectez ses styles avec DevTools, vous verrez ceci -&nbsp;rayé parce que c'est invalide&nbsp;: `t.main {width: calc(100% - $sidebar-width);}`

Penchons-nous là-dessus une minute. `calc()`est une fonction CSS, pas une fonction Sass. Cela signifie que Sass interprète l'expression tout entière comme une chaîne de caractères. Pour le vérifier, vous pouvez faire&nbsp;:

```scss
$type-of-expression: type-of(calc(100% - $sidebar-width));
// string
```

Puisque c'est une chaîne de caractères, Sass se comporte comme précédemment avec `$colors` dans notre chaîne de caractères `@warn`&nbsp;, donc `$sidebar-width` est considéré comme une chaîne de caractères et elle est affichée comme telle. Mais ce n'est pas ce que nous voulons, n'est-ce pas&nbsp;? Alors interpolons&nbsp;!

```scss
t.main {
  width: calc(100% - #{$sidebar-width});
}
```

Maintenant, lorsque Sass compile la feuille de style, il remplace `#{$sidebar-width}` par la valeur associée à `$sidebar-width`, dans ce cas `250px`, ce qui donne l'expression CSS valide suivante&nbsp;: `t.main {width: calc(100% - 250px);}`

Mission accomplie ! Nous avons parlé de `calc()`, mais nous aurions pu utiliser `url()`, `linear-gradient()`, `radial-gradient()`, `cubic-bezier()` et toute autre fonction CSS native, y compris toutes les [pseudo-classes](http://la-cascade.io/articles/combinateurs-et-pseudo-classes-css/).

Par exemple :

```scss
t@for $i from 1 through $max {
  .el:nth-of-type(#{$i}) {
    // ...
  }
}
```

C'est un cas que vous avez sans doute déjà rencontré&nbsp;: l'utilisation d'une boucle `for` en conjonction avec les sélecteurs `:nth-*()`. Là encore, vous devez interpoler la variable pour qu'elle apparaisse correctement dans le CSS final.

En résumé : Sass traite les fonctions CSS comme des chaînes de caractères, ce qui vous impose d'échapper toute variable utilisée dans la fonction si vous voulez que le CSS soit correct.

### Directives CSS

Passons maintenant à un autre cas intéressant d'utilisation de l'interpolation, les directives CSS comme `@support`, `@page` et surtout `@media`.

Il s'agit ici de la façon dont Sass analyse les directives CSS `@`, en particulier la directive media. J'ai mis mon nez dans le code Sass et, bien que mon niveau de Ruby ne soit pas top, j'ai trouvé des choses intéressantes&nbsp;:

```ruby
def query_expr
  interp = interpolation
  return interp if interp
  return unless tok(/$/)
  res = ['(']
  ss
  res << sass_script(:parse)

  if tok(/:/)
    res << ': '
    ss
    res << sass_script(:parse)
  end
  res << tok!(/$/)
  ss
  res
end
```

En gros, les premières lignes disent à Sass de retourner la media query s'il y a une expression interpolée, ou une erreur, sauf s'il trouve une ouverture de parenthèse, auquel cas il doit continuer et analyser le reste. Essayons avec un exemple&nbsp;:

```scss
$value: screen;

@media $value {
  // ...
}
```

Sans surprise, c'est un échec :  
`Invalid CSS after "@media": expected media query (e.g. print, screen, print and screen), was "$value{"`

Comme l'indique le message d'erreur, Sass attendait une media query. Il faut interpoler votre variable si elle arrive juste après `@media`, par exemple&nbsp;:

```scss
$value: screen;

@media #{$value} {
  // ...
}
```

Comme nous l'avons déduit de notre petite escapade en Ruby, si `@media` est directement suivi de parenthèses `()`, nous n'avons plus besoin d'interpoler la variable parce que Sass évaluera tout ce qui se trouve à l'intérieur des parenthèses. Par exemple&nbsp;:

```scss
$value: 1336px;

@media (max-width: $value) {
  // ...
}
```

Dans ce cas, Sass évalue l'expression `(max-width: $value)`, la transforme en `(max-width: 1337px)` pour aboutir à un résultat CSS valide, il n'y a donc pas besoin d'échapper la variable.

Pourquoi les développeurs de Sass l'ont-ils conçu ainsi, j'ai posé la question à Nathan Weizenbaum et voici sa réponse&nbsp;:

> _D'une manière générale, nous ne voulons pas autoriser l'utilisation de variables "brutes" là où les expressions SassScript ne peuvent être utilisées. C'est le cas des media queries, car SassScript peut être ambigu dans ce contexte (en particulier les maps)_.

### Sélecteurs

Un dernier exemple de cas d'utilisation où nous aurons besoin d'interpoler les variables Sass&nbsp;: Lorsque nous utilisons une variable comme sélecteur, ou comme partie d'un sélecteur. Ce n'est peut-être pas un cas très courant, mais il n'est pas non plus si rare&nbsp;:

```scss
$value: custom;

selector-$value {
  property: value;
}
```

Malheureusement, ça ne marche pas :  
`Invalid CSS after "selector-": expected "{", was "$value {"`

C'est à peu près la même raison que pour les media queries. Sass a sa propre façon d'analyser les sélecteurs CSS. S'il rencontre quelque chose d'inattendu, par exemple un `$` non échappé, il crashe.

Heureusement, ce problème est facile à résoudre, et vous connaissez déjà la solution&nbsp;: l'interpolation&nbsp;!

```scss
$value: custom;

selector-#{$value} {
  property: value;
}
```

### Conclusion

En définitive, l'interpolation Sass n'est pas si simple. Il existe des cas où vous devrez échapper votre variable, d'autres où ce ne sera pas nécessaire. À partir de là, il y a deux façons de faire&nbsp;:

- soit vous attendez un message d'erreur, et vous échappez
- soit vous échappez tout mais avec des valeurs CSS régulières (dont vous savez qu'elles fonctionnent).

J'espère en tout cas que cet article vous aura permis de mieux comprendre comment fonctionne l'interpolation de variable.


Sass et interpolation


Quand j’ai commencé à m’amuser avec Sass il y a un an et demi, j’ai mis un peu de temps à comprendre la différence entre [inclure un mixin](https://sass-lang.com/guide#topic-6) et [étendre un placeholder](https://sass-lang.com/documentation/at-rules/extend#placeholder-selectors). En fait, la notion même de placeholder relevait un peu de la magie noire pour moi.

Si vous êtes dans le même cas, pas d’inquiétude. Aujourd’hui nous allons apprendre exactement à quoi sert un mixin, et quand utiliser un placeholder. Vous verrez qu’ils ont chacun leur utilité et ne doivent pas être confondus.

Remarque : Je parle ici de Sass, mais ce que je décris pourrait s’appliquer à d’autres préprocesseurs CSS, tels Stylus ou LESS, vous pouvez donc adapter le contenu de cet article à l’outil de votre choix.

Pour commencer, un petit rappel sur les mixins et les placeholders.

## Un petit mix

Un mixin est une directive qui vous permet de définir des règles multiples dépendant de plusieurs arguments. Un peu comme une fonction qui au lieu de retourner une valeur renverrait du contenu CSS. Voici la définition donnée par [Sass Reference](https://sass-lang.com/documentation/at-rules/mixin)&nbsp;:

> _Les mixins vous permettent de définir des styles qui peuvent être réutilisés dans votre feuille de style sans avoir besoin de recourir à des classes non-sémantiques telles que `.float-left`. Les mixins peuvent aussi contenir des règles CSS et tout ce qui est permis dans un document Sass. Ils peuvent prendre des arguments qui vous permettent de produire de nombreux styles avec très peu de mixins_.

Voilà pour la terminologie. Supposons maintenant que vous ayez repéré quelques déclarations répétées plusieurs fois dans votre feuille de style. Vous connaissez [le principe DRY](http://fr.wikipedia.org/wiki/Ne_vous_répétez_pas) (Don’t Repeat Yourself) et vous décidez de corriger cela en écrivant un mixin&nbsp;:

```scss
@mixin center() {
  display: block;
  margin-left: auto;
  margin-right: auto;
}

.container {
  @include center();
  /* Other styles here... */
}

/* Other styles... */

.image-cover {
  @include center;
}
```

_NB : si vous ne passez pas d’argument dans votre mixin, vous pouvez omettre les parenthèses. Vous pouvez même les omettre dans la définition du mixin._

Avec ce mixin, vous n’avez pas besoin de répéter ces trois lignes à chaque fois que vous voulez centrer un élément, il suffit d’inclure le mixin. Pratique, non&nbsp;?

Parfois vous aurez besoin de construire des "raccourcis" pour quelques propriétés. Par exemple, `width` et `height`. N’êtes-vous pas fatigué d’écrire toujours ces mêmes lignes, surtout quand elles ont la même valeur&nbsp;? Réglons ça avec un mixin&nbsp;!

```scss
@mixin size($width, $height: $width) {
  width: $width;
  height: $height;
}
```

Simple, n’est-ce pas ? Remarquez que j’ai rendu le paramètre `$height` optionnel en lui donnant la même valeur par défaut que `$width`, directement dans la définition du mixin. Maintenant, à chaque fois que vous voudrez définir les dimensions d’un élément, vous pourrez écrire simplement&nbsp;:

```scss
.icon {
  @include size(32px);
}

.cover {
  @include size(100%, 10em);
}
```

_NB: pour un autre exemple de syntaxe "sucrée", vous pouvez consulter [celle](http://hugogiraudel.com/2013/08/05/offsets-sass-mixin/) que j’ai réalisée pour éviter d’avoir à écrire `top`, `right`, `bottom`, `left` et `position` à chaque fois que je veux un positionnement différent de `static`._

## <span id="ph">Placeholders</span>

Les placeholders sont un peu bizarres. Ce sont des classes qui ne sont pas rendues commes telles lorsque votre SCSS est compilé. Et alors&nbsp;? me direz-vous. En fait, tout irait bien s’il n’y avait cette directive `@extend`. Mais commençons par le commencement, voici comment on écrit un placeholder&nbsp;:

```scss
%center {
  display: block;
  margin-left: auto;
  margin-right: auto;
}
```

En gros, c’est exactement comme écrire une classe, sauf qu’elle est préfixée avec `%` au lieu d’un point. Le placeholder suit les mêmes règles de nommage que les classes.

Si maintenant vous compilez votre SCSS, vous ne verrez pas ce code dans le fichier généré en CSS. Pour l’instant, ce placeholder est totalement inutile. Pour qu’il serve à quelque chose, il faut utiliser `@extend`&nbsp;:

```scss
.container {
  @extend %center;
}
```

Sass va aller chercher le contenu du placeholder `%center` pour l’appliquer à `.container`.

Autre application extrêmement utile d’`@extend`, vous pouvez étendre des sélecteurs CSS existants, de la façon suivante&nbsp;:

```scss
.table-zebra {
  @extend .table;

  tr:nth-of-type(even) {
    background: rgba(0, 0, 0, 0.5);
  }
}
```

C’est un cas d’usage très courant. Dans l’exemple ci-dessus, nous demandons à la classe `.table-zebra` de se comporter exactement comme la classe `.table` (en étendant les règles relatives à cette dernière), puis nous ajoutons des règles spécifiques à zebra.

L’extension de sélecteurs est très pratique quand vous développez votre site/application avec des composants modulaires. Pour en savoir plus sur le sujet, vous pouvez consulter l’article [Sass : tout sur @extend](/articles/sass-tout-sur-extend/).

## Lequel utiliser ?

Eh bien, comme toujours dans notre domaine, _ça dépend_. Cela dépend du contexte et de votre objectif.

Le meilleur conseil serait&nbsp;: si vous avez besoin de variables, utilisez un mixin. Sinon, étendez un placeholder. Il y a deux raisons à cela&nbsp;:

- D’abord, on ne peut pas passer de variables dans un placeholder, donc vous ne pourrez pas générer un CSS spécifique au contexte, comme vous le pourriez avec un mixin.
- Ensuite, la façon dont Sass gère les mixins les rend assez peu pratiques lorsqu’ils ne sont pas utilisés avec des variables contextuelles. Pour le dire simplement&nbsp;: Sass recopie le rendu de votre mixin à chaque fois que vous l’utilisez, ce qui a pour résultat un code dupliqué (contraire au principe DRY) et des feuilles de styles alourdies.

Si nous reprenons notre tout premier exemple&nbsp;:

```scss
@mixin center {
  display: block;
  margin-left: auto;
  margin-right: auto;
}

.container {
  @include center;
}

.image-cover {
  @include center;
}
```

Le résultat CSS après compilation sera&nbsp;:

```css
.container {
  display: block;
  margin-left: auto;
  margin-right: auto;
}

.image-cover {
  display: block;
  margin-left: auto;
  margin-right: auto;
}
```

Vous remarquez la duplication de CSS. Ce n’est pas bien grave s’il n’y a que 3 lignes de code, mais vous imaginez ce que ça peut donner avec des mixins plus complexes et utilisés plus souvent dans un projet. Essayons de réécrire notre petit exemple en utilisant maintenant un placeholder&nbsp;:

```scss
%center {
  display: block;
  margin-left: auto;
  margin-right: auto;
}

.container {
  @extend %center;
}

.image-cover {
  @extend %center;
}
```

Voici le résultat CSS après compilation&nbsp;:

```css
.container,
.image-cover {
  display: block;
  margin-left: auto;
  margin-right: auto;
}
```

Beaucoup mieux ! La compilation s’effectue par [groupage de sélecteurs](http://reference.sitepoint.com/css/selectorgrouping), sans répétition de styles. Conclusion&nbsp;: lorsque vous voulez éviter d’écrire les mêmes propriétés, si vous savez qu’elles ne varieront pas, il faut utiliser un placeholder.

Par contre, si vous voulez écrire les mêmes propriétés mais avec des valeurs différentes, le mixin est préférable. Et si vous avez un groupe de valeurs fixes et variables, vous pouvez essayer une combinaison des deux.

```scss
%center {
  margin-left: auto;
  margin-right: auto;
  display: block;
}

@mixin skin($color, $size) {
  @extend %center;
  background: $color;
  height: $size;
}

a {
  @include skin(pink, 10em);
}
b {
  @include skin(blue, 90px);
}
```

Dans cet exemple, le mixin étend le placeholder pour les valeurs fixes, ce qui génère un CSS propre&nbsp;:

```css
a,
b {
  margin-left: auto;
  margin-right: auto;
  display: block;
}

a {
  background: pink;
  height: 10em;
}

b {
  background: blue;
  height: 90px;
}
```

Et voilà !


Sass mixin ou placeholder


Sass nous offre énormément d’outils pour écrire un CSS cohérent et solide. L’un des plus puissants est `@extend`. La plupart des utilisateurs de Sass connaissent son utilisation, mais il reste quelques parties insuffisamment connues.

Commençons d’abord par les bases.

## Les bases d’@extend

La directive @extend de Sass permet à un sélecteur d’hériter des styles d’un autre. C’est particulièrement utile dans une architecture basée sur les composants, en nous permettant de faire des variations à partir d’un composant.

Voici un cas très basique d’extension d’un sélecteur&nbsp;:

```scss
.message {
  padding: 0.5em;
}

.message-error {
  @extend .message;
}
```

qui est compilé en :

```css
.message,
.message-error {
  padding: 0.5em;
}
```

Facile, non ? Bien sûr l’extension n’est pas limitée aux classes, vous pouvez étendre à peu près tous les sélecteurs (p.ex. `a`), les IDs (p.ex. `#id`) etc. et bien sûr les [placeholders](/articles/sass-mixin-ou-placeholder/#ph) qui fonctionnent explicitement ainsi.

## Extension d’un sélecteur complexe

La plupart du temps, on étend des sélecteurs simples (le plus souvent des classes), mais rien ne vous empêche d’étendre un sélecteur plus complexe, comme `.class element:pseudo` ou même&nbsp;:

```scss
.message + .message {
  margin-bottom: 0.5em;
}

.message-error {
  @extend .message;
}
```

qui sera rendu ainsi :

```css
.message + .message,
.message-error + .message-error,
.message + .message-error,
.message-error + .message {
  margin-bottom: 0.5em;
}
```

Le résultat est maintenant un peu plus complexe, mais si vous comprenez `@extend`, il ne devrait pas trop vous surprendre.

## Extensions multiples

Vous savez certainement que vous pouvez étendre des sélecteurs multiples dans la même règle, mais saviez-vous que vous pouviez le faire avec une directive `@extend` unique&nbsp;?

```scss
.message {
  padding: 0.5em;
}

.important {
  font-weight: bold;
}

.message-error {
  @extend .message, .important;
}
```

La compilation en CSS donne&nbsp;:

```css
.message,
.message-error {
  padding: 0.5em;
}

.important,
.message-error {
  font-weight: bold;
}
```

Si vous me posez la question, je vous dirais que cette méthode n’est pas ma préférée. Le code est certes plus concis, mais je le trouve plus difficile à lire. L’utilisation de directives distinctes pour chaque sélecteur étendu permet de mieux distinguer les sélecteurs et la façon dont ils sont étendus.

Vous pourriez certes réécrire la syntaxe ainsi&nbsp;:

```scss
.message-error {
  @extend .message, .important;
}
```

nmais est-ce vraiment plus lisible&nbsp;?

Pour ma part, je continuerai à écrire `@extend` ligne par ligne, le résultat sera identique, mais chacun peut faire comme il veut.

## Enchaîner les extensions

Nous venons de voir qu’un sélecteur peut être étendu depuis plusieurs sources. Mais vous pouvez également enchaîner vos directives&nbsp;:

```scss
.message {
  padding: 0.5em;
}

.message-important {
  @extend .message;
  font-weight: bold;
}

.message-error {
  @extend .message-important;
}
```

La compilation en CSS donne&nbsp;:

```css
.message,
.message-important,
.message-error {
  padding: 0.5em;
}

.message-important,
message-error {
  font-weight: bold;
}
```

L’exemple ci-dessus est valide, toutefois je vous conseille de ne pas procéder ainsi pour éviter quelques effets indésirables que nous allons examiner maintenant.

## Extension massive

Certains considèrent que le CSS produit par la compilation est _horrible_, et parfois ils peuvent avoir raison. La directive `@extend` est si puissante qu’elle peut aboutir à des extensions [démesurées](http://pastebin.com/Jy9PqFTy). C’est pourquoi il faut toujours être attentif lorsqu’on étend un sélecteur car il étendra _toutes_ les occurrences du sélecteur - ce qui peut rapidement compliquer les choses.

```scss
.important {
  font-weight: bold;
}

.sidebar .important {
  color: red;
}

.message {
  @extend .important;
}
```

La compilation en CSS donne&nbsp;:

```css
.important,
.message {
  font-weight: bold;
}

.sidebar .important,
.sidebar .message {
  color: red;
}
```

Comme vous le voyez, non seulement `.message` a hérité de `.important`, mais il a aussi hérité des instances où `.important` est un sélecteur descendant. Si c’est ce que vous aviez souhaité c’est parfait, mais il arrive que ce soit un effet non désiré, il convient donc d’être prudent avec la directive `@extend`, soit en s’assurant que le sélecteur à partir duquel vous faites l’extension n’existe qu’à un endroit dans votre CSS, soit en étendant un placeholder -&nbsp;qui est fait pour cela.

Dans tous les cas, rappelez-vous que [Sass ne crée pas de mauvais code](http://thesassway.com/editorial/sass-doesnt-create-bad-code-bad-coders-do), ce sont les mauvais développeurs qui le font.

## Préserver l’ordre des sources

Une caractéristique peu connue de @extend dans Sass est la façon dont elle traite l’ordre des sources. Prenons le code suivant&nbsp;:

```scss
.half-red {
  color: rgba(red, 0.5);
}

.message-error {
  color: red;
  @extend .half-red;
}
```

Mis à part le côté non-sémantique du nommage des classes, le code est correct et vous vous attendez à un résultat du genre&nbsp;:

```css
/* Ceci ne sera pas le résultat de la compilation ! */
.message-error {
  color: red;
  color: rgba(255, 0, 0, 0.5);
}
```

Ce serait une façon simple de permettre une [dégradation élégante](http://fr.wikipedia.org/wiki/Amélioration_progressive) pour les navigateurs anciens qui ne supportent pas `rgba()`. Pourtant, ce n’est pas le résultat que nous obtiendrons, au contraire nous aurons&nbsp;:

```css
.half-red,
.message-error {
  color: rgba(255, 0, 0, 0.5);
}

.message-error {
  color: red;
}
```

Mais pourquoi donc ? me direz-vous. Eh bien parce que la directive @extend fonctionne à l’envers. La [documentation Sass](https://sass-lang.com/documentation/at-rules/extend) indique que&nbsp;:

> _@extend fonctionne en insérant le "sélecteur étendant" partout où le "sélecteur étendu" apparaît dans la feuille de style_.

Dans notre exemple, le "sélecteur étendant" est `.message-error` et le sélecteur étendu est `.half-red`.

## Extensions optionnelles

Selon les applications sur lesquelles vous travaillez, vous êtes peut-être amenés à utiliser des frameworks tiers ou des widgets. Si certains sont écrits en Sass, rien ne vous empêche d’étendre des sélecteurs de ces fichiers.

Malheureusement, si le sélecteur étendu n’existe pas, Sass renverra un message d’erreur et la compilation échouera&nbsp;:

> _".message-error" “ failed to @extend “.important”_.  
> _The selector “.important” was not found_.  
> _Use “@extend .important !optional” if the extend should be able to fail_.

Comme vous le voyez, vous pouvez passer un flag `!optional` à vos imports pour éviter qu’ils n’échouent si le sélecteur étendu n’est pas trouvé. Ça peut être utile en cas de conflit entre les sélecteurs étendu et étendant&nbsp;:

```scss
a.important {
  font-weight: bold;
}

p.message-error {
  @extend .important;
}
```

De fait, cela enverra un message d’erreur car les deux sélecteurs sont spécifiés et il est donc impossible de les unifier&nbsp;:

> _No selectors matching “_  
> _.important” could be unified with “p.message-error”_.  
> _Use “@extend .important !optional” if the extend should be able to fail_.

L’ajout de `!optional` à votre `@extend` résoudra ce problème.

## Extensions et media queries

L’un des principaux problèmes avec `@extend` est son incompatibilité avec la directive `@media`&nbsp;: impossible d’étendre à l’intérieur de @media un sélecteur défini à l’extérieur. Malheureusement, Sass ne permet pas les extensions cross-media.

```scss
.important {
  font-weight: bold;
}

@media (max-width: 767px) {
  .message-error {
    @extend .important;
  }
}
```

Vous obtiendrez le message d’erreur suivant&nbsp;:

> _You may not @extend an outer selector from within @media_.  
> _You may only @extend selectors within the same directive_.

Cela est dû au fait que @extend fonctionne en déplaçant les sélecteurs, pas les règles CSS, comme nous l’avons vu tout à l’heure au sujet de l’ordre des sources. Si Sass le permettait, alors l’extension d’un sélecteur situé dans un autre media query donnerait quelque chose comme cela&nbsp;:

```scss
.règle, @media(max-width: 767px) { .autre-règle }, .encore-une-autre-règle {
  /* ... */
}
```

...ce qui n’est clairement pas du CSS valide.

Ceci étant, les développeurs de Sass sont tout à fait conscients du problème, comme le montre le nombre d’occurrences sur leur repo : [#501](https://github.com/nex3/sass/issues/501), [#640](https://github.com/nex3/sass/issues/640), [#915](https://github.com/nex3/sass/issues/915), [#1050](https://github.com/nex3/sass/issues/1050), [#1083](https://github.com/nex3/sass/issues/1083).

Il est donc très probable qu’une solution soit proposée bientôt. Si l’on en croit [ce commentaire](https://github.com/nex3/sass/issues/640#issuecomment-16537355) de Nex3 (un des principaux développeurs de Sass), ce serait une _mixin interpolation_.

## Bonnes pratiques

En résumé, voici ce que j’appellerais les bonnes pratiques d’@extend.

- Vérifiez que le sélecteur étendu est présent, une seule fois, dans la feuille de style.
- Évitez d’étendre depuis des sélecteurs imbriqués.
- Évitez d’enchaîner les directives @extend.
- N’essayez pas d’étendre à l’intérieur d’un media query, ça ne marchera pas.


La Cascade

sass

Ressources complémentaires en français

Ressources complémentaires en anglais