Whitespace blues

I think it was Eric Meyer who first coined this expression (or at least he did where I read it first), and I think it’s something that describes what I sometimes feel. Whitespace blues is the feeling you experience when HTML tags aren’t written next to each other, resulting in weird effects, margins etc.

Some code with whitespace:

	<img src="cool-image.png" />
		<li>Item one</li>
		<li>Item two</li>
		<li>Item three</li>

Above code can, in some cases/web browsers, generate extra margins and space in the displayed layout. Sometimes the only solution is to re-write it like this:

<div><img src="cool-image.png" /><ul><li>Item one</li>
<li>Item two</li><li>Item three</li></ul></div>

Sad but true. Personally, I dislike giving up on writing well-structured code just to get rid of strange whitespace. So is taking whitespace into consideration for web browsers really necessary? Or should whitespace only have any affect whatsoever within PRE tags?


  • Anne says:

    I think mixing both inline and block level elements within the same container is bad design, but nevertheless, I believe there are other ways to solve this. Putting the IMG element to 'display:block' works for example. (I haven't tested it though, but I believe it is correct.) For the LI elements you can set the container to inline for IE only by using '_display:inline' and there are more known workarounds. If you put up some test cases online to prove me wrong, I'll try to make some to counterproof that.

  • Tabris says:

    Doesn't <abbr title="Cascading Style Sheets, level 2">CSS2</abbr>'s <code>white-space</code> property (which applies to block-level elements) handle this?

  • Robert Nyman says:


    The code above wasn't the best example and not tested by me, it was just a way of showing the difference between whitespace in the code or not (imagine the containing DIV being floated to work as a column, then it would be ok to have the UL within it).

    Unfortunately, for the moment I don't have any example code that generates the behavior I'm talking about (but I'm sure one of my readers have an example for me, don't you??? *begging*).

    When it comes to using display:block for the image, sure, I usually do it like that. But in the cases where the image's height is less than 1em, I think it will show whitespace before the next element, and it has to be positioned using vertical-align. Or am I wrong here?


    I guess the whitespace property does it job correctly for block-level elements, I've only really used it to avoid line breaks within certain elements.

    But is the solution then to set every inline element that generates extra unwanted whitespace to display:block and use white-space for them (I don't know, I'm just raising the question)?


    What inspired me to this post, is that I read in one of Eric Meyer's books that sometimes the only solution to avoid whitespace bugs were to write all the <acronym title="HyperText Markup Language">HTML</acronym> together. Either Eric (yes, we're on a first-name basis ;-)) said so beacuse of lack of experience (which I doubt) or there actually are cases where whitespace problems can't be solved through <acronym title="Cascading Style Sheets">CSS</acronym>.

  • Tommy Olsson says:

    Whitspace text nodes in the DOM tree should be ignored by the user agent if all children of an element are block-level. IE gets this wrong sometimes.

    Something that trips beginners up is when they use <code>display:inline</code> on list elements to create a horizontal list. Since the children now generate inline boxes, the whitespace matters.

    A draft of the DOM (Core) Level 1 specification had an <code>isIgnorableWhitespace</code> attribute on <code>Text</code> nodes, but it didn't make it to the CR.

  • Robert Nyman says:


    Thanks! Interesting.

    But this then means that a DIV element with whitespace before its A and IMG children (who aren't set to display:block) will render differently than if those tags were written on the same line as the starting DIV?

    And if that's the case, that's what I'm talking about.

    This may result in long lines that are difficult to read, as opposed to writing the code in a nice hierarchical way with line breaks and intendation.

  • Tommy Olsson says:

    Browsers seem to ignore empty text nodes as the first children of block-level elements. I think that's the proper behaviour, but I haven't been able to locate anything about it in the W3C specs today.

    IE has some issues with list elements under certain circumstances, where it gets this wrong, but in a test document I just wrote with <code>div</code> elements containing a single <code>a</code> element, Mozilla and IE6 behaved identically (ignoring the whitespace node).

  • Tommy Olsson says:

    I found this in the HTML 4.01 specification:

    In order to avoid problems with SGML line break rules and inconsistencies among extant implementations, authors should not rely on user agents to render white space immediately after a start tag or immediately before an end tag.

    I can't find anything definitive about how user agents should handle leading or trailing whitespace-only text nodes, but it seems like contemporary don't render them, to allow authors to format their markup in a legible way.

  • Tommy Olsson says:

    Er … that should be "contemporary browsers".

  • Tommy Olsson says:

    Sorry for the comment spamming, but here's some more from Appendix B:

    SGML (see [ISO8879], section 7.6.1) specifies that a line break immediately following a start tag must be ignored, as must a line break immediately before an end tag. This applies to all HTML elements without exception.

    The examples given use <code>p</code> and <code>a</code> elements, to this behaviour is not limited to block-level children as I suggested in my first comment.

    I'll stop now. šŸ™‚

  • Robert Nyman says:


    You must be going on something! šŸ˜€

    I'm sitting out at a customer's, so it's good to have a bloodhound like you hunt for clues, when I can't!

    All of that seems correct and the way it should be, but I guess that <acronym title="Internet Explorer">IE</acronym> doesn't always fall under that category.

    I have nothing to back it up with, but I'm pretty sure that there are cases where <acronym title="Internet Explorer">IE</acronym>, especially version 5.x on PC, doesn't abide to above rules.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.