Every element in an HTML document accepts a value for the CSS display property. The possible values you can use for display are many.
The three most commonly used values are none, block, and inline. But what if you don’t define a display value for an element? Well, all elements have an initial or default state for their display value. Let’s consider some of these and see some interesting things you might not have known.
Blocks and Text-flow Content
This one is pretty straightforward. I’ve covered block vs. inline before, but here’s a quick review.
Container-type elements (like <div>, <article>, <p>, etc.) will start out as block-level elements, so the computed value of the display property for these is “block”. All headers (<h1>, <h2>, etc.), even though they generally only contain text content, are likewise block elements by default.
On the other hand, elements that flow with text content are inline elements. That is, their computed display value is “inline”. These are elements like <span>, <em>,
and <cite>.
With both block and inline elements, you can (if you choose to) redefine their display value to something other than their default. Generally this is done in order to give an element a value of “none” or one of the alternate values (e.g. table). You can also change an inline element to block and vice-versa. But in most cases, this really is not the right choice. Instead, you’re better off using a different element altogether or otherwise rethinking what you’re trying to do. (Update, Oct. 31/2012) People seem to be misinterpreting the previous sentence, now deleted. It’s definitely beneficial at times to change an <a> element to “block” or a list item to “inline-block”. My statement was more about changing something like a <div> element to “inline”, when you can just use a <span> instead.
Replaced Elements
In HTML, in addition to the elements already mentioned, there are also what are referred to as replaced elements. These include <img>, <input>, <select>, and <video>.
Although these are different from block and inline elements, they still have computed values for their display property. And they’re not always the same. For example, an <img> element, by default, is inline. Also, an <input> element is inline-block (which I’ve covered before).
Unknown Elements
Standards and accessibility advocates will hate me for telling you this, but the fact is, you don’t have to use any valid HTML5 elements in your documents. You could build an entire web page using your own made-up tags like <cookieMonster>, <potato>, and <sarcasm>.
So how would the browser read these foreign elements? Well, here’s a clue. Do you remember seeing this chunk of code in your CSS reset?
article,aside,details,figcaption,figure,
footer,header,hgroup,nav,section,summary {
display: block;
}
That’s added for older browsers (like IE6-8) that don’t recognize the new HTML5 elements. By default, in all browsers, all unknown elements have a computed display value of “inline”. Here’s a JS Bin that demonstrates this using a made-up element and then logging the display value of the element in the console.
And here’s another example with the same element given “block” status.
Invisible Elements
Here’s something you may not know is possible. HTML5 has a category of elements called document metadata. These include elements like <head>, <title>, and <style>. These elements, by default, are computed to display: none, as you can see by viewing the console in this JS Bin.
But, believe it or not, you can make them visible. Look at the screen shot taken below from the online version of Jeremy Keith’s HTML5 book:
As shown in Chrome’s developer tools, the header for the site is styled by making the <title> element inside the <head> visible by means of display: block. In this case, both the <title> and <head> elements need to be blocked, not just the <title>.
This can also be done to make an element’s stylesheet editable by the user, as demonstrated in this JS Bin. We do this using the contenteditable attribute on the <style> element. In supporting browsers, with that attribute set to “true”, the user can make changes to the CSS and watch them take effect instantly.
Conclusion
Most of what I’ve discussed here has been covered, to some degree, before, so this might not all be new to everyone. If you know of any other interesting things about the default display values for various elements, or have any corrections/additions to anything I’ve said, I’d love to hear them.
Is the img element really inline by default? That doesn’t make sense to me, because it has an explicit width/height. I thought it was inline-block.
I don’t think the fact that it has an explicit height/weight would affect whether it’s inline or not. You can see here:
http://jsbin.com/iwoqoh/13/edit
Open the dev tools and you’ll see that the console logs out ‘inline’ for the img element on that page.
<img> is not the image, it has no height or width on it’s own (unless of course you set it [untested, just figuring]).
I think it makes a lot of sense. Images are a kind of content and if you think of the old days of the web, when ‘hypertext’ was about text with links and images where not for decoration but for explaining things like scientific texts – also they had to be small in size, as display resolution where mostly 640×480 and networks where so slow.
Placing small images somewhere in you sentence within the flow of text was the only useful concept….
Great read, Ive thought about this a lot of times especially when I’m writing CSS and trying to keep it as clean as possible.
Nice article, thanks.
Thanks for this, will help me to clean up my CSS.
HTML5 doesn’t use the terms block and inline elements anymore. There is flow content and phrasing content, amongst other. How did you establish that in most cases changing the display value is a bad choice? I see a lot of reasonable use cases here, like making link boxes, css table layouts, inline header or hiding stuff. Excellent post tough.
Yes, definitely, link boxes are a good example. But for most cases, if you have to change something that’s inline to “block”, then you might be better off just using an inline element in the first place. Of course, that’s not a rule, just a general guideline. It all depends.
Never even considered trying to jump out of the body. That title being the top-most element thing could be useful. Wonderful article, a lot of interesting points.
Using contenteditable attribute on the style tag is very clever. Great post!
l loved the article, but I’m still confused with its conclusion. So, what are the best practices? How does the article will help me to clean up my code?
Sorry for the lame questions, but I’m a beginner.
Best regards,
Castle
The article was just discussing some interesting things about the display values of elements. Not necessarily best practices here, but more of a deeper understanding of how elements behave when you don’t explicitly declare a “display” value.
So using ‘display: inline-block;’ on li’s within a ul is bad practice and floating would be a better option?
No, not at all. That’s fine, I’ve done it many times. Maybe I should change the wording of that section discussing changing elements from their original state, because I think it sounded too presumptuous.
“You can also change an inline element to block and vice-versa. But in most cases, this really is not the right choice. Instead, you’re better off using a different element altogether or otherwise rethinking what you’re trying to do.” This doesn’t make much sense to me. HTML elements are about “meaning”, CSS about how they look. For instance, what would be wrong about setting an <a> element to “display:block” if you need a link and need it to show as a box (with width, height, margin, padding)?
Yes, that’s fine. That’s one of the ways that you would benefit from doing that. But with most tags, it’s probably the wrong choice. For example, it would be silly to insert a DIV element somewhere and make it “inline”. You might as well just use a SPAN or something else that’s already inline.
I like this post. Really very interesting notes. Thanks Louis.
Hi Louis,
Yes, the normally invisible <head> elements can get the block display to show them. It’s also used in my “(Not) Empty Content” page, which has all empty body elements, but is telling a small story in the right column on screen.
clba.nl/experiments/emptycontentpage.
Francky
Warning: while valid HTML and valid CSS, don’t use a Text Browser (Lynx) or a Screen Reader (Fangs) – and don’t disable css, for a better effect. ;-)
Here’s a list that you may want to add to your article:
{
“inline” : [“A”, “ABBR”, “ACRONYM”, “B”, “BDI”, “BDO”, “BIG”,
“BR”, “CANVAS”, “CITE”, “CODE”, “DD”, “DEL”, “DFN”,
“DIALOG”, “EM”, “EMBED”, “FONT”, “FRAME”, “I”, “IFRAME”,
“IMG”, “INPUT”, “INS”, “KBD”, “KEYGEN”, “LABEL”, “MAP”,
“MARK”, “MENUITEM”, “OBJECT”, “OUTPUT”, “PICTURE”, “Q”,
“S”, “SAMP”, “SMALL”, “SOURCE”, “SPAN”, “STRIKE”,
“STRONG”, “SUB”, “SUP”, “TEXTAREA”, “TIME”, “TRACK”,
“TT”, “U”, “VAR”, “VIDEO”, “WBR”],
“block” : [“ADDRESS”, “ARTICLE”, “ASIDE”, “BLOCKQUOTE”, “BODY”,
“CENTER”, “DETAILS”, “DIR”, “DIV”, “DL”, “DT”, “FIELDSET”,
“FIGCAPTION”, “FIGURE”, “FOOTER”, “FORM”, “FRAMESET”,
“H1”, “H2”, “H3”, “H4”, “H5”, “H6”, “HEADER”, “HR”, “HTML”,
“LEGEND”, “MAIN”, “MENU”, “NAV”, “OL”, “OPTGROUP”, “OPTION”,
“P”, “PRE”, “SECTION”, “SUMMARY”, “UL”],
“none” : [“AREA”, “AUDIO”, “BASE”, “BASEFONT”, “DATALIST”, “HEAD”,
“LINK”, “META”, “NOFRAMES”, “NOSCRIPT”, “PARAM”, “RP”,
“SCRIPT”, “STYLE”, “TITLE”],
“inline-block” : [“APPLET”, “BUTTON”, “METER”, “PROGRESS”, “SELECT”],
“list-item” : [“LI”],
“ruby-text” : [“RT”],
“ruby” : [“RUBY”],
“table” : [“TABLE”],
“table-row-group” : [“TBODY”],
“table-cell” : [“TD”, “TH”],
“table-footer-group”: [“TFOOT”],
“table-header-group”: [“THEAD”],
“table-row” : [“TR”],
“table-caption” : [“CAPTION”],
“table-column” : [“COL”],
“table-column-group”: [“COLGROUP”]
}