Pour
@if je comprends, mais tu vois, pour ce cas d'usage précis, celui donné dans l'exemple, j'opterais pour une approche vanilla CSS tout de même :
:root {
color-scheme: light dark;
--shadow-core-1: 0 2px 4px rgba(0, 0, 0, 0.1);
--shadow-core-2: 0 4px 8px rgba(0, 0, 0, 0.15);
--shadow-core-3: 0 8px 16px rgba(0, 0, 0, 0.2);
--shadow-glow-dark: 0 0 12px rgba(255, 255, 255, 0.05);
/* Thème clair par défaut */
--elevation-1: var(--shadow-core-1);
--elevation-2: var(--shadow-core-2);
--elevation-3: var(--shadow-core-3);
}
@media (prefers-color-scheme: dark) {
:root {
/* Concaténation de ombre + Lueur */
--elevation-1: var(--shadow-core-1), var(--shadow-glow-dark);
--elevation-2: var(--shadow-core-2), var(--shadow-glow-dark);
--elevation-3: var(--shadow-core-3), var(--shadow-glow-dark);
}
}
.card {
box-shadow: var(--elevation-2);
}
.modal {
box-shadow: var(--elevation-3);
}
Petit bonus ici : Le composant .card ignore totalement s'il est en thème clair ou sombre. Il n'a pas besoin de la classe utilitaire .modal-dark. Il demande le "niveau 2", et le pipeline CSS lui fournit la donnée exacte pré-calculée à la racine.
---
Tout ça m'a titillé alors j'ai cherché : apparemment, l'intérêt de @if de nos jours serait de supprimer du code mort, en ciblant la plateforme qui devra supporter l'application.
On pourrait alors faire par exemple :
@if $target-profile == 'embedded' {
// Un fallback pour du legacy :
border: 1px solid rgba(0, 0, 0, 0.15);
background-color: #ffffff;
} @else {
// Pour le support standard :
background-color: rgba(255, 255, 255, 0.8);
backdrop-filter: blur(#{$depth}px);
box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
will-change: transform;
}
Donc,
quelque chose d'externe à la logique du code ; c'est un invariant très fort pour moi, et suffisant pour que j'apprenne à m'en passer pour l'instant si le CSS vanilla est suffisant.
---
Pour la boucle
@for par contre, je suis convaincu moi aussi par le besoin, je l'ai intégré à mon pipeline d'ailleurs. MAIS : je l'utilise de façon naïve, juste des itérations avec
i :
.demo-items-color {
$demoColorDeg: 15;
$demoColorDeviation: 7;
@for $i from 1 to 15 {
& > :nth-child($(i)n) {
background-color: hsl(calc($i * $demoColorDeviation - $demoColorDeviation + $demoColorDeg),
100%,
50%);
}
}
}
Cela me fait prendre conscience d'une chose : il manque à mon pipeline une résolution AOT de
calc() lorsque cela est possible, résolution que fait un plugin comme
PostCSS Calc :
/* Avant : */
h1 {
font-size: calc(16px * 2);
height: calc(100px - 2em);
width: calc(2 * var(--base-width));
margin-bottom: calc(16px * 1.5);
}
/* Après : */
h1 {
font-size: 32px;
height: calc(100px - 2em);
width: calc(2 * var(--base-width));
margin-bottom: 24px;
}
Il faudra donc que j'ajoute cette fonctionnalité à mon pipeline. Rien que pour avoir trouvé l'importance builder calc() lorsque c'est possible (mon intuition initiale, mais je ne l'avais pas mise en œuvre) ça valait le coup de vous poser la question sur le forum. Je vous remercie pour cela.
Bonne soirée à vous.
Modifié par Olivier C (04 Sep 2026 - 13:05)
.
