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).
That’s a pity that Firexox doesn’t support it…
Great tip! Thx Chris.
Didn’t know that. Thanks for the tip.
Great Tip but sad Fire fox doesnt like it.
That attribute would be great if Firefox supported it. Shame!
It’s strange that firefox doesn’t support it, but IE8 does.
I guess not if they don’t agree with the spec. But you’d expect at least a slight effort at integration as the other vendors have tried.
It’s certainly an interesting concept and one that could prove very useful if the spec were to be agreed upon and it be implemented in the latest releases.
That’s pretty cool. I’m sure someone will come up with a shiv for FF…
What’s the point of an article about a css attribute that doesn’t at the very least have broad support in the latest version of all browsers?
Does anyone really implement commercial standard websites using flaky supported css properties?
My opinion, not meant to start any controversy
In my opinion, this has pretty wide support. The fact that Firefox is a holdout makes this extra interesting and all the more worthy of an article.
Uh What? So what you saying is… what’s the point of any CSS3 article since {insert browser} does not support it? 4 out of 5 is more then enough.
People implement websites using proprietary css (and other) markup that only work in one browser
…not pointing any fingers, of course : )
“There will one day be lemon-soaked paper napkins” – HHGTTG
I’d rather learn about this stuff now rather than have to play catchup when it’s widely implemented enough to use.
I only ever use tiny amounts of HTML5 and CSS3 due to the lack of support / signed off standards, but articles like these prepare us better and give us places to refer back to when the time is right.
Good on ya Chris.
I can’t bring myself to use it until FF decides to support it, but it’s excellent article fodder (why the b!tching?). I’ve bookmarked it in anticipation of FF deciding to support it. I hope they do, it’s an excellent attribute that I would find quite useful.
Think of it in terms of progressive enhancement. You can use this attribute and the day FF will support it, it looks like in other brothers. Until then it looks different, but it does no harm to the content.
This is exactly what I have been looking for in one of the projects I am currently working on, but probably won’t use it since FF doesn’t support it.
It’s heartbreaking finding exactly what you want, only to realize you can’t really use it.
You could achieve this effect by setting display: inline to both the header and the following paragraph. It may (depending on your usage) require adding an extra class to the tag but it works fine across all browsers that I have tested.
Cool tip. 53% of my blog readers use FF, 13% use Chrome, and only 6% use Safari. I’m not about to use something that the main browser of choice doesn’t support.
Even in my work environment, where FF is around the typical usage (maybe somewhere in the 40’s percentile, that is too high to ignore. And even if someone did come up with a way for it to work, like the above person said, that is more crap to fiddle with just to get it to work in one browser.
I do appreciate seeing something I didn’t even know existed though. I agree with FF in not supporting it. If you can’t figure it out, it must indeed be too vague to bother with.
I can absolutely see instances of design where headers have run-in, but the design is such that in Firefox it just goes block-level and the design is no worse for the wear.
Generally speaking though, you’re not in the majority. For many areas, it’s a toss up between Chrome and IE at the moment, and it all depends on your location, target demographic, local affluence and a ton of other factors.
Probably 40% of users of my sites use Chrome, and the same for IE. But for specific sites, this can get very odd indeed, with a lot of users using lower version IE. It all depends.
It’s certainly worth knowing about these things, especially when you consider that you can gracefully degrade for unsupported browsers.
Chris, oh how I enjoy your articles but please can you do us CSS nerds a favour?
Don’t let me drool over this potentially awesome CSS property and the promise that it holds, read through a long article about it, and then tell me that it’s poorly supported at the very end? This leads to disappointment in my brain.
If you’re writing about a CSS property can you mention browser support much earlier or better yet display the logos of the browsers that support it at the top of the page.
On the plus side I enjoyed this informative article and, like full CSS3 support, I can’t wait til it’s a univeral reality. I’m 28-years old now so I’ll be on my third mid-life crisis before all CSS3 properties are supported by all browsers – anyone wanna sell me their sportscar early?
It’s not that long of an article and there is an entire section on Browser Support. Unfortunately it’s not as simple as supported vs. not supported.
Also to be clear, it’s not specifically CSS3. Browsers have been toying with it for over 10 years.
How funny are the double standards that we designers/developers (myself included) have?
We use cool tricks, properties and CSS3 that IE can’t handle and are ready to scream “I’m using it and if IE users can’t see it, well screw them, it’s time for them to start using a decent browser anyway”. But now that we found one (1) property that FF does not support but ALL other browsers do (in some extend), we’re like “I’m not gonna use that! FF users won’t be able to see it”!!
:)
Recently Battle.net’s Real ID page (http://us.battle.net/en/realid/) had implemented this and looked really sharp in the context of the page design (it looks like it has since been removed).
It likely wouldn’t work in all design contexts, but is definitely one more tool in the designers arsenal, especially since it degrades gracefully in firefox to a normal block level element.
Chris, thanks for the explanation and history on this display mode, and for the demo so we can all see it in action.
First time I seen it in Opera config (for small resolution), but never needed to use in my work.
Nice find and excellent research on the spec. You should absolutely continue writing about such finds.
Still, I also notice this pattern, not just on your site, but a lot of sites writing about CSS. It starts with an exciting feature and ends with “ah, never mind…can’t use it”.
I know that with the right mindset you can get things like this to work across browsers, but more and more I find the effort, hacks and extra libraries that are sometimes required to be a waste of time, and I end up just not using it, exceptions aside (such as rounded corners and shadows that degrade really gracefully).
I guess one could use a span element inside of a paragraph element with the same styles as the header you wish to imitate.
It doesn’t seem that FF/gecko-engine browsers supports this attribute, but browsers/web-kit-engine that support this functions displays these attributes properly. I believe that this helps eliminates float attribute/design layouts until *all* browser technology catches up. Its unfortunate that css is out-dating browser engines and not vice versa, or the world would be a better place.
Well this is first time I came across this attribute. Thanks a lot for sharing it.
Never knew about the run-in attribute. I could certainly find some uses for it despite some Firefox issues!
Thanks for the info, Chris!
Just when I thought I knew all there is to know about CSS 2.1 I read about this pretty awesome attribute. Like all attributes, it won’t be used on every project, but there will come a time when it’ll be nice to use instead of a class using span.
As for Firefox not supporting it, I believe this would be one of those cases in which 99% of the time it will degrade gracefully for that 15% of site visitors. I still see IE6 users and I don’t even use any type of PNG fix for PNGs with transparency any more.
In my opinion (which is usually way off), anyone who hasn’t done something that isn’t supported by 100% of browsers probably has never gone outside of the proverbial box.
i mean:
i guess we can replace h3 with font
Is there any jQuery alternative that is cross browser?
Since most browsers don’t support display: run-in, to style run-in headers I use display: inline on headers and the next sibling paragraph using the adjacency selector +, which is well-supported. For example,
#content h3, #content h3 + p{ display: inline; }
or
#content h3{ display: inline-block;}
#content h3 + p{ display: inline;}
which also seems to work (at least in FF and Safari) and lets you apply margins to the h3.
I found out about + when I was browsing quirksmode.org’s compatibility tables. Really useful.
Oops, here’s the correct link to quirksmode.org’s compatibility tables. Copy-paste error. Sorry about that.
Note that this technique’s usefulness is limited by the requirement that there be an element before the h3 that is displayed as a block (for example, that each header have at least 2 paragraphs below it since the 1st paragraph is displayed inline). Otherwise, the header will not only run into the following paragraph but also the previous one.
And scratch what I said about inline-block, it doesn’t work for multiline headers.
Display: run-inis not supported in Chrome anymore.