Sie kennen die Syntax mit einem Wert: .thing { display: block; }. Der Wert „block“ ist ein einzelner Wert. Es gibt viele Einzelwerte für display. Zum Beispiel inline-flex, was wie flex ist, da es ein Flex-Container wird, aber sich wie ein Element auf Inline-Ebene verhält und nicht wie ein Element auf Block-Ebene. Ziemlich intuitiv, aber besser bedient von einem System mit zwei Werten, das dasselbe Konzept breiter und ebenso intuitiv anwenden kann.
Für eine eingehende Betrachtung sollten Sie den Blogbeitrag von Rachel Andrew lesen: The two-value syntax of the CSS Display property. Die Spezifikation ist ebenfalls eine gute Lektüre, ebenso wie dieses Video von Miriam.
So stelle ich es mir im Gehirn vor

block oder inline, dann wählen Sie flow, flow-root, flex, grid oder table. Wenn es ein list-item ist, ist das eine dritte Sache.Sie wählen im Wesentlichen einen aus jeder Spalte, um das gewünschte Layout zu beschreiben. Die vorhandenen Werte, die wir ständig verwenden, lassen sich also ungefähr so darstellen:

Eine andere Art, über diese beiden Spalten nachzudenken, sind die **„äußeren“ und „inneren“** display-Werte. Außen, d. h. wie es mit anderen Elementen drumherum fließt. Innen, d. h. wie das Layout innerhalb dieser Elemente abläuft.
Kann man es tatsächlich benutzen?
Nicht wirklich. Firefox 70 ist der erste, der es implementiert, und mir sind keine weiteren Anzeichen für Unterstützung von Chrome oder Safari bekannt. Es ist eine großartige Weiterentwicklung von CSS, aber was die alltägliche Nutzung betrifft, wird es noch Jahre dauern. So etwas Grundlegendes wie das Layout will man nicht scheitern lassen, nur wegen dieses eher geringfügigen beschreibenden Vorteils. Wahrscheinlich ist es auch nicht die Mühe wert, mit @supports und Ähnlichem progressiv zu verbessern.
Einzelheiten
- Schauen Sie sich den Teil der automatischen Transformationen an. Nur weil Sie einem Element einen bestimmten Display-Wert zuweisen, heißt das nicht, dass dieser nicht unter bestimmten Umständen überschrieben werden kann. Ich gehe davon aus, dass es hauptsächlich um ein Element geht, das gezwungen wird, ein Flex-Element oder ein Grid-Element zu sein.
- Es gibt implizite Kurzformen. Wenn Sie zum Beispiel
inline list-itemverwenden, ist das eigentlichinline flow list-item, währendlist-itemblock flow list-itemist. Das alles erscheint ziemlich intuitiv. - Sie verwenden immer noch Dinge wie
table-rowundtable-header-group. Das sind Einzelwert-Konstrukte, ebenso wiecontentsundnone. - Spalte eins enthält technisch gesehen auch
run-in, aber soweit ich weiß, hat kein Browserrun-indisplay jemals unterstützt. - Spalte zwei enthält technisch gesehen
ruby, aber ich habe nie verstanden, was das überhaupt ist.
Wie wir über CSS sprechen
Ich mag, wie Rachel diese Änderung mit einem rationaleren mentalen und didaktischen Modell verbindet.
… Sie erklären die Interaktion von Boxen mit anderen Boxen korrekt, im Hinblick darauf, ob sie block- oder inline-basiert sind, plus das Verhalten der Kinder. Um zu verstehen, was display ist und tut, denke ich, dass sie eine sehr nützliche Klarstellung darstellen. Daher habe ich begonnen, display mit diesen beiden Werten zu lehren, um zu erklären, was passiert, wenn man Formatierungskontexte ändert.
Es ist immer aufregend, neue Features implementiert zu sehen. Ich hoffe, dass andere Browser diese Zwei-Wert-Versionen bald ebenfalls implementieren werden. Und dann, in nicht allzu ferner Zukunft, werden wir in der Lage sein, CSS so zu schreiben, wie wir es jetzt erklären, und die Beziehung zwischen Boxen und dem Verhalten ihrer Kinder klar demonstrieren.
Hallo Chris,
Aha, danke für die neuen Perspektiven. Auch die CodePens im zitierten Blogbeitrag von Rachel Andrew sind sehr klärend!
Nebenbemerkung
„#Eigenheiten (…) soweit ich weiß, hat kein Browser run-in display jemals unterstützt.“
Erinnern Sie sich an Ihren Artikel von 2010 css-tricks.com/run-in? ;-)
Darin steht: „Firefox unterstützt es überhaupt nicht, auch nicht die Version 4 Betas. Die WebKit-Familie (Safari und Chrome) unterstützt es, ebenso wie Opera und IE8.“
In der Zwischenzeit
– Firefox hat gewonnen!
– Internet Explorer unterstützt es bis zum Ende (IE11), in Ihrer Testseite css-tricks.com/examples/Runin schwimmen alle Fische mit IE11 herum; aber MS-Edge hat die Unterstützung eingestellt.
– Chrome, Opera und Safari haben ihre Unterstützung ebenfalls eingestellt; nur Opera Mini unterstützt es heutzutage.
– Nur 1,65 % der globalen Browsernutzer können das run-in genießen (0,19 % IE8/IE10, 1,85 % IE11, 1,3 % Opera Mini).
– Siehe: caniuse.com/#search=run-in.
– Der w3c css-Validator gibt Grün zu Ihrer Testseite, im Einklang mit den Spezifikationen.
– Aber die Entwickler-Panes in FF und Chrome zögern nicht, run-in als „ungültigen Eigenschaftswert“ abzulehnen.
Schlussfolgerung: de facto können wir display: run-in; als ungültig betrachten.
Entschuldigung, aber was hat Sie zu dieser Schlussfolgerung geführt? Sowohl die Spezifikation (die informative Tabelle direkt vor Abschnitt 2.1) als auch Rachel Andrews Artikel scheinen diese Kombination klar als perfekt gültig aufzulisten. Sie bedeutet „Block-Level-Block-Container, alias Block-Box“ und ist äquivalent zum guten alten
block-Wert. Mit anderen Worten, es ist eine einfache Block-Box, die keinen neuen Block-Formatierungskontext erstellt, daher löst sie keine Floats auf und lässt die Ränder ihrer Kinder mit ihren eigenen Rändern kollabieren), im Gegensatz zublock flow-root(aka nurflow-root), das eine Block-Box erstellt, die einen neuen BFC erstellt.Ups! Ich kann das klarstellen. Ich bezog mich auf dies in der Spezifikation.
Ich interpretiere das so, dass, nur weil Sie möchten, dass etwas wie ein Block-Container funktioniert, es sich so verhält, wenn es ein Flex-Kind (oder Ähnliches, denke ich) ist.
Ah ja, diese „Blockifizierung“ und „Inlineifizierung“ sind wirklich knifflig (besonders Letzteres). Grundsätzlich ja, sie passieren, wenn wir versuchen, etwas in einen Kontext zu platzieren, in dem es sich nicht so verhalten kann, wie sein Wert es vorschreibt. Die „Blockifizierung“ von ursprünglich inline-Elementen ist häufiger (traditionelle Beispiele sind floatende und absolut positionierte inline-Elemente; das Konvertieren von inline-Elementen in Flex- oder Grid-Elemente hat denselben Effekt). „Inlineifizierung“ erscheint mir immer noch exotisch (ich habe es noch nicht in der Praxis gesehen, und wenn ich die Specs durchsehe, fand ich es nur im Ruby-Kontext, der selbst eine ziemlich exotische Sache ist). Aber grundsätzlich, soweit ich verstehe, bedeutet es, dass wenn wir einen Block-Container in eine Umgebung platzieren müssen, die nur inline-Kinder akzeptiert, CSS diesen Block in ein Inline-Block (
inline flow-root) konvertieren muss, dainline flow(akainline) jegliche Block-Container-Funktionen verlieren würde.Das stimmt, aber es ist etwas anderes. Es ist nur der unabhängige Formatierungskontext und nicht die automatische Transformation des Box-Typs. Es beeinflusst das Verhalten, ändert aber keinen der Komponenten des
display-Werts.Bitte korrigieren Sie also die rote Linie im Diagramm:)
Beeindruckend! Danke für das Teilen des Beitrags.