Tiefer in Anfragen im Containerstil graben

Ich habe vor einiger Zeit einige frühe Gedanken über Abfragen im Containerstil geschrieben. Es sind noch frühe Tage. Sie sind bereits in der Spezifikation der CSS Containment Modul Level 3 definiert (derzeit im Entwurfsstatus des Editors), aber es finden noch einige ausstehende Diskussionen statt.

Die grundlegende Idee ist, dass wir einen Container definieren und anschließend Stile auf seine Nachkommen anwenden können, basierend auf seinem berechneten Styling.

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

Das beste Beispiel, das ich bisher gesehen habe, ist die Entfernung von Kursivschrift aus so etwas wie & lt; em & gt;, & lt; i & gt; und & lt; Q & gt; Wenn sie in einem Kontext verwendet werden, in dem der Inhalt bereits kursiv ist:

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;
  }
}

Das ist die allgemeine Idee. Wenn Sie es jedoch nicht wussten, führt Miriam Suzanne, die Redakteurin der Spezifikation ist, eine laufende und gründliche Reihe persönlicher Notizen zu Anfragen im Containerstil, die öffentlich verfügbar sind. Es wurde neulich aktualisiert und ich habe einige Zeit damit verbracht, meinen Kopf um nuanciertere Aspekte von Stilfragen zu wickeln. Es ist inoffizielles Zeug, aber ich dachte, ich würde einige Dinge aufschreiben, die mir aufgefallen sind. Wer weiß? Vielleicht ist es Sachen, auf das wir uns irgendwann freuen können!

Jedes Element ist ein Stilbehälter

Wir müssen nicht einmal einen Container-Namen oder einen Container-Typ zuweisen, um einen Stilbehälter zu definieren, da alles standardmäßig ein Stilbehälter ist.

Sie sehen dieses Beispiel oben, das Kursivschrift beseitigt? Beachten Sie, dass es keinen Container identifiziert. Es springt mit der Funktion style () direkt zur Abfrage. Welcher Behälter wird also befragt? Es wird der direkte Elternteil der Elemente die angewandten Stile empfangen. Und wenn nicht, dann ist es der nächstgelegene relative Container , der Vorrang hat.

Ich mag das. Es ist sehr CSS-y, dass die Abfrage nach einer Übereinstimmung sucht und dann weiter sprudelt, bis sie einen passenden Zustand findet.

Es war schwer für mein kleines Gehirn zu verstehen, warum wir mit einem impliziten Behälter, der auf Stilen basiert, durchkommen können, aber nicht so sehr, wenn wir uns mit dimensionalen Abfragen wie Größe und Inline-Größe befassen. Miriam erklärt es schön:

dimensionale Abfragen erfordern CSS Containment für die Größe, das Layout und den Stil des Containers, um Layout -Schleifen zu verhindern. Containment ist eine invasive Sache, die sich allgemein anwenden kann. Daher war es wichtig, dass Autoren eine sorgfältige Kontrolle darüber haben, welche Elemente (oder nicht) Größenbehälter sind.

stilbasierte Abfragen haben nicht die gleiche Einschränkung. In CSS gibt es bereits keine Möglichkeit, dass Nachkommensstile sich auf die berechneten Stile eines Vorfahren auswirken. (Hervorhebung meiner)

Es kommt alles auf Konsequenzen an, von denen es keine gibt, soweit es einen Stil für einen Style -Abfrage -Container direkt außerhalb der Box ist.

Wenn ein Behälter gefunden wird: Die Bedingungen werden gegen diesen Container aufgelöst.

Wenn mehrere Container übereinstimmen: Der nächste relative Container hat Vorrang.

• Wenn keine Übereinstimmungen gefunden werden: Unbekannt zurückgegeben.
Das ist der gleiche "vergebende" Geist wie der Rest von CSS.
Ein Container kann sowohl dimensionale als auch stile Abfragen

unterstützen

Nehmen wir an, wir möchten eine Stilabfrage ohne einen expliziten Containernamen:

Dies funktioniert, da

alle Elemente Stilcontainer

sind, unabhängig vom Container-Typ. Das ermöglicht es uns, implizit Stile abzufragen und uns auf das nächste Spiel zu verlassen. Und das ist völlig in Ordnung, da es bei der Festlegung von Stilbehältern wieder keine negativen Nebenwirkungen gibt.

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

Wir müssen einen expliziten Container-Typ für dimensionale Abfragen verwenden, aber nicht so sehr für Stilanfragen, da jedes Element eine Stilabfrage ist. Das bedeutet auch, dass dieser Container sowohl ein Stil als auch dimensionale Abfrage ist:

ohne einen Container von der Ausfragung ausschließen

Vielleicht möchten wir nicht, dass ein Container am Matching -Prozess teilnimmt. Hier kann es möglich sein, den Container-Typ zu setzen: keine in einem Element.

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;
  }
}

Explizite Style -Abfragebehälter bieten mehr Kontrolle darüber, was abfragt wird

Wenn wir beispielsweise eine Style -Abfrage für die Polsterung schreiben sollten, gibt es keine zuverlässige Möglichkeit, den besten passenden Container zu bestimmen, unabhängig davon, ob wir mit einem explizit benannten Container oder dem nächsten direkten Elternteil arbeiten. Das liegt daran, dass Polsterung kein ererbtes Eigentum ist.

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

In diesen Fällen sollten wir also den Container-Namen verwenden, um den Browser, aus dem sie anziehen können, explizit zu informieren. Wir können sogar einem Container mehrere explizite Namen geben, damit er mehr Bedingungen entspricht:

oh, und Containername akzeptiert eine beliebige Anzahl von optionalen und

wiederverwendbaren

-Namen für einen Container! Dies ist noch mehr Flexibilität, wenn es darum geht, dem Browser bei der Suche nach Übereinstimmungen eine Wahl zu treffen.

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

Ich frage mich, ob dies auch als „Fallback“ angesehen werden könnte, falls ein Container übergeben wird.

Stilanfragen können kombiniert werden

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

Die OR und und und die Bediener ermöglichen es uns, Wuerien zu kombinieren, um die Dinge trocken zu halten:

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

Styles

Es gibt eine kleine Überlappung zwischen Abfragen im Containerstil und Arbeiten, um eine Toggle () -Funktion zu definieren. Zum Beispiel können wir zwei Werte im Schriftart im Schriftart durchlaufen, beispielsweise kursiv und 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. Der Vorschlag für CSS -Umschaltungen legt jedoch nahe, dass die Funktion Toggle () ein einfacherer Ansatz wäre:

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

Aber alles, was über diese Art von binärem Anwendungsfall hinausgeht, ist, wo Toggle () weniger geeignet ist. Stilfragen sind jedoch gut zu gehen. Miriam identifiziert drei Fälle, in denen Stilfragen besser geeignet sind als ein Toggle ():

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

Stilfragen Lösen Sie den "benutzerdefinierten Eigenschaft Toggle Hack"

Beachten Sie, dass Style -Abfragen eine formale Lösung für den „CSS Custom Property Toggle Trick“ sind. Dort setzen wir eine leere benutzerdefinierte Eigenschaft (--foo:;) und verwenden die von Comma getrennte Fallback-Methode, um die Eigenschaften ein- und auszuschalten, wenn die benutzerdefinierte Eigenschaft auf einen realen Wert eingestellt ist.

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

Das ist super cool, auch viele Arbeiten, die Style -Container -Abfragen trivial machen.

Stilabfragen und CSS erzeugt Inhalt

Für generierte Inhalte, die durch die Inhaltseigenschaft von :: vor und: nach pseudo-Elementen erstellt wurden, ist der passende Container das Element, auf dem der Inhalt generiert wird.

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

Stilabfragen und Webkomponenten

Wir können eine Webkomponente als Container definieren und nach Stil abfragen. Erstens haben wir die Vorlage & gt; der Komponente:

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

Dann verwenden wir die: Host-Pseudo-Element als Container, um einen Containernamen, einen Container-Typ und einige auf hohen Attributen darauf zu setzen:

@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. */
}

Elemente innerhalb des & lt; Media-Host & gt; kann die Parameter des & lt; Media-Host & gt; Element:

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

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

Was kommt als nächstes?

Auch hier basiert alles, was ich hier unten aufgeschrieben habe, auf Miriams Notizen, und diese Notizen sind kein Ersatz für die offizielle Spezifikation. Aber sie sind ein Hinweis darauf, was diskutiert wird und wo die Dinge in Zukunft landen könnten. Ich schätze Miriam, die noch eine Handvoll herausragender Diskussionen in Verbindung gebracht hat, die wir folgen können, um auf dem neuesten Stand zu bleiben:

• Benutzerdefinierte Eigenschaften mit höherer Ebene, die mehrere Deklarationen kontrollieren#5624
• Sollte Style () -Anfragen! Wichtige Flagge zulassen? #7413
• Abfragen stilvoller Stile von Standardeigenschaften auf Stufe 4#7185
• Fügen Sie die Fähigkeit zum Testen für die Vorläufe von AT-RUE#6966
hinzu

Das obige ist der detaillierte Inhalt vonTiefer in Anfragen im Containerstil graben. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!