关于：css display run-in

还没有试过这个

原文地址：display run-in">关于：css display run-in作者：emlyhch

CSS has a value for the display attribute calledrun-in. It’s like this:

h3 {  display: run-in;}

The point is to allow a header to run into text below it,without sacrificing semantics or running into the problems youmight run into trying to force it with other layout techniques.

Let’s take a closer look.

But why not __________?

But why not float it to the left? Well headersare often of larger font-size than body type. So if you float theheader to the left, you might catch more than one line.

But why not make it an inline element? Becausethe following text might be (actually, is likely to be) inside of aparagraph tag. Paragraph tags are block-level, and thus the willbreak to a new line if they follow an inline element and the effectwill not be achieved. You could insert the<h3> tag within the<p> tag, but that has semanticconcerns, and more importantly, long term maintenance concerns.What if this effect goes out of vogue?

But why not use inline-block? Same problem asabove. The effect will not be achieved unless you tuck the headerinto the following paragraph which is problematic.

How does it work then?

If a run-in element precedes a block level element, the run inelement will behave structurally as if it has become the blocklevel elements first inline child element.

Browser Support

Haven’t heard much about this? Well it might be because browsersupport is a bit weird.

Rumor has it that Mozilla isn’t happy withthe spec.Firefox doesn’t support it at all, including the version 4betas.

The WebKit family (Safari and Chrome) are supporting it, as wellas Opera and IE 8. There are some differences in how these browsershandle things though. Reports have itthat older versions of WebKit and Konqueror allowed run-in elementsto run into succeeding inline elements which is incorrect.

Issues in the spec?

In my own reading of the spec, I find it a bit unclear.

If a sibling block box (that does not float and is notabsolutely positioned) follows the run-in box, the run-in boxbecomes the first inline box of the block box.

That makes sense and appears to be how it works, butdoes “becomes the first inline box” mean that the run-inbox should become a descendant of the block box? In WebKit, therun-in element retains itssolidarity.

A run-in cannot run in to a block that already starts with arun-in or that itself is a run-in.

Does that mean that there can’t be two headers, both run-ins,that run into a paragraph below? That’s how I would read it, but Ithink the WebKit implementation where they both fall inside makes more sense. Operaand IE 8 follow the spec in that the first run-in becomes block andthe second goes inline.

Then it says:

Otherwise, the run-in box becomes a block box.

Otherwise is a big word, but implementations have beenpretty good here. Three run-in’s in a row inside a parent with noother siblings? They all go block. A run-in sandwiched between twoinline elements? It goes block. Run-in >absolute-position > block, the run-in goes block.Mind-bending, I know, but current modern browsers are doing goodhere.

If the run-in element contains anything block-level, it becomesblock-level. All browsers seem to agree on that one.

Demos

Here is my own simple demo page. Thereis also a superhardcore demo (which is over 10 years old).