CSS Run-in Display Wert

CSS hat einen Wert für das display-Attribut namensrun-in. Es ist so

h3 {
  display: run-in;
}

Der Punkt ist, einer Überschrift zu erlauben, in den darunterliegenden Text überzugehen, ohne die Semantik zu opfern oder auf Probleme zu stoßen, die man versuchen könnte, sie mit anderen Layout-Techniken zu erzwingen.

Schauen wir uns das genauer an.

Aber warum nicht __________?

Aber warum nicht nach links flotten? Nun, Überschriften haben oft eine größere Schriftgröße als Fließtext. Wenn Sie also die Überschrift nach links flottieren, erwischen Sie möglicherweise mehr als eine Zeile.

Aber warum nicht ein Inline-Element daraus machen? Da der folgende Text möglicherweise (tatsächlich ist es wahrscheinlich) innerhalb eines Absatz-Tags liegt. Absatz-Tags sind Block-Level-Elemente und brechen daher bei einem Inline-Element in eine neue Zeile, und der Effekt wird nicht erzielt. Sie könnten das <h3>-Tag *innerhalb* des <p>-Tags einfügen, aber das hat semantische Bedenken und vor allem Bedenken hinsichtlich der langfristigen Wartung. Was, wenn dieser Effekt aus der Mode kommt?

Aber warum nicht inline-block verwenden? Gleiches Problem wie oben. Der Effekt wird nicht erzielt, es sei denn, Sie stecken die Überschrift in den folgenden Absatz, was problematisch ist.

Wie funktioniert es dann?

Wenn ein „run-in“-Element einem Block-Level-Element vorausgeht, verhält sich das „run-in“-Element strukturell so, als wäre es zum ersten Inline-Kindelement des Block-Level-Elements geworden.

Browser-Unterstützung

Habe das noch nicht oft gehört? Nun, das könnte daran liegen, dass die Browserunterstützung etwas seltsam ist.

Gerüchten zufolge ist Mozilla nicht glücklich mit dem Standard. Firefox unterstützt es überhaupt nicht, auch nicht die Beta-Versionen von Version 4.

Die WebKit-Familie (Safari und Chrome) unterstützen es, ebenso wie Opera und IE 8. Es gibt jedoch einige Unterschiede darin, wie diese Browser Dinge handhaben. Berichten zufolge erlaubten ältere Versionen von WebKit und Konqueror, dass „run-in“-Elemente in nachfolgende Inline-Elemente übergehen, was falsch ist.

Probleme im Standard?

Bei meiner eigenen Lektüre des Standards finde ich ihn etwas unklar.

Wenn eine Geschwister-Blockbox (die nicht gefloatet und nicht absolut positioniert ist) der „run-in“-Box folgt, wird die „run-in“-Box zur ersten Inline-Box der Blockbox.

Das ergibt Sinn und *scheint* so zu funktionieren, aber bedeutet „wird zur ersten Inline-Box“, dass die „run-in“-Box ein Nachfahre der Blockbox werden sollte? In WebKit behält das „run-in“-Element seine Solidarität.

Ein „run-in“ kann nicht in einen Block übergehen, der bereits mit einem „run-in“ beginnt oder der selbst ein „run-in“ ist.

Bedeutet das, dass es nicht zwei Überschriften, beide „run-in“, geben kann, die in einen darunterliegenden Absatz übergehen? So würde ich es lesen, aber ich denke, die WebKit-Implementierung, bei der sie beide hineinfallen, macht mehr Sinn. Opera und IE 8 folgen dem Standard, indem das erste „run-in“ zu Block wird und das zweite Inline.

Dann heißt es:

Andernfalls wird die „run-in“-Box zu einer Blockbox.

*Andernfalls* ist ein großes Wort, aber die Implementierungen waren hier ziemlich gut. Drei „run-ins“ hintereinander innerhalb eines Elternelements ohne Geschwister? Alle werden zu Block. Ein „run-in“ zwischen zwei Inline-Elementen? Es wird zu Block. Run-in > absolut positioniert > Block, das „run-in“ wird zu Block. Verwirrend, ich weiß, aber aktuelle moderne Browser machen das hier gut.

Wenn das „run-in“-Element etwas Block-Level-Element enthielt, wird es zu Block-Level. Alle Browser scheinen sich da einig zu sein.

Demos

Hier ist meine eigene einfache Demo-Seite. Es gibt auch eine superhardcore Demo (die über 10 Jahre alt ist).