Patience isn’t something I naturally possess, particularly when I really want to solve a problem. As many designers and developers know, a large part of our job requires patience - with ourselves; with software companies developing production and productivity tools; and of course with our good friends, the browser vendors.
But I’m beginning to lose patience regarding the widespread adoption of a wonderfully useful display property value for the CSS display property, run-in. This value was introduced with the CSS 2 specification, and is also in the still-not-recommended CSS 2.1 spec. It was implemented by IE 5 for Mac, ironically, and is supported for the purposes described in this article in Opera, Konqueror and Safari. No IE for Windows supports the value, nor does Mozilla Firefox. How’s that for a change of pace?
Display Property: Common Value Usage
Most people working with CSS are already familiar with the CSS display property. We use it regularly for a number of techniques including:
Displaying lists to create horizontal navigation using the inline property value:
ul {display: inline;}
Displaying inline elements as block elements, in this case to ensure each link extends to the width and height of the list item rather than just the link itself:
a {display: block;}
We’ve even used the none value for display, particularly in early image replacement techniques:
Take Your Vitamins
h2 {background-image: url(images/tyv.png);}
span {display: none;}
What Does run-in Offer?
Displaying an element as run-in causes boxes to display either as inline or block, depending upon the context of the markup - a perfect example, and one of the primary reasons I’d like to encourage implementers to make run-in a priority implementation in upcoming revisions. Since that will take time, I’ll show you a simple but extraordinarily elegant use of run-in display for typographic enhancement. Consider the following markup:
Take your vitamins!
It’s imperative you think about your nutrition. Whether that be what you eat or what you read, nourishment is not only desirable, but necessary.
Feel great, look fabulous, work better.
After several weeks, you’ll find that taking your vitamins will make you have more energy than ever. Your skin will clear up, your mind will be sharp, and your colleagues are sure to take notice.
Impress your friends, your family and even your boss.
Who knows, maybe your boss will see the results and you’ll find yourself with a pay rise, a corner office, and a brand new car. Okay, I can fantasize, can’t I?
Here we have a simple, semantic example of marking up some headers and text. Assuming that the rest of the document retains its required structure and content is marked up semantically, this markup will be very accessible and logical to everyone, including those with special needs. Here’s the content displayed with no additional style in Opera 9:
Using run-in display, I can display the headers visually in a traditional typographic manner that we’ve not truly had available to us without using additional elements. Here’s some styles, including the run-in display value, that add this typographic option without ever adding presentational elements:
h2 {display: run-in;font-family: Verdana; font-size: 1.5em; color: violet; margin-right: 10px;}
p {font-family: Georgia; font-style: italic; font-size: 1.0em; color: #333;}
The fun results can be seen here:
Digressive Enhancement
The good news is that you can still use the run-in value if you’re willing to sacrifice the effect in IE Windows and Gecko browsers such as Firefox, and in this case, Camino. Here’s what those users will see:
Not too terrible, but again, nowhere near as pretty. And real designers could have a field day with this sort of thing, including background images, image replacement and so on to really enhance the typographic texture and visual flow of the document’s presentation.
There’s a reason it’s important to advocate this for certain useful aspects of a spec that might not have full implementation. Without interest and support from the community, such features could easily get dropped from future specifications.
It’s difficult enough getting features we want into the specs in the first place, so let’s not let the good stuff we do have, such as the run-in value for display, disappear before we have a chance to see it properly implemented and available for consistent use.
Like this article? Digg it!
Hey…
Very cool demo, thanks… though you’ve got a type in your first UL code:
you have:
item
should be without the semi-colon (unless I’m crazy or something):
item
Steve
- corrected, thanks Steve!
Good article, it seems as though the semi-colon that Steve mentioned is still there, just a heads up.
It should be pointed out that run-in behavior can be a little bit tricky in some edge cases, which may be why its implementation has been delayed. Still, if nobody asks it’ll never get implemented, so well done!
Eric: “Still, if nobody asks it’ll never get implemented, so well done!”
ummm…. Why should we have to ask that a standard be fully supported. If it’s in the standard, it should be supported.
Very nice information. I wonder why I’ve never experimented with it. I’ll do that tomorrow. Thank you for raising the interest. I’m certainly going to give it more attention now. :)
Okay, can a real designer show how this is useful? I don’t see anything special here. Couldn’t “float: left” or “display: inline” do this trick? I think Molly wrote this one on the way out th door.
Colin: “Okay, can a real designer show how this is useful?”
What makes you think that Molly isn’t a real designer?
Great article, Molly. I’ll start implementing this on my sites.
Run-in can be useful, but the display property that can really change things is “
display:inline-block;“. Safari implements it, and IE kinda does. Mozilla-based browsers are really lagging behind here as all they’ve got is a -moz- property that really doesn’t work. But there’s SO many cases where this is useful, cases where people are using floats because there is no other choice. Better support for “table-cell” would be nice to, because it allows finer grain control of vertical spacing and other table-licious visual properties.Mark: because resources are finite, and thus feature additions are prioritized. The feature nobody asks about will be the last one added, and that can be on a time scale years long. Isn’t that kind of obvious?
Colin: ‘run-in’ inserts the element as an inline box at the beginning of the following block element. That’s very different from floating, not least of which because that causes the run-in element’s baseline to be perfectly aligned with the baseline of the following block’s content. ‘inline’ doesn’t do the same thing, either, unless you make both elements ‘inline’, which has significant consequences for the layout of the following element. So they’re actually very, very different.
Colin: The other point here is there’s no need for extra markup. As such, the integrity of the document remains intact.
Mark: I agree with you. The display property values in general have poor support yet offer so much. I chose run-in because it at the very least can degrade somewhat gracefully to those browsers that don’t support it and again, document integrity reigns supreme. But you are spot-on, there’s a lot of undiscovered country there!
[…] Vitamin has published my “In Search of the Missing run-in Value.” Hop on over and let me know what you think in the comments there. […]
I’ve used this effect on a few site, but in lieu of the run-in property working as it should in FF and its ilk, I’ve done this sort of thing:
h2 + p {
display: inline;
}
Not as elegant as the run-in value, and still doesn’t work in IE — but does work well in FF and Safari. :)
Hey Jeff, excellent point. Also, in IE7, it’ll work! Nice.
Colin: The run-in header is a classic typographic style. It certainly is useful from a designer’s perspective, even used exactly as Molly used it. I recommend Robert Binghurst’s “The Elements of Typographic Style” for some nice example on how this effect can be used.
I have to agree with Colin regarding the explicit difference to the inline property. That just didnt come across to run-in newbs, like me. (eg: i use display: inline for this typographic effect - thus some of my commentors complain about lost paragraph-styling)
Thanks to Erics explanation, i finally understood, what this article wanted to illustrate. Anyway: good article. Thank you Molly & others.
Molly, I think you hit the nail on the head whilst you were at the same time ignoring that you’ve done so.
“The good news is that you can still use the run-in value if you’re willing to sacrifice the effect in IE Windows and Gecko browsers such as Firefox, and in this case, Camino.”
That’ll be a total user base of 98+% then for the average site for which this doesn’t work.
I appreciate your “don’t ask, don’t get” approach towards browser manufacturers, especially in the light of your great work on WASP, and all the other standards bodies you’re involved with, but as far as real life usefulness goes, I’m afraid it scores a zero until at least one of the big boys implements it.
Simply using these values, as the teaser for the article suggests (”Molly E. Holzschlag encourages you to take advantage of little-known CSS values, such as run-in display, before they disappear…”), is not going to make support for it magically appear.
I do like Jeff Croft’s solution, though. Once IE7 has gained a decent market share, that is. :o/
Don’t get me wrong - this is not so much a criticism of your article, more one of the classification of it - it should probably have been categorised under ‘Standards’, or ‘Browsers’….
Eric’s right about using float, certainly, however I’ve just been playing around with Molly’s example and was able to get a something resembling the run-in example.
It’s not perfect, and goes weird with the text baseline if the h2 spans more than one line, however, depending on your requirements, it might be passable. It’s just a matter of tweaking the negative margin values to line up the baselines:
h2 { float:left; margin:-0.35em 10px -0.35em 0; padding:0; font-family: Verdana; font-size:1.5em; color:violet; }
Seems to work okay in IE (6 and 7), Fx 1.5 and Opera 9 (and supports font scaling in all three — apart from the aforementioned multi-line h2 issue).
But yes Molly, I agree we would be blessed if we could do it across the board with a simple change of display property.
[…] Molly Holzschlag teaches us about another one of those lesser used CSS rules; display: run-in; that really could be put to better use. But why is this not supported by Firefox? It would appear to be one of the better class’ to support. I can already see a use for it in this site, removing span div’s from the equation and making the code a little easier. Cycleshow 2006 Pink For October […]
This article was severly lacking one major point, which thanks to Mr. Meyer has been cleared up - exactly what run-in is supposed to accomplish.
Molly you never explained why run-in would be any better than it’s other counter parts, which I didn’t understand either until Eric’s comment. Without the explanation, the exampe doesn’t look like anything that can’t currently be done with floats.
Alright. All my questions were cleared up. Thanks Eric. Like Jeff, I wasn’t so sure as to what run-in did specifically.
Jeff: I apologize for that. The issue goes back to document integrity. The run-n display value provides a classic typographic option without breaking the semantic and structural logic of a document. Floating, positioning, using additional elements to achieve this sort of result are all hackish in the end. This technique is, in an ideal browser world, ideal because the header is kept in the normal flow of the document, no additional markup is necessary to achieve a presentational result, and the run-in display is purely presentational - never affecting the actual document but only its display.
This is the ideal in a CSS-based environment. I hope that Eric’s helpful commentary as well as the good questions and options raised here round out what I didn’t clarify.
One other thing. Is there an official way to ask for this to _not_ be dropped from the spec?
Cool stuff Molly.
Now that I think about this a little more, why would anything like this be dropped from the spec at all? Resource issues aside and deprecated tags, etc. why would anyone not include this? So what if it takes a while to implement into browsers?! We’re used to waiting! (wink) There’s nothing wrong with implementing more important/requested things first, but when you’re done with those, go for the rest! Seriously. Eventually, the priority stuff will get in there. Are brower devs just gonna stop? I never heard of run-in and I am sure there are more I don’t know, but jeez just put it in! WebKit devs found time to put text shadow in…
OK… decaf from now on…
Man you have just got to love Molly! Nice one! Thanks to both you and Eric for clearing up specifically what run-in does…
Great to see any new implementations coming along. Keep up the noise!
Great Stuff Molly. I love this kind of article - I would like to see more articles like this.
Implementers implement what they implement. W3C specs may or may not have anything to do with it. Consider the
centerelement. Netscape implemented it, it made it into the spec - not the other way around.To get implementation we have to make noise. Write articles, blog posts, link to each other, talk about what we as designers and developers want and need in as public a forum as possible. The W3C does not enforce implementation. To paraphrase my own chair at the W3C, Richard Ishida, this is our Web, not the W3C’s. And not Microsoft’s or Mozilla’s or any company or organization. Ours.
Thanks for the great discussion and requests for clarification here. It’s exactly this sort of discussion that makes the difference, so let’s keep talking about what real working web designers and developers need, want and advocate for those things.
It is a shame that the world of designers and developers have no real vote that counts:
For example advanced selectors like li: first-child, media queries or display:table
We have two major forces that hold us back:
Slow implementation of WWW specs which holds back designers to use *unknown* or *newer* CSS specs and unexplainable poor communication between www, vendors like Microsoft and others AND the professional world.
Maybe we should start a union after all.
Ok, this is a good little tidbit to know about, but IMO it currently falls squarely into the useless category since it doesn’t work for over 95% of visitors to most sites. Something that doesn’t work in IE or FF? Great! (/sarcasm)
Wow, the sad thing is that this is a technique that I know has been attempted with various forms of “float’ and “display:inline” by many designers. I didn’t know the run-in option existed, and unfortunately, without more browser support, I can’t say I expect designers to start using it. I know the ideal trend is that designers will use something in a few browsers and popularize it so others will implement it, but it never seems to work that way.
Molly,
Thanks for the extra clarification to my comment. It is kinda a neat effect, would be nice to see it get implemented - maybe IE8?
Dogmatism versus pragmatism?
[…] In search of the missing run-in value […]
For the noobs scratching their heads, I think there’s a “li” missing in that first CSS example.
ul {display: inline;}
should be
ul li {display: inline;}
I would definately like to see this implemented. I am often given designs that include header and paragraph text on the same line and it is hard to make people understand why I don’t want to do that in the HTML.
I used display: run-in for several years on my blog for entry titles, but ran into a problem in Safari where the first line of the paragraph following the title would intermittently (about 75% of the time, but annoyingly not 100% of the time) left justify instead of starting at the end of the ran-in title, resuling in two bits of text occupying the same space on the screen. I submitted it as a bug to Apple using the facilities in Safari, but never heard from them, and the display anomaly persisted. I ignored it for a while, but ultimately gave up and removed display: run-in from my stylesheet. It wasn’t worth the intended design effect to mess up my site for a relatively small but important percentage of my tiny audience.
I just updated my desktop Mac to OS X 10.4.8 last week from 10.3.9, thereby updating Safari to 2.0. I haven’t checked if this behavior is still there.
Firstly, why are some people apparently criticizing the author of this article for the fact that the CSS is not supported by IE or FF? Surely it is the browser developers that should be taken to task for it, given that the technique is entirely valid in terms of published standards?
I’d never heard of this before, but it’s a great effect. If the word is spread, maybe we’ll get to use it. For the time being, it’s another addition to that long list of reasons to be a standards advocate.
Maybe this is the sort of thing that needs a page in Vitamin dedicated to effects that should be proposed to IE/FF. Sort of a laundry list of items we hope become browser aligned with standards? I am sure such pages exist somewhere out there, but maybe there needs to be a definitive source to point Microsoft and Firefox to when they are in development?
If you’ve got an account, go vote for bug 2056 to get this implemented in Gecko. That’s right people, we’re going back to the 4 digit bug numbers, almost 8 years old (and counting!)
This comparison table of display property support from PPK can be useful.
It shows that only Opera at this moment supports all display modes. Well done Opera!
Actually Opera supported run-in back to version 7.
[…] Egenskapen display bestemmer om eller hvordan et element skal fremvises. Med denne egenskapen kan du gi et inlineelement blokknivåegenskaper, eller fjerne elementet fra fremvisningen ved hjelp av verdien none. Spesifikasjonen presenterer oss også med noen mindre kjente verdier som for eksempel run-in. […]
Hi! Very nice site! Thanks you very much! PtfHDMQ5mtI4jR
dgtobmkep
Fantastic article!
Good article.
[…] read more | digg story […]
@Smithy - The example Molly has used:
ul {display: inline;}
is correct, the list items will inherit the inline value (value ‘cascades’). The example you supplied, also correct, could be argued to be unnecessary markup. Keep the code semantic.
@Molly - Great article, keep up the ’shout’ and I will consider using this typographic technique in future projects, I hope you will continue to raise awareness on any other values that we seem to look over. Some I have no knowledge of and have not seen mentioned widely are the speech values for slowing up/down and emphasis of certain words for screen reader users.
@Eric - Thanks for your comments and clearing up the specific usage for the run-in value, you have made it a lot clearer for those having never used it before.
nice article
thx for the great stuff
nice article! thank you