nicht angemeldet
Frage zum Wiki-Artikel „@container“
0 
Gunnar Bittersmann
0
0 
Rolf B
Frage zum Wiki-Artikel „@container“
Matthias ScharwiesWieso soll sich die im Beispiel gezeigte die @container-Abfrage nur auf das nav beziehen?
Antwort: weil in dem, was gezeigt wird, nur nav.main einen Container mit sich bringt.
Jedoch: schon die Ellipsen zeigen, daß das Beispiel gekürzt ist! Nach ein paar Minuten Nachdenken (die Quellen, auf die verwiesen wird, sind da auch nicht wesentlich anders zu verstehen) komme ich zu folgender Auffassung: Die Abfrage würde sich auch auf alle anderen Container, die da noch irgendwo herumlingern, beziehen. — Und sich dann in die Gestaltung von nav einmischen.
Wenn ja, dann (vermute ich) hätte der letzte im Quelltext erwähnte Container (container-type: … oder container: … hängen dran) gewonnen und würde die Liste in nav.main zum Flex zwingen! Das könnte „interessant“ sein oder werden. Eine Priese Klarstellung könnte da doch nicht schaden?
-
@@nix
Wenn ja, dann (vermute ich) hätte der letzte im Quelltext erwähnte Container (
container-type: …odercontainer: …hängen dran) gewonnen und würde die Liste in nav.main zum Flex zwingen! Das könnte „interessant“ sein oder werden.„Vermute“, „hätte“, „könnte“ …
Eine Priese Klarstellung könnte da doch nicht schaden?
Ja, deinerseits. Bitte erstelle ein Gegenbeispiel, welches das im Wiki Geschriebene widerlegt.
🖖 Живіть довго і процвітайте
--
Ad astra per aspera-
Wie soll ich die Frage, die Unklarheit, von der ich geschrieben habe, widerlegen?
Aber:
<html> <header> <style> p { background: yellow; max-width: 40em; } .chef { container-type: inline-size; font-size: 1.75em; } .stpd { color: lightgreen; } @container (width > 1em) { span { padding-inline: 1cm; border: 10px solid blue; } } .accident { container-type: inline-size; background-color: red; } </style> </header> <body> <p class="chef">CHEF<span>chef</span> 1</p> <p>SOMEBODY<span>somebody</span> 2</p> <p class="stpd">ABC<span>abc</span>…</p> <p class="accident">ABC<span>abc</span>…</p> </body> </html>zeigt immerhin, daß alle Container-Kinder (aber auch nur diese) von dem betroffen sind, was innerhalb von
@containerverlost wird. Das kann unerwünscht sein (und, da die Effekte ja von Bedingungen abhängen, durchaus auch mal überraschend, länger unerkannt bleiben). Und der Browser wird, wenn es so wie im Beispiel gezeigt gemacht wird, alle Container daraufhin untersuchen, ob da nicht ein passendes nav drin steckt. Um dann nur dieses umzugestalten.Es wird ja auch (ggf.) schnell komplizierter. Wenn man z. B. bei den Styles noch ein
.y { container-type: size; … }und im HTML dann noch ein <div class="y"> wor drum herum einbaut …Mein Fazit: das Verhalten ist durchaus eingängig, aber die potentiellen Nebenwirkungen sind nicht unbedingt offensichtlich.
-
Moin,
Aber:
<html> <header> <style> p { background: yellow; max-width: 40em; } .chef { container-type: inline-size; font-size: 1.75em; } .stpd { color: lightgreen; } @container (width > 1em) { span { padding-inline: 1cm; border: 10px solid blue; } } .accident { container-type: inline-size; background-color: red; } </style> </header> <body> <p class="chef">CHEF<span>chef</span> 1</p> <p>SOMEBODY<span>somebody</span> 2</p> <p class="stpd">ABC<span>abc</span>…</p> <p class="accident">ABC<span>abc</span>…</p> </body> </html>… funktioniert auch nur, weil Browser
headeraußerhalb desbodyakzeptierenstyleinnerhalb desbodyinterpretieren
😉
Viele Grüße
Robert-
@@Robert B.
headeraußerhalb desbodyakzeptieren
Wobei das passiert:
-
Der Parser ist im
html-Wurzelelement und liest<header>– das Element darf nicht als Kind vonhtmlvorkommen, auch nicht inhead. Also macht der Parser dasbody-Element auf. -
Der Parser liest
<body>, ist aber schon imbodyundbodyinbodygibt’s nicht. Somit wird das Start-Tag ignoriert.
Im DOM ist dann
headerinbodygeschachtelt.styleinnerhalb desbodyinterpretieren
Wie jetzt, steht das immer noch nicht in der Spec, dass
styleauch inbobyerlaubt ist? Nachgeschaut: nein, immer noch nicht. Warum nicht?🖖 Живіть довго і процвітайте
--
Ad astra per aspera-
Moin Gunnar,
styleinnerhalb desbodyinterpretieren
Wie jetzt, steht das immer noch nicht in der Spec, dass
styleauch inbobyerlaubt ist? Nachgeschaut: nein, immer noch nicht. Warum nicht?diese Frage stellt sich erst recht angesichts von Inline-SVG mit eigenem
style.Viele Grüße
Robert-
@@Robert B.
Wie jetzt, steht das immer noch nicht in der Spec, dass
styleauch inbobyerlaubt ist? Nachgeschaut: nein, immer noch nicht. Warum nicht?diese Frage stellt sich erst recht angesichts von Inline-SVG mit eigenem
style.Nö. Das sollte schon durch die SVG-Spec abgedeckt sein.
Dass
circleim HTML-Dokument auftauchen kann, steht ja auch nicht in der HTML-Spec.🖖 Живіть довго і процвітайте
--
Ad astra per aspera-
Hallo Gunnar,
die Frage „Warum nicht“ stellt sich doch, weil es in SVG erlaubt, SVG in HTML erlaubt, aber nicht in der HTML-Spezifikation steht 😉
Viele Grüße
Robert
-
-
Weia! Kam das vom Auto-Complete? Oder vom „schnell was zusammenfrickeln“? Vielleicht beides.
-
-
-
Hallo 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 ulRegel 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-
Danke für die ausführliche Antwort! Für mich selber habe ich ja mittlerweile (s. o.) schon herausgefunden, in wie weit da Gefahren bestehen (könnten). Und mir ging es ja „hier“ auch mehr darum, auf mögliche unerwünschte „Nebenwirkungen“ hinzuweisen, die man IMHO mit einem kleinen Hinweis im Vorfeld abwürgen könnte.
BTW: fast neu herausgefunden habe ich einen Grund für manche meiner Probleme. Nämlich, daß diese Maßeinheiten „mit q drin“ (
cqw,cqbusw.)-
dieses „q“ nicht umsonst herumschleppen weil
-
sie nur „funktionieren“ (fast schon: existieren), wenn sie innerhalb eines Querry notiert werden. Wenn ich das geahnt hätte … Aber so wollte ich doch gleich „ganz modern anfangen“ und habe die an manchen Stellen „einfach so“ platziert. Also direkt im eigentlichen CSS und nicht in einer Abfrage. — So ein Container scheint also nur innerhalb der Querries zu existieren. Also „so richtig“ und nicht „als Geist“.
Gut, dann werd’ ich die nächste Zeit mein CSS halt neu aufbauen. Schon wieder einmal, wie Forrest meinte …
-
Servus!
…
BTW: fast neu herausgefunden habe ich einen Grund für manche meiner Probleme. Nämlich, daß diese Maßeinheiten „mit q drin“ (
cqw,cqbusw.)-
dieses „q“ nicht umsonst herumschleppen weil
-
sie nur „funktionieren“ (fast schon: existieren), wenn sie innerhalb eines Querry notiert werden. Wenn ich das geahnt hätte …
Ja, das haben wir des Öfteren im Forum geantwortet:
- 04.08. (vor einem Monat): SELF-Wiki: Container Queries-Tutorial - halbwegs fertig
- 05.08. HTML + CSS debuggen
- …
Leider hast Du oft - wsl. weil du nicht angemeldet bist und deshalb wohl kein „Ping“ bei neuen Antworten im Thread kriegst, oft einen neuen Thread aufgemacht, ohne auf unsere Antworten einzugehen.
Aber so wollte ich doch gleich „ganz modern anfangen“ und habe die an manchen Stellen „einfach so“ platziert. Also direkt im eigentlichen CSS und nicht in einer Abfrage. — So ein Container scheint also nur innerhalb der Querries zu existieren. Also „so richtig“ und nicht „als Geist“.
Und da bist du nicht der einzige Anfänger, der einfach mal alles wild durcheinanderwirft und sich dann fragt, wieso es denn nicht wie gewünscht läuft.
Gut, dann werd’ ich die nächste Zeit mein CSS halt neu aufbauen. Schon wieder einmal, wie Forrest meinte …
Oder erst mal ne Pause machen und sich in Ruhe Tutorials durchlesen!
Herzliche Grüße
Matthias Scharwies
--
Ich habe heute rausgefunden, dass in das Pizzafach meines Rucksacks auch ein Laptop passt!-
Nun, eigentlich bin ich, was „die Qs angeht“, nur nirgends darüber gestoplert, daß „Innerhalb eines Containers“ vor allem meint nur „innerhalb von z. B.
@container“. Und “Mr. Fallback” dazu dann meint, „wenn kein Container da (zu sehen) ist, dann wird cq gestrichen und dafür ein v eingesetzt“.
-
-