nicht angemeldet
Rolf BHallo nix,
Die Abfrage würde sich auch auf alle anderen Container, die da noch irgendwo herumlingern, beziehen.
Ja.
Und sich dann in die Gestaltung von nav einmischen.
Eher nicht.
Je Element im DOM wird geschaut, welche CSS Regeln darauf zutreffen könnten. Die nav.main ul Regel im Wiki-Beispiel betrifft ein ul Element, das nav-Element mit Klasse main als Elternelement hat.
Die @container-Regel fügt dieser Regel eine bedingte Gültigkeit hinzu. Hierfür wird geschaut, was in der @container-Regel abgefragt wird, und es wird dasjenige Elternelement gesucht, das die Abfrage aller Teile dieser Bedingung ermöglicht. Die Spec ist ziemlich vertrackt, was aber auch daran liegt, dass dort auch style-Container berücksichtigt werden.
Für eine Größenabfrage braucht man ein Containerelement, das einen passenden containment-type anbietet. Auf die Idee, dass es mehrere davon geben könnte (also geschachtelte Size-Container), ist von den Spec-Autoren aber entweder keiner gekommen, oder die Lösung war ihnen so klar, dass sie es nicht der Erwähnung für wert hielten. Der
letzte im Quelltext erwähnte Container
gewinnt jedenfalls nicht, denn relevant für die Suche nach dem passenden Container sind nur die Elternelemente eines Elements. Und die logische Vorgehensweise ist: Es gewinnt der innerste passende Container, also für jedes Element einzeln ausgehend vom jeweiligen Element der erste in der Elternkette - alles andere ergibt keinen Sinn. Eine definitive Quelle dafür finde ich aber tatsächlich nicht. @Gunnar Bittersmann, steht das irgendwo aufgeschrieben?!
Im @container-Artikel ergibt sich damit, dass das nav Element als Size-Container für das ul Element dient. Der Browser stellt also eine Beziehung zwischen diesem Size-Container und allen Elementen her, deren Styling von der Größe dieses Size-Containers abhängt (hier nur das ul Element) und prüft bei Größenänderungen des Size-Containers, ob die abhängigen Style-Regeln aktiviert oder deaktiviert werden müssen.
Eine Namensangabe für die @container Regel kann aber auch kontraproduktiv sein. Wenn ich Elemente habe, die von einem Container abhängig sein sollen, dann kann es ja durchaus sein, dass ich zwei solche Elemente in zwei unterschiedlichen Containern habe. Und diese unterschiedlichen Container können unterschiedlich breit sein.
@container (min-width: 25em) {
nav ul {
display: flex;
}
}
Wenn ich jetzt auf meiner Seite sowas habe:
- ein 100% breites <header>-Element mit containment-type: inline-size, darin ein nav Element mit ul darin
- ein 15em breites <nav>-Element mit containment-type: inline-size am linken Rand, darin eine ul
- ein <div>-Element mit containment-type: inline-size als Kind von <main>, im <div> ein <nav> mit <ul> darin. <main> ist ein Grid.
Nehmen wir noch an, das <body> Element wäre 60em breit. Der Header wäre es dann auch, und das ul-Element darin würde demnach geflext.
Das <nav> Element am linken Rand ist 15em breit, es ist der size-Container für das ul darin und demnach wird diese Liste nicht geflext.
Das div im main-Element ist je nach Grid-Layout 25em breit oder nicht. Solange es schmaler ist, bleibt die Liste ungeflext. Ziehe ich mein Fenster breit, kann der Schwellwert erreicht werden (je nach Gesamtlayout) und die Liste schaltet um. Hat das div einen "Maximize" Button, durch den es die gesamte <main>-Fläche einnehmen kann, kann das ebenfalls zum Umschalten ins Flexlayout führen.
Und das alles mit nur einer Regel. Auf komplexen Seiten wird das Benennen von Containern wichtig, damit sich die Komponenten nicht in die Quere kommen. Aber zwingend ist das nicht.
Rolf
sumpsi - posui - obstruxi
Gunnar Bittersmann
Matthias Scharwies