Approfondir les requêtes de style conteneur

J'ai rédigé quelques premières réflexions sur les requêtes de style conteneur il y a quelque temps. C’est encore tôt. Ils sont déjà définis dans la spécification de niveau 3 du module de confinement CSS (actuellement dans l'état du projet de l'éditeur), mais il y a encore quelques discussions en cours.

L'idée de base est que nous pouvons définir un conteneur, puis appliquer des styles conditionnellement à ses descendants en fonction de son style calculé.

@container <name>? <conditions> {
  /* conditional styles */
}

Le meilleur exemple que j'ai vu jusqu'à présent est de supprimer les italiques de quelque chose comme & lt; em & gt;, & lt; i & gt;, et & lt; Q & gt; Lorsqu'ils sont utilisés dans un contexte où le contenu est déjà en italique:

em, i, q {
  font-style: italic; /* default UA behavior */
}

/* When the container's font-style is italic, remove italics from these elements. */
@container style(font-style: italic) {
  em, i, q {
    font-style: normal;
  }
}

C'est l'idée générale. Mais si vous ne le saviez pas, Miriam Suzanne, qui est rédactrice de The Spec, garde un ensemble continu et approfondi de notes personnelles sur les requêtes de style conteneur accessibles au public. Il a été mis à jour l'autre jour et j'ai passé un peu de temps là-bas à essayer de comprendre ma tête dans des aspects plus nuancés des requêtes de style. Ce sont des trucs non officiels, mais je pensais que je noterais certaines choses qui m'ont marqué. Qui sait? Peut-être que c'est des choses que nous pouvons éventuellement attendre avec impatience!

Chaque élément est un conteneur de style

Nous n'avons même pas besoin d'attribuer un type de conteneur ou de type conteneur pour définir un conteneur de style car tout est un conteneur de style par défaut.

Donc, vous voyez cet exemple ci-dessus qui supprime l'italique? Remarquez qu'il n'identifie pas un conteneur. Il saute à droite à la requête en utilisant la fonction style (). Alors, quel conteneur est interrogé? Ce sera le parent direct des éléments recevant les styles appliqués. Et sinon, c'est le prochain conteneur relatif le plus proche qui a priorité.

j'aime ça. Il est très CSS-y pour que la requête recherche un match, puis continuez à bouillonner jusqu'à ce qu'elle trouve une condition correspondante.

Il était difficile pour mon petit cerveau de comprendre pourquoi nous pouvons nous en sortir avec un conteneur implicite basé sur des styles, mais pas tellement lorsque nous avons affaire à des requêtes dimensionnelles, comme la taille et la taille d'une taille en ligne. Miriam l'explique bien:

Les requêtes dimensionnelles nécessitent CSS confinement sur la taille, la mise en page et le style du conteneur afin d'éviter les boucles de mise en page. Le confinement est une chose invasive à appliquer largement, il était donc important que les auteurs aient un contrôle minutieux sur les éléments (ou ne sont pas) des conteneurs de taille.

Les requêtes basées sur le style n'ont pas la même limitation. Il n'y a déjà aucun moyen dans CSS pour que les styles descendants aient un impact sur les styles calculés d'un ancêtre. Donc, aucun confinement n'est requis, et il n'y a pas d'effets secondaires invasifs ou inattendus pour établir un élément en tant que de style de style de style .

. (mien mettant l'accent)

Tout se résume aux conséquences - dont il n'y en a pas en ce qui concerne tout ce qui est un conteneur de requête de style dès la sortie de la boîte.

• Si un conteneur est trouvé: les conditions sont résolues contre ce conteneur.
• Si plusieurs conteneurs correspondent: le conteneur relatif le plus proche a la priorité.
• si aucune correspondance n'est trouvée: inconnu renvoyé.

C'est le même esprit «indulgent» que le reste de CSS.

Un conteneur peut prendre en charge les requêtes dimensionnelles et de style

Disons que nous voulons définir une requête de style sans nom de conteneur explicite:

@container <name>? <conditions> {
  /* conditional styles */
}

Cela fonctionne car tous les éléments sont des conteneurs de style , peu importe le type de conteneur. C’est ce qui nous permet de demander implicitement les styles et de compter sur le match le plus proche. Et c'est totalement bien car, encore une fois, il n'y a pas d'effets secondaires indésirables lors de l'établissement de conteneurs de style.

Nous devons utiliser un type de conteneur explicite pour les requêtes dimensionnelles, mais pas tant pour les requêtes de style car chaque élément est une requête de style. Cela signifie également que ce conteneur est à la fois une requête dimensionnelle de style et :

em, i, q {
  font-style: italic; /* default UA behavior */
}

/* When the container's font-style is italic, remove italics from these elements. */
@container style(font-style: italic) {
  em, i, q {
    font-style: normal;
  }
}

excluant un conteneur d'être interrogé

Peut-être que nous ne voulons pas qu'un conteneur participe au processus de correspondance. C'est là qu'il pourrait être possible de définir le type de conteneur: aucun sur un élément.

@container style(font-style: italic) {
  em {
    font-style: normal;
  }
}

Les conteneurs de requête de style explicites offrent plus de contrôle de ce qui est interrogé

Si, disons, nous devions écrire une requête de style pour le rembourrage, il n'y a pas de moyen fiable de déterminer le meilleur conteneur correspondant, que nous travaillions avec un conteneur explicitement nommé ou le parent direct le plus proche. C'est parce que le rembourrage n'est pas une propriété héritée.

Ainsi, dans ces cas, nous devons utiliser le nom de conteneur pour informer explicablement le navigateur de quels conteneurs qu'ils peuvent tirer. Nous pouvons même donner un conteneur plusieurs noms explicites pour qu'il corresponde à plus de conditions:

.card-container {
  container: card / inline-size; /* implictly a style query container as well */
}

Oh, et le nom de conteneur accepte n'importe quel nombre de noms facultatifs et réutilisables pour un conteneur! C'est encore plus de flexibilité lorsqu'il s'agit d'aider le navigateur à faire un choix lors de la recherche de matchs.

.some-element {
  container-type: none;
}

Je me demande en quelque sorte si cela pourrait également être considéré comme un «replacement» dans le cas où un conteneur est passé.

Les requêtes de style peuvent être combinées

Les opérateurs OR et et nous permettent de combiner Wueries pour garder les choses au sec:

@container <name>? <conditions> {
  /* conditional styles */
}

Styles de basculement

Il y a un peu de chevauchement entre les requêtes de style conteneur et les travaux effectués pour définir une fonction toggle (). Par exemple, nous pouvons parcourir deux valeurs de style de police, par exemple en italique et normal:

em, i, q {
  font-style: italic; /* default UA behavior */
}

/* When the container's font-style is italic, remove italics from these elements. */
@container style(font-style: italic) {
  em, i, q {
    font-style: normal;
  }
}

cool. Mais la proposition de basculement CSS suggère que la fonction toggle () serait une approche plus simple:

@container style(font-style: italic) {
  em {
    font-style: normal;
  }
}

Mais tout ce qui est au-delà de ce type de cas d'utilisation binaire est l'endroit où toggle () est moins approprié. Les requêtes de style, cependant, sont bonnes à partir. Miriam identifie trois cas où les requêtes de style sont plus appropriées qu'une togche ():

.card-container {
  container: card / inline-size; /* implictly a style query container as well */
}

Les requêtes de style résolvent le «Hack Toggle Hack»

Remarquez que les requêtes de style sont une solution formelle pour le «Toggle Toggle de la propriété CSS». Là-bas, nous définissons une propriété personnalisée vide (--Foo :;) et utilisons la méthode de secours séparée par les virgules pour «basculer» les propriétés activées et désactivées lorsque la propriété personnalisée est définie sur une valeur réelle.

.some-element {
  container-type: none;
}

C'est super cool, aussi beaucoup de travail que les requêtes de conteneur de style rend trivial.

Les requêtes de style et le contenu généré CSS

Pour le contenu généré produit par la propriété de contenu de :: avant et :: après des pseudo-éléments, le conteneur correspondant est l'élément sur lequel le contenu est généré.

.card {
  container-name: card layout theme;
}

requêtes de style et composants Web

Nous pouvons définir un composant Web comme un conteneur et l'interroger par style. Tout d'abord, nous avons le modèle & lt; du composant:

.theme {
  container-name: theme;
}
.grid {
  container-name: layout;
}
.card {
  container-name: card layout theme;
}

Ensuite, nous utilisons le: pseudo-élément hôte comme conteneur pour définir un nom de conteneur, un type de conteneur et quelques attributs de haut niveau:

@container bubble style(--arrow-position: start start) or style(--arrow-position: end start) {
  .bubble::after {
    border-block-end-color: inherit;
    inset-block-end: 100%;
  }
}

/* is the same as... */
@container bubble style(--arrow-position: start start) {
  /* etc. */
}
@container bubble style(--arrow-position: end start) {
  /* etc. */
}

Éléments à l'intérieur du & lt; Media-Host & gt; peut interroger les paramètres de & lt; Media-Host & gt; élément:

em, i, q {
  font-style: italic;
}

@container style(font-style: italic) {
  em, i, q {
    font-style: normal;
  }
}

Quelle est la prochaine étape?

Encore une fois, tout ce que j'ai noté ici est basé sur les notes de Miriam, et ces notes ne remplacent pas les spécifications officielles. Mais ils sont une indication de ce qui est discuté et où les choses pourraient atterrir à l'avenir. J'apprécie que Miriam ait lié une poignée de discussions exceptionnelles qui se déroulent que nous pouvons suivre pour rester au top des choses:

• Propriétés personnalisées de niveau supérieur qui contrôlent plusieurs déclarations # 5624
• Les requêtes de style () devraient-elles autoriser! Flag important? # 7413
• Déplacer les requêtes de style des propriétés standard au niveau 4 # 7185
• Ajouter la capacité de tester les préludes en règle # 6966

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!