nicht angemeldet
Matthias Scharwies
Gunnar Bittersmann
Rolf B
Rolf B
Rolf B
Gunnar Bittersmann
Rolf B
Gunnar Bittersmann
Rolf B
Container-Maße und „artverwandte“ Dinge – wozu sind die denn wirklich zu gebrauchen?
Für die Querries? Ich sehe da nur eine alternative Schreibweise für Prozent-Angaben. Die bekommt man auch mit calc in den Griff. (Sind, wenn man sie denn tatächlich benötigen sollte, obendrein sehr wahrscheinlich auch ohne Grid und Flex nutzbar.) Und sonst?
Nehmen wir mal ein Grid. Mitten drin sitzt ein Item. Und das hat, ob nun mit cq? oder ohne, keine Ahnung davon, wie groß es ist. Da hilft dann auch kein Container-Querry. Denn auch das, so ein Konstrukt, „sieht“ da nur die Größe des Containers. Also im gewählten Beispiel die Größe des Grid. Des gesamten Grid. Und nicht ansatzweise die Ausmaße der Tracks. Bleibt also weiterhin entweder das Überlaufen (mit Überlagerung benachbarter Items) oder das Beschneiden und damit Verbergen dessen, was es selber darstellen sollte. Um aus dieser Situation zu entkommen bleibt dem Designer also nur, das „gute alte Pixel-Layout“ durch ein Fractions-Layout zu ersetzen. Und wenn ich sowieso alles „zu Fuß“ zusammentragen „darf“, wieso dann noch auf das setzen, was in den Browsern offensichtlich (s. u.) noch längst nicht ausgereift zusammengeschraubt ist?
Offensichtlich? Nun, mein Gebastel sah letztens, noch mit Safari 16, fast(!) gut aus. Firefox hatte dazu aber an einigen Stellen eine ganz andere Meinung. Da wird, um nur eine der Differenzen zu erwähnen, der Aufbau der (vermuteten) Layer (die anscheinend für die einzelnen nebeneinander liegenden Grid- und Flex-Boxen intern angewendet werden) in einer anderen Reihenfolge vorgenommen. Folge: was in einem Browser mit z-index zu einer sauberen Darstellung führt (Überlagerung von Nachbarelementen bei z. B. Zoom-Effekten mittels scale), versteckt beim anderen das „hervorgehobene“ hinter vermeintlich weiter hinten liegenden Elementen …
Dann kam Safari 17. Und beim ersten Öffnen einer „gerade eben noch“ scheinbar sauber gestalteten Anhäufung von HTML „mit mehreren Grid und Flex drin“: große Baustelle! Vor allem waren plötzlich die gerade noch „gut“ dargestellten Grid-Items „weg“. Der Inspektor meinte, die hätten ja nur 0⨯0 (CSS-)Pixel vorzuweisen …
Also jetzt wieder alles umbauen? V.a. das zentrale Grid durch ein Flex ersetzen, dessen Elemente wiederum aus Flex bestehen, so daß wenigstens eine Dimension vielleicht „greifbar“, verläßlich planbar, wird? Und damit den einzigen noch erkennbaren Vorteil, die „Schachbrett-Anordnung“ (so sie sich nicht hinter überlaufenden Items verkriecht), auch noch verlieren? Danke!
Für ein einzelnes tatsächlich nutzbares Grid lohnt sich IMHO der (Lern-)Aufwand rund um diese „modernen Layout-Features“ nicht.
Servus!
Container-Maße und „artverwandte“ Dinge – wozu sind die denn wirklich zu gebrauchen?
Für die Querries?
Ja, für die Container Queries!
Nehmen wir mal ein Grid. Mitten drin sitzt ein Item. Und das hat, ob nun mit cq? oder ohne, keine Ahnung davon, wie groß es ist.
Wir haben schon mehrfach geschrieben, dass Container-Einheiten nur innerhalb eines Containers sinnvoll sind. Innerhalb eines Grid solltest du eben keine absoluten Positionierungen, Containerwerte oder ähnliches bunt durcheinander mischen.
@Gunnar Bittersmann hatte vor einigen Wochen das CSS-Café verlinkt, mit dem Thema „Don't over-engineer your CSS!“ - Das sind bis jetzt nur Slides auf Englisch - meiner Meinung nach aber trotzdem nützlich!
Herzliche Grüße
Matthias Scharwies
Was zumindest mein Beispiel angeht: da „will“ ich doch nur, daß so ein da mittendrin abgelegtes Item (vlt. die allseits bekannte Card?) auf Veränderungen der Größe entsprechend reagiert. So, wie das in den allseits vorzufindenden Beispielen ja auch gezeigt wird. Nur: das geht ja eben nicht!
Denn: die Ausmaße des Containers, des „Containers mit Card drin“, haben ja nur bedingt mit denen zu tun, welche dem Kärtchen eigentlich zugestanden würden. Die bekommt es schlicht nicht zu sehen und stellt sich deshalb abseits von Viewport-Größen, für welche es direkt zusammengechraubt wurde, immer quer.
Ja wenn wenigstens etwas wie max-size = [super size] (wenn anstelle der übergeordneten Klasse das Eltern-Objekt einträte) möglich wäre …
Bleibt, jedenfalls für mich und unter dem Strich: „ein Schachbrett, auf dem ein Stapel Bierdeckel viele Felder überdeckt und auf dem sich Figuren gelegentlich so aufblasen, daß das Brett unter dem kleinen Zeh verschwindet …“
@@nix
Container-Maße […] Ich sehe da nur eine alternative Schreibweise für Prozent-Angaben.
cqw u.dgl. sind Prozent-Angaben. Nur dass sie sich auf einen anderen Grundwert beziehen als vw u.dgl. bzw. %.
Scott Kellum zeigte in seinem (grandiosen) Talk Mapping Typography ein Beispiel, wo sich die Schriftgröße der Überschrift nach der Größe des Containers richtet.
Für ein einzelnes tatsächlich nutzbares Grid lohnt sich IMHO der (Lern-)Aufwand rund um diese „modernen Layout-Features“ nicht.
Wenn du 08/15-Websites bauen willst, die so aussehen wie jede andere Website vor 5 Jahren, dann kommst du ohne modernes CSS aus.
🖖 Живіть довго і процвітайте
Danke, aber das „mit den Prozenten“ ist ja nicht das Problem. Wären es „richtige Maße“, ob mit oder ohne Dezimalstellen (die ja so und so überall drin stecken müssen), wären, es würde sich nichts ändern: Das enspringt dem Umstand, daß deren Bezug am gesamten ElternVorfahren-Container hängt. Die dem Item eigentlich zustehenden Größen, die Dimensionen der beiden Tracks, in die es eingebettet wird, sind unsichtbar. Und damit kann das Item natürlich auch nicht auf genau diese reagieren, sich passend aufblasen oder klein machen.
Und wegen dem „Fuchsberger drin“: den erwähnten „bis vor 17“ Zustand bekomme ich mittels calc (und dann ziemlich wahrscheinlich auch @container) allemal hin. Sogar der Aufwand des Umbauens sollte sich, dank BBedit, in Grenzen halten. Und was mir gerade noch einfällt: ich verliere zwar das doch eher fragile „Schachbrett“, kann „mit eigener Hände Arbeit“ aber womöglich mehr als nur ein einfaches „Mauerwerk“, ja vielleicht sogar „Inka-Gemäuer“ aufrichten. Ganz ohne (nicht mehr ganz so) neues Schlüsselwort (das in Safari jetzt auch, aber nur, auftaucht). Wenn schon, denn schon?
Hallo nix,
das Thema hatten wir neulich bei dieser 3×5 Bildergalerie. Der TO wollte die Breite der Bilder als 1/N der Fensterbreite bestimmen, die Höhe der Bilder als 2/3 ihrer Breite und die Höhe der Galerie aus Bildhöhe und Anzahl Bildzeilen.
Denn nur, wenn die Größe der Galerie festgelegt ist, funktioniert die Methode, durch Vergrößern eines Bildes die zugehörige Gridzeile und -s palte expandieren zu lassen.
Das ließ sich mit einer Breitenberechnung durch "100%" nicht lösen, weil % in der Richtung ermittelt werden, in der sie benutzt werden (also wenn ich im custom property --breite irgendwas mit calc(100% + bla - blub) stehen habe und --breite dann in der Höhenberechnung einsetze, beziehen sich die 100% auf einmal nicht mehr auf die Breite, sondern auf die Höhe, und alles geht kaputt).
Man hätte 100vw verwenden können statt 100%, aber das hatte Nachteile.
Deshalb habe ich den Body zum inline-size Container gemacht (oder man macht es mit dem Element, das die Galerie enthält) und berechne die Bildbreite über cqw. Damit kann ich dann auch die Höhe berechnen, ohne dass mir die Maßeinheit kaputtgeht.
Ohne Container-Units hätte ich ansonsten wohl JavaScript gebraucht. Zumindest habe ich es anders nicht hinbekommen…
Für ein einzelnes tatsächlich nutzbares Grid lohnt sich IMHO der (Lern-)Aufwand rund um diese „modernen Layout-Features“ nicht.
Wie oft noch? Wenn Du uns nicht zeigst, was Du machst, kann Dir keiner sagen, ob Du eine Dusseligkeit eingebaut hast oder das Feature dusselig ist. Code Inspection ist das Mittel, mehr über seine eigenen Fehler zu lernen. Weiß ich genau. Ist mir oft genug passiert.
Rolf
Ein Beispiel, schon wieder einmal? Ich denke, die Sache ist doch eigentlich klar? Wenn man mal die diversen „anderen Nettigkeiten“ wie die erwähnten Meinungsverschiedenheiten der Browser weg läßt: es geht um (mindestens) ein Grid, das Items enthält, die wie diese Cards auf Änderungen des Platzangebots reagieren sollen. Wobei der Platz durch die Tracks, welche seinen Platz bestimmen, vorgegeben würde.\
<style>
.container {
display: grid;
container: Master / size;
grid-template: "hdr hdr hdr" 1fr "art pic inf" 8fr "art ftr ftr" 1fr / 1fr 8fr 1fr;
…
}
.card {
display: grid;
/* contain: paint; ??? */
grid-template-columns: minmax(0,1fr) 3fr clamp(min-content, 60%, max-content);
…
}
/* Sinnbefreit:
@container Master (inline-size > 250px) { .card { … } }
wie schön könnte es sein?
@container Master's Track (inline-size … ) { … }
*/
</style>
…
<div class="container">
<div class="card">
<p>Mal bin ich (zu) klein, mal bin ich (zu) groß, mal patz’ ich aus allen Nähten …</p>
</div>
…
</div>
Da solche Items aber nicht erfahren, erfahren können, wie viel Platz ihnen zur Verfügung stehen sollte (1cq? bezieht sich ja auf .container „in toto“), ist für die auch jedes @container sinnfrei.
Hallo nix,
das Beispiel ist schwierig nachvollziehbar, weil dein HTML nur ein <p> enthält, das Grid darin aber 3 Spalten definiert.
Deine Definition des .card Grid ist allerdings fehlerhaft, weil clamp nicht in grid-template-columns erlaubt ist. Guck in die Doku, bzw. in die ausgelagerte Beschreibung zur track-list. Die Regeln für Trackgrößen sind sehr strikt. Dein Browser dürfte Dir in den Entwicklertools ebenfalls mitteilen, dass diese Eigenschaft einen ungültigen Wert hat.
Wenn Du möchtest, dass sich der Inhalt eines div.card nach der Größe der Card richtet, musst Du das .card-Element zum Container machen. Dann kannst Du Container-Queries dafür definieren, so dass der Inhalt der Card der Card-Größe (sprich: der Trackbreite) folgt. Und in den Regeln, die den Card-Inhalt layouten, kannst Du mit cqw/cqh arbeiten.
Im Haupt-Grid musst Du lediglich sicherstellen, dass sich die Tracks über die gesamte Breite des Grid ausdehnen. Das ist mit justify-content:stretch aber bereits der Default.
Das Grid selbst (also deinen Master) zum Container zu machen, ist nur nötig, wenn Du tatsächlich die Größe des Containers verwenden musst. Aber musst Du das? Geschachtelte Container führen auch zu dem Problem, dass der Browser die cq-Einheiten auf das nächstgelegene Elternelement bezieht, das Container Size Queries akzeptiert, und nicht auf den Container, in dessen @container Query sie stehen. D.h. das Card-Innere kann sich ohnehin nicht auf cq-Einheiten des Master-Grid beziehen. Und es ist auch nicht nötig, weil das Master-Grid seine Grid-Items ja basierend auf dem Layout kontrolliert und Du darum im Card-Grid auf das Master-Grid keinen Bezug nehmen solltest.
Aber das ist etwas, worüber Matthias sich aufgeregt hat: Regeln für das Container-Element selbst kann man durch Container-Queries nicht definieren, d.h. man muss nötigenfalls ein Extra-Div drumherumlegen, das selbst keine größenabhängigen Styles braucht und die Rolle des Containers übernimmt. Ob das bei Dir nötig ist, kann ich nicht sagen. Nötig wäre es beispielsweise dann, wenn das .card Element ein Grid ist und Du das Grid-Template je nach Größe umbauen möchtest. Dann geht das nur so:
<div class="card">
<div>
<!-- inhalt -->
</div>
</div>
.card {
container: Card / inline-size;
}
.card > div {
display:grid;
grid: /* schmales Layout */;
}
@container Card (width > 20em) {
.card > div {
display:grid;
grid-template-columns: minmax(5em, 30cqw) 1fr;
}
}
Du hast versucht, die contain-Eigenschaft für das .card-Element zu verwenden. Diese Eigenschaft bewirkt containment, erzeugt aber keinen Query-Container für Größenabfragen. Was wolltest Du da bezwecken?
Rolf
Der Knackpunkt ist doch „kannst Du mit cqw/cqh arbeiten“. Aber die beziehen sich auf die Größe des gesamten Cntainers (hier eben: das grid). Und damit wird das Ergebnis eben „mal zu groß, mal zu klein“:
.container {
display: grid;
grid-template-columns: repeat(auto-fill, …);
…
}
ist nicht mal nötig. Schon das „gewöhnliche fr“ liefert ja keinen Wert, den man „in die Hand nehmen kann“. Einziger „Ausweg“: man nagelt alles fest:
:root { --FIX: 200px; }
.container {
display: grid;
grid-template-columns: repeat(4, var(--FIX));
…
.item {
max-inline-size: var(--FIX);
…
}
Aber wieso sollte man da dann noch grid verwenden? Und wenigstens in so einer „Lösung“: wofür @container?
Hallo nix,
wie ich schon sagte: für das Layouten des Grid-Items sollte das Item der Container sein, nicht das Grid.
Dass die cq Einheiten und die @container Query bei dir nicht tun, was du erwartest, dürfte im Wesentlichen daran liegen, dass du das Grid zum Container gemacht hast.
Rolf
Sprich: Grid und Flex sind ungeeignet, um das Design der Seite zu gestalten. Also: weg damit.
Hallo nix,
Gunnar schrieb – unter anderem, was ich für löschwürdig hielt – dies:
Grid und Flex sind dafür hervorragend geeignet.
Du müsstest es nur richtig verwenden. Weshalb meinst Du, dass unbedingt das Gesamt-Grid der Container sein muss? Daraus entstehen doch deine Probleme. Warum kannst Du nicht die Grid-Items zum Container machen?
Rolf
@@Rolf B
Gunnar schrieb – unter anderem, was ich für löschwürdig hielt
Wer hier permanent austeilt, der muss auch einstecken können.
🖖 Живіть довго і процвітайте
PS: Nein, ich bestehe nicht darauf, dass mein Posting wiederhergestellt wird.
Warum kannst Du nicht die Grid-Items zum Container machen?
Und woher weiß so ein Container-Item dann, wie groß es ist? Bzw. sein darf. Denn wenn die Items die Größe bestimmen, und zwar unkontrolliert, verlangen sie vom Grid, daß es, geschätzt anhand dessen, was aktuell an Inhalten vorhanden ist, daß der Browser doch bitte ein Fenster mit 1200vw⨯1600vh anbieten soll. Denn: die Card-Items haben absolut keinen Grund, sich klein zu machen.
Also mal davon abgesehen, daß diese Items wegen ihrer Inhalte, um die zu gestalten, ja eigentlich schon über @container Card fürs Anpassen vorgesehen … waren.
Hallo nix,
Und woher weiß so ein Container-Item dann, wie groß es ist?
Das Grid bekommt eine feste Breite, z.B. 100%, und steuert das. Ggf. braucht der Body das auch.
Rolf
„Mein“ Grid hat längst eie feste Breite. Das Ergebnis soll seine Inhalte ja möglichst umfangreich, flächendeckend, darstellen. Und die Items sollten sich, wenn es „eng wird“, eben klein machen.
Aber, spätestens mit den da eingebundenen Bildern, haben diese ohne „äußeren Zwang“ keine Scheu davor, sich nicht an Grenzen zu halten. — Tja, ein (nur sinngemäß so dargestellt:) <img max-inline-size=90cqi …> …