L'imbrication CSS (CSS nesting)

Bonjour,

A propos du nesting récemment pris en charge par CSS et les navigateurs, j'ai un logo avec la classe ".logo-nav" qui est un lien sur les pages du site, mais une div sur la page d'accueil. Dans mes styles j'ai fait du nesting pour ce composant comme pour tous les autres, mais je me retrouve coincé à un endroit, je n'arrive pas à fusionner les deux ensembles.

Pour commencer voici l'exemple qui fonctionne avec deux ensembles de règles imbriquées :

.logo-nav {
  grid-area: logo;
  display: block;
  box-shadow: 0.5rem 0.5rem 0.5rem var(--colorAB2);
  background-color: var(--color2);

  &::after {
    content: '';
    display: block;
    width: 100%;
    height: 100%;
    background-image: url('../medias/images/logo/logo.svg');
    background-repeat: no-repeat;
    background-position: 50% 50%;
    background-size: auto 70%;
    filter: brightness(1.25) contrast(1.25);
  }
}

a.logo-nav:where(:focus-within, :hover) {
  background-color: var(--color5);

  &::after {
    animation: anim-logo 0.5s ease-in-out;
  }
}

Pour lier ces deux ensembles j'ai tenté quelque chose comme ceci (qui ne marche pas mais pour vous donner l'idée recherchée) :

.logo-nav {
  grid-area: logo;
  display: block;
  box-shadow: 0.5rem 0.5rem 0.5rem var(--colorAB2);
  background-color: var(--color2);

  &::after {
    content: '';
    display: block;
    width: 100%;
    height: 100%;
    background-image: url('../medias/images/logo/logo.svg');
    background-repeat: no-repeat;
    background-position: 50% 50%;
    background-size: auto 70%;
    filter: brightness(1.25) contrast(1.25);
  }

  &a:where(:focus-within, :hover) { /* <-- nop... */
    background-color: var(--color5);
  
    &::after {
      animation: anim-logo 0.5s ease-in-out;
    }
  }
}

J'ai une question subsidiaire, elle concerne SASS : l'imbrication des règles CSS va considérablement alléger le poids des pages en évitant toute redondance des sélecteurs... si l'on n'utilise pas un préprocesseur du moins, car ce denier convertit tout par soucis de rétrocompatibilité. Alors ok je comprends, mais peut-on configurer la compression des fichiers de sortie dans SASS (pas pour la prod', mais pour faire des tests) ? J'ai bien peur de connaitre la réponse car je n'ai rien trouvé à ce sujet...
Modifié par Olivier C (21 Dec 2023 - 04:01)

Mince, ça marche en vanilla ! : CodePen
Modifié par Olivier C (21 Dec 2023 - 10:17)

Waaaaah j'avais loupé une sacré news effectivement...
Incroyable que le nesting arrive dans CSS natif : https://jsfiddle.net/0wejcvyt/2/

Apres les variables...

Ah c'est sûr que cette année ça a été Noël. Des trucs attendus depuis longtemps sont enfin tombés, et surtout sont enfin supportés par la majorité des navigateurs du marché.

On a désormais comme ajout révolutionnaire (selon moi) :
- les variables bien sûr, et surtout des variables avec lesquelles le html peut interagir, rien à voir avec des variables compilées (lorsqu'ils en parlent pour les présenter, les blogs de dev's oublient presque tous ce point fondamental),
- le sélecteur :has() (Firefox le supporte enfin sur sa version Nightly),
- les container queries (pour moi le truc le plus important),
- les sélecteurs de regroupement :where() et :is(),
- les opérateurs logiques,
- subgrid (déjà mentionné par Niuxe),
- et j'en passe et des meilleures, par exemple les fonctions trigonométriques (sin(), cos(), etc.).

J'utilise les quatre premiers items depuis quelques mois maintenant et ça passe crème sur les nouveaux navigateurs. Pour les navigateurs dont la mise à jour est bloquée (comme chez moi, dans le CHU dans lequel je travaille), c'est sûr que là, rien ne fonctionne.

Pour l'instant il me manque le support des variables dans les medias queries ou les container queries, ce que var() ne peut pas faire, mais qui sera peut-être le rôle de env() (et ce dernier sera loin d'avoir ce seul rôle). J'attends aussi avec impatience le support d'un masonry full CSS qui doit se greffer sur le module grid layout.

Quand à Autoprefixer, vu que les navigateurs limitent désormais l'utilisation des préfixes à des éléments de shadow DOM qui les concernent spécifiquement, et que donc il faut définir au cas par cas, il ne sert plus à grand chose (à en croire CSS-Tricks, les dev's de Chrome auraient reconnu que l’excès dans cette voie à contribuer à mettre dans l'impasse de nombreux sites webs).

Le temps des pré/post/processeur est donc bientôt révolu. Il restera la fonction @import, qui coûtera toujours une requête serveur par appel et que CSS ne va pas concaténer magiquement. Il faudra alors paramétrer un script pour faire le taf de concaténation, avec une bonne minification derrière pour optimiser le tout, et hop, ce sera plié.

Les mixins, ça peut être intéressant pour éviter du code redondant sur des propriétés non cumulables entre elles (par exemple ::-webkit-slider-thumb vs ::-moz-range-thumb), mais si elle existe la redondance n'est pas si courante (je rencontre le cas une fois ou deux sur des fichiers de 74ko une fois compilés), enfin lorsque l'on est trop obligé d'y avoir recours c'est que l'on a un problème de conception de toute façon.

En gros avec un outil de type PostCSS on pourrait actuellement configurer un truc pour concaténer les @import, avec un système pour les variables dans les medias queries, et enfin un CSSO...
Modifié par Olivier C (23 Dec 2023 - 00:45)

Oui, je crois que tu y est. Le CSS va par conséquent s'alléger de manière drastique.

Par exemple, avant je pouvais avoir ça :

.list-straight,
.list-rounded {
  margin: 0;
  padding-inline-start: 0;
}
.list-straight li,
.list-rounded li {
  display: grid;
  grid-template-columns: 3em minmax(0, 1fr);
}
.list-straight li:focus-within,
.list-rounded li:focus-within,
.list-straight li:hover,
.list-rounded li:hover {
  animation: anim-list 0.05s ease-in-out;
}
.list-straight li:focus-within svg,
.list-rounded li:focus-within svg,
.list-straight li:hover svg,
.list-rounded li:hover svg,
.list-straight li:active svg,
.list-rounded li:active svg,
.list-straight li:focus-within::before,
.list-rounded li:focus-within::before,
.list-straight li:hover::before,
.list-rounded li:hover::before,
.list-straight li:active::before,
.list-rounded li:active::before {
  color: #fff;
  background-color: #ffa600;
}

En comparaison, comme équivalence j'aurais plutôt quelque chose comme ça :

.list-straight,
.list-rounded {
  margin: 0;
  padding-inline-start: 0;

  & li {
    display: grid;
    grid-template-columns: 3em minmax(0, 1fr);

    &:focus-within,
    &:hover {
      animation: anim-list 0.05s ease-in-out;
    }

    &:where(:focus-within, :hover, :active) svg,
    &:focus-within::before, /* ces trois derniers items je n'ai pas réussi à les factoriser, mais c'est peut-être possible */
    &:hover::before,
    &:active::before {
      color: var(--colorW);
      background-color: var(--color5);
    }
  }
}

Modifié par Olivier C (21 Dec 2023 - 22:47)

Yordi a écrit :
Je trouve ça vraiment incroyable ce qu'il nous est possible de faire nativement aujourd'hui .

Encore plus dingue à mon sens que l'intégrateur (comme on disait avant) ne soit pas autant recherchés qu'un développeur React (ou autre profils du moment). Les front-end comprennent généralement mieux le back-end que le CSS j'ai l'impression…
On est encore à penser que le CSS n'est pas un vrai language, que tout le monde ajoute ça sur son CV parce qu'il/elle connait border-radius…

J'en ai même vu certains se vanter sur les forums d'avoir parcouru CSS en deux semaines/un mois et qu'ils pouvaient désormais passer aux choses sérieuses...

De mon côté j'ai toujours trouvé les langages de programmation plus simples à maitriser que le CSS. (pour les langages, le plus dur, en vrai, c'est la maîtrise de leur écosystème). En plus, dès que tu en as appris un, la montée en compétences pour les suivants est nettement plus courte.

Et pour ce qui concerne JavaScript : ce n'est pas la même chose d'utiliser JS côté backend sous Node.js que de manipuler son API DOM qui est par elle-même un monde en soit. Sans parler des Web Components et des Applications web progressives (PWA).

Mais pour en revenir aux styles : je pense que le fait de débattre pour savoir si CSS est un vrai langage de programmation ou non n'est pas la bonne approche. Pour moi le CSS est avant tout une grammaire, une science pour laquelle il faut savoir conjuguer les règles de styles. Tout le monde peut prétendre savoir conjuguer au présent, mais seul les meilleurs grammairiens seront en capacité de pouvoir faire des merveilles.

N'oublions pas aussi le HTML et toutes ses subtilités, ou encore les ARIA et autres Micro Data...

Ça commence à faire beaucoup.
Modifié par Olivier C (08 Jan 2024 - 22:52)