28172 sujets

CSS et mise en forme, CSS3

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)
Oui, mais ça bug avec SASS. Tu crois que ce serait supporté en CSS vanilla ? Il faudra que je fasse le test...
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)
Bonjour,

vous m'épatez avec vos nouveautés.
J'ai regardé un peu les docs, css nesting se fait "à la main", si j'ai bien compris, à l'inverse des pre-processeurs comme SASS ?
Quand ce sera bien reconnu par les navigateurs, on pourra alors "nettoyer" son css afin de le rendre plus concis et plus clair. C'est ça ou je me trompe sur les objectifs de css nesting ?
Smiley biggrin Smiley biggrin
Bonne nuit.
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)
Bon, finalement, après avoir passé 10 ans sous Stylus et 3 jours sous SASS (.scss), j'ai tenté de remplacer SASS avec PostCSS, ce soir.

Sans compression pour l'instant. En effet ça a bugué avec postcss-csso qui n'a pas aimé certaines formes de nesting ou sélecteurs CSS4, il faut que je trouve une autre approche.
Édit : si, finalement j'ai trouvé une solution temporaire avec postcss-minify.

Avec une commande cli dans mon `package.json` car c'est juste pour tester rapidement pour l'instant :
"cssmain": "postcss styles/development/main.css --use postcss-import postcss-mixins postcss-simple-vars postcss-minify --output styles/main.css --watch --verbose --map"

J'ai dû procéder à quelques adaptations par rapport à SASS (ex : passer de "@mixin" à "@defin-mixin")

Par contre, la coloration syntaxique est atroce, j'ai donc défini en la coloration .css sur ".scss". Il reste toujours plein de warning sous VSC car leurs vérificateurs ne sont pas à jour pour les modules "CSS4" valides.

Au final, d'un fichier de 75.5ko je suis passé à 67.5ko avec le nesting. On peut certainement faire mieux avec un outil de compression plus agressif que postcss-minify. Mais serait-ce souhaitable de faire autre chose que d'enlever des espaces blancs et les commentaires pour gagner 1% ? Je ne crois pas.
Modifié par Olivier C (22 Dec 2023 - 06:26)
Modérateur
Google l'a résumé: CSS Wrapped 2023.

Je trouve ça vraiment incroyable ce qu'il nous est possible de faire nativement aujourd'hui Smiley smile .

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…

Aujourd'hui si on veut une app qui doit en jeter, il faut pouvoir envoyer du CSS de compétition, construire intelligemment, intéragir avec d'autres libs… Clairement des compétences à avoir dans une équipe.


Petite astuce à partager que j'ai découvert aujourd'hui seulement, combiner min() dans le minmax() de grid, pour éviter que son composant ne créé un overflow en dessous d'une certaine taille:
.auto-layout {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(200px, 100%), 1fr))
}

Modifié par Yordi (05 Jan 2024 - 09:02)
@Yordi Oh mais... je crois bien que tu viens de résoudre un de mes problèmes de conception pour mon système de grilles sous Grid Layout ! L'emploie de min() dans minmax()... je n'y avais pas pensé... Jusque là je limitais mes valeurs lorsque j'utilisais auto-fit, je vais tester ta solution urgemment. Merci beaucoup en tous les cas.

En attendant, en guise de remerciement, voici une petite trouvaille pour mapper une balise <progress> dans la nouvelle syntaxe (au passage note l'emploi de la fonction CSS native cos()) :
:root {
  --colorG18: hsl(0, 0%, 18%);
  --color2: hsl(9, 100%, 64%);
  --colorA2: hsla(0, 0%, 100%, 0.2);
  --colorAB2: hsla(0, 0%, 0%, 0.2);
  --colorAB4: hsla(0, 0%, 0%, 0.4);
}

.progress {
  --color: var(--color2);
  /* @todo La déclaration suivante ne semble plus nécessaire si définition de l'élément, à évaluer : */
  /* appearance: none; */
  width: 100%;
  height: 1em;
  border: none;
  animation: anim-progress 4s linear infinite;

  &,
  &::-webkit-progress-bar {
    background-color: var(--colorG18);
    box-shadow: inset 0 0.2em 0.5em var(--colorAB2);
    border-radius: 0.5em;
  }

  &::-webkit-progress-inner-element,
  &::-webkit-progress-bar {
    background-position: inherit;
  }

  /* @note Les deux sélecteurs propriétaires suivant ne peuvent pas être regroupés. Si on utilise un préprocesseur on peut utiliser une mixin pour rester DRY. */
  &::-webkit-progress-value {
    min-width: 1em;
    background-color: var(--color);
    background-image: repeating-linear-gradient(-45deg, transparent 0 0.5rem, var(--colorA2) 0.5rem 1rem);
    background-size: calc(1rem / cos(45deg)) 100%, 100% 800%;
    background-position: inherit;
    box-shadow: inset 0 2px 9px var(--colorA3), inset 0 -2px 6px var(--colorAB4);
    border-radius: 0.5em;
  }

  &::-moz-progress-bar {
    min-width: 1em;
    background-color: var(--color);
    background-image: repeating-linear-gradient(-45deg, transparent 0 0.5rem, var(--colorA2) 0.5rem 1rem);
    background-size: calc(1rem / cos(45deg)) 100%, 100% 800%;
    background-position: inherit;
    box-shadow: inset 0 2px 9px var(--colorA3), inset 0 -2px 6px var(--colorAB4);
    border-radius: 0.5em;
  }
}

@keyframes anim-progress {
  0% {
    background-position: 0 0;
  }
  100% {
    background-position: calc(10 * 1rem / cos(45deg)) 100%;
  }
}

Voir la démo en ligne : Progress.

Auparavant j'utilisais une simple div pour simuler la progression, mais avec le tag HTML natif ma solution CSS précédente ne fonctionnait plus avec tous les navigateurs : la barre de progression bougeait mais son background ne pouvait plus être animée (sous Chrome, avec Firefox ça restait OK), avec le code proposé ci-dessus, c'est OK pour tous les navigateurs.

Merci encore Yordi. Et bonne année !
Modifié par Olivier C (05 Jan 2024 - 02:54)
Mince alors : Yordi t'es un dieu ! Je viens de tester ta solution sur ma base de code et ton système règle effectivement un problème pour lequel j'utilisais une solution de contournement plus lourde et surtout peu souple.

Je voulais justement retoucher prochainement mon système de grille, je vais m'empresser d'utiliser ta solution. Mon système de grille va drastiquement s'alléger, il avait déjà subit un régime depuis le passage à Grid Layout, mais alors là, en terme de souplesse d'utilisation ça va être un truc de fou...

Je ferais un retour sur le forum of course.
Modifié par Olivier C (05 Jan 2024 - 03:07)
Modérateur
Un dieu… ? Tu connais Raphaël Goetter ? Smiley ravi

L'astuce n'est pas de moi, je l'ai vu sur une vidéo de Kevin Powell (contenu en anglais, mais toujours super intéressant, techniques avancées, et très actif).
L'astuce ne vient probablement pas lui non plus, mais le partage est la clé Smiley smile
Yordi a écrit :
Je trouve ça vraiment incroyable ce qu'il nous est possible de faire nativement aujourd'hui Smiley smile .

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)
Prévenir un modérateur
Répondre au sujet
Aller à