I'm making the layout for a new site. I simply want a horizontally centered trunk container, with in it the navigation menu div and the article div side by side. Inspired by http://www.sitepoint.com/give-floats-the-flick-in-css-layouts/, I thought I'd use inline-block for the two (child) divs, for a change. Only to see a behavior -- from IE8 to Chrome35 -- that I can't get my head around.
Here is the bare-bones demo, consisting of this code:
<title>Demo Behavior inline-block</title>
border: 1px solid black;
<div id="trunkContainer"><div id="navMenuDiv"></div><div id="articleDiv">ABC</div></div>
I made the divs code one line, to eliminate the influence of spaces, tabs and hard returns in the code.
Just remove the ABC, or move it from the articleDiv to the navMenuDiv, and see that the positioning of inline-block elements is strongly -- I'd say freakishly -- content-dependent. My first question is: Why such behavior? I looked up the W3C specifications, which say: "(Inline-block) causes an element to generate an inline-level block container. The inside of an inline-block is formatted as a block box, and the element itself is formatted as an atomic inline-level box." But that doesn't make it any clearer for me.
My second, and more important question is: Does this mean that to get two block-level elements with different content types side by side there are still only two options: floating and absolute positioning, in this case relative-absolute positioning (relative to the trunkContainer)? Because only if the two (child) divs in this example contain the same type of content, are they positioned side by side.