nicht angemeldet
Frage zum Wiki-Artikel „Flex-Container“
Rolf B
Gunnar Bittersmannflex-direction: colum ≣ flex-grow: 1; flex-shrink: 1;
Frage: wenn die Blockrichtung diejenige der Breitenausdehnungen ist: dito? Und: display: inline-flex?
-
Hi nix, die Antwort ist ganz einfach: du erlaubst damit dass das selektierte Element sowohl wachsen darf als auch schrumpfen darf.
-
Hallo Hörnchen,
es ging ihm darum, ob column vertikal bleibt, wenn ein writing-mode die Blockachse in die Horizontale dreht.
Soweit ich weiß: column ist immer senkrecht. Der writing-mode bezieht sich nur auf das Innere der Flex-Items.
Bei inline-flex mit flex-direction: row musst Du eine width setzen, damit es zu einem flex-grow kommt. Das Setzen einer inline-size anstelle eine width geht bei vertikalem writing-mode in die Hose. Deswegen gibt's ja immer noch beides.
Rolf
--
sumpsi - posui - obstruxi-
Sprich: bei einem auf Spalte gedrehten Flex sind flex-grow usw. sinnfreie Angaben⁈
-
Hallo nix,
so wie ich das sehe, ist flex-grow dann sinnvoll, wenn in Grow-Richtung mehr Platz festgelegt wird als die Flex-Items auf Grund ihrer flex-basis Größe in dieser Richtung benötigen.
Aber er muss von außen festgelegt sein. Andernfalls ist die Flexbox so groß wie die Summe der Itemgrößen und es gibt keinen Anlass für einen Grow.
Rolf
--
sumpsi - posui - obstruxi-
Danke, werde damit mal „spielen“.
Aber die Idee dazu ist schon wieder …: ein Inline-Flex sorgt anscheinend zuverlässig dafür, daß das „Outline-Flex“ nicht mehr sonderlich viel vom Umbruch hält. Zumindest wächst es (schon wieder einmal) deutlich über den Viewport hinaus.
-
Hallo nix,
hm. Wenn Du dazu einen Link hättest oder das in einem Codepen / Fiddle / MDN Playground darstellen könntest?
Rolf
--
sumpsi - posui - obstruxi-
Kurz mal was gebastelt. Lustig da drin dann auch noch: wenn man im
pauswidtheinmin-widthmacht, passiert schon wieder was:<html> <head> <style> /* ol { display: …; } anscheinend: egal. */ .catalog { display: flex; flex-flow: row wrap; gap: 1em; } li { display: inline-flex; } p { display: inline-block; /*min-*/width: 27vi; } </style> </head> <body> <ol class="catalog"> <li> <p>A</p> <p>B</p> <p>C</p> <div class="inner"> <p>a</p> <p>b</p> <p>c</p> <p>d</p> <p>e</p> <p>f</p> </div> <p>D</p> <p>E</p> </li> <li> <p>F</p> <p>G</p> <p>H</p> </li> <li> <p>I</p> </li> <li> <p>J</p> </li> </body> </html>Hier ist das Verhalten (schon wieder) etwas anders als beim „großen Versuch“, aber immerhin ähnlich. Irgendwie scheint sich der Browser nicht entscheiden zu können, wie die inline-flex umbrechen sollen – oder nicht. Und: ein paar Buchstaben fehlen ab und an da doch im Alphabet?
Aber: wenn man dem inline-flex ein
flex-flow: inherit;mit auf den Weg gibt (an dem hier anscheinend alles oder fast alles hängt), fließt das innere flex doch ein wenig im äußeren.[1](Für mich störend/irritierend ist: wenn ein Flex als inline-flex doch wieder nur als Flex behandelt wird, seine eigene „Zellkultur“ aufbaut … das ginge doch auch ohne inline.)
Obendrein habe ich jetzt den „sehr dringlichen Verdacht“, etwas verstanden zu haben: inherit meint wohl immer „den ganzen Parameter-Satz“ und nicht einzelne Werte. Ich meine, man kann das z. B. unter padding schon auch anders verstehen. (Die Darstellungweise von logischen Blöcken, hier eine „entweder oder“ Aufstellung, ist ja auch überall anders …) Denn: flex-flow: x inherit (o. ä.) „funktioniert auch nicht“.
BTW:
flex-direction(auch als Tteil vonflex-flow) ist hier ja eigentlich überflüssig, vielleicht sogar (eigentlich) ein Fehler, das Spielen mit flex-wrap aber eigentlich nicht. Das ist eher lustig. ↩︎
-
Hallo nix,
oh je. Geschachtelte Flexboxen. Ein Kopfschmerzgenerator.
Eine wichtige Info ist: Der Default-Wert von flex-shrink ist 1. D.h. Flexbox hat grundsätzlich erstmal das Recht, Elemente schmaler zu machen, wenn nicht genug Platz ist.
Weiter ist wichtig: width ist für ein Flex-Item nicht der Maßstab, sondern der flex-basis Wert. Den legst Du nicht fest, damit ist er "auto". Frag mich aber nicht, wie er "auto" auf die Realität abbildet. Möglicherweise orientiert er sich an width.
Das gilt nicht für die p Elemente im .inner div. Die sind keine Flex-Items und haben daher eine Breite von 27vi.
Die Bestimmung der Größen in einer Flexbox ist kompliziert. Ich nehme für mich nicht Anspruch, das verstanden zu haben. Lies selbst
Grundsätzlich ist es so, dass er den Wert von flex-basis mit flex-shrink multipliziert und die erforderliche Verkleinerung im Verhältnis dieser Werte auf die Flex-Items verteilen soll. Das tut er bei Dir nicht, er verkleinert nicht genug. Und ich habe keine Ahnung, warum.
Wenn Du für die flex-items eine min-width setzt, dann gibst Du eine Untergrenze für die Verkleinerung vor. Deshalb wird .inner auf einmal sehr viel schmaler, die p darin landen untereinander, die Zeile wird viel höher und der Defaultwert von align-items:stretch wird aktiv: die p Elemente A,B,C,D,E werden höher.
Ich hoffe, das hat es etwas erhellt. Ein paar Schatten krieg ich nicht weg.
Rolf
--
sumpsi - posui - obstruxi-
Kopfschmerzen („global gesehen“)? Schlimm! Denn inline-flex ist ja was einigermaßen „offizielles“.
Kopfschmerzen (diesmal „ganz lokal“)? Na ja, nicht ganz so schlimm wie beim Grid. Aber (vermutlich aus ähnlichen Gründen: die Angaben von Höhen und Breiten, vor allem diejenigen mit „max-“ oder „min-“ davor, bewirken … ähm … nix. Und beim Herumexperimentieren mit cq-Dingens wird man auch nicht gerade schlau. Denn da sind 100cqi schnell mal mehr als 100vi. Selbst dann, wenn es ein „Ururur-Enkel-Element“ ist und drum herum irgendwie (versuchsweise) mit containter-type und/oder contain herumgemauert wurde. Und dann doch wieder nicht. Dann ist es weniger, aber hängt … tja, woran? Den Anker dazu wenn ich erst mal habe …
Ach ja, das .inner-div. Ist von mir übersehen worden. Mein schnell gezimmerter Versuchsaufbau war anfangs etwas anders gestaltet. .inner wäre da auch ein inline flex (hey, das geht in der Zweitwort-Syntax!)
Und jetzt werde ich erst mal … lesen? Nein, meine Augen auf flex-basis und Co richten. „Versuch macht kluch!“ Man hofft es jedenfalls! Und da ja width nicht der Maßstab ist, na, einen Veruch ist’s bestimmt wert.
Danke!
-
Hallo nix,
da sind 100cqi schnell mal mehr als 100vi.
das kann ich mir aber nur dann vorstellen, wenn der Container breiter ist als der Viewport. Wenn nicht: hast Du ein Codepen- oder JSFiddle, in dem das passiert?
Rolf
--
sumpsi - posui - obstruxi
-
-
@@Rolf B
Die Bestimmung der Größen in einer Flexbox ist kompliziert. Ich nehme für mich nicht Anspruch, das verstanden zu haben.
Ich nehme für mich nicht Anspruch, das überhaupt verstehen zu wollen. 😆
Flexbox setze ich ein, wenn ich flexible Boxen haben will.
Wenn ich die Größe der Boxen unter Kontrolle haben will, ist Grid oft das bessere Mittel der Wahl.
🖖 Живіть довго і процвітайте
--
„Ukončete, prosím, výstup a nástup, dveře se zavírají.“ -
@@Rolf B
Weiter ist wichtig: width ist für ein Flex-Item nicht der Maßstab, sondern der flex-basis Wert.
Auch auf der Liste der Sprachfehler von CSS:
Flexbox should have been less crazy about
flex-basisvswidth/height. Perhaps: ifwidth/heightisauto, useflex-basis; otherwise, stick withwidth/heightas an inflexible size.🖖 Живіть довго і процвітайте
--
„Ukončete, prosím, výstup a nástup, dveře se zavírají.“
-
-
-
-
-
-
-