CSS Run-in Display Value

CSS has a value for the display attribute called run-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 you might 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 headers are often of larger font-size than body type. So if you float the header to the left, you might catch more than one line.

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

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

How does it work then?

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

Browser Support

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

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

The WebKit family (Safari and Chrome) are supporting it, as well as Opera and IE 8. There are some differences in how these browsers handle things though. Reports have it that older versions of WebKit and Konqueror allowed run-in elements to 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 not absolutely positioned) follows the run-in box, the run-in box becomes the first inline box of the block box.

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

A run-in cannot run in to a block that already starts with a run-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 I think the WebKit implementation where they both fall inside makes more sense. Opera and IE 8 follow the spec in that the first run-in becomes block and the second goes inline.

Then it says:

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

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

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

Demos

Here is my own simple demo page. There is also a super hardcore demo (which is over 10 years old).