inline-block vs float
With display:inline-block finally ready for everyday use across the most popular browsers (in all honesty, it has been for a while now), I quickly hit a pretty big dilemma. When comparing inline-block to floats, it wasn't immediately clear what the exact differences were and what method to prefer. I looked online but couldn't find a source listing the difference between the two. Guess that's a good reason for keeping a blog then.
Note that inline-block still needs fixes in IE6 and IE7 (more about that later this week) and isn't supported in FireFox versions prior to FF3. There is a -moz fix if you still want to support these browsers though. Apart from those (easy to fix) issues, you can play around with it all you like.
looking alike
At first sight inline-block and float (left) look incredibly alike, and in a fair few situations both statements can be used to accomplish the same visual effect. Both statements are used to create a horizontal flow rather than the standard vertical flow. A popular design element for navigation, image lists, product lists and a whole range of other commonly used web patterns. That's where the confusion started for me, as randomly choosing a method isn't really my kind of thing.
The inline-block value was created to give an element two different faces. Its parent will treat it as an inline element, with all the typical inline properties. But the element itself considers itself a block element, meaning it can have widths, heights, paddings, margins and all other popular properties of block elements.
Finding the differences
As much as they seem to have in common, once you start looking at the finer points it becomes clear that both methods can be used to different effect and both have their own set of use cases. Below is a list of the most visible and useful differences, allowing you to make a weighted decision when confronted with the choice.
1. horizontal positioning
Horizontal positioning is probably the most important difference, or at least the one I needed the most. Parents can position inline-block children using the text-align property. This means you can actually center a block-property container without knowing its horizontal dimensions. A typical example is that of pagination that needs to be centered, no matter how many pages are displayed. This was pretty much impossible if you wanted to apply fancy styling (not just some text links). Another thing you can do is align all children in normal source order to the right of the container, previously impossible for more complex elements (unless you added a couple of extra floats + wrapper).
Floats can't be centered, let alone be controlled by their parent. Left-floated elements do behave pretty much like normal inline-block elements, but right-floated elements will change order. The first element will be at the far right, the second element will hug the left side of the first element, etc etc. This can be useful behavior, but it's not always wanted. A clearer advantage of floats is that you can float children in separate directions without directly influencing any of its peers. In our pagination example, the 'previous' link can be floated to the far left, the 'next' link can be floated to the far right, while leaving the number navigation centered. You can't do that with inline-block elements.
2. to flow or not to flow
Inline-block elements aren't taken out of the flow. This means that you won't need any clearing nonsense on the parent. No clearfix class, no abuse of overflow:hidden or any other ugly trick to make the parent semi-aware of its children. Quite lovely indeed.
Floats are taken out of the document flow. Even though this has caused us a lot of trouble, it is there for a very simple reason, allowing us to float text around an image (the original intent of the float). Related to this is the ability to clear floats. You can force elements to the next visual line, something which can't be done when using inline-block elements. One thing I thought of was using the ::after pseudo-element in combination with a line feed to force the following elements down, but no luck so far. Haven't been able to get anything in the content property that doesn't come out as simple text.
ul li:nth-child(3n)::after {content:"--fake enter--";} 3. the baseline
Inline-block elements are positioned against the baseline of the text. This means you have way more vertical control. Additionally, when an element breaks to the next line it will never "hang" behind any of the previous elements but will always start at the left-most side of its parent. In some cases this will remove the need of a "row wrapper". It's interesting behavior which has some unforeseen advantages, but more about that in one of the following articles.
Floats will always align at the top, but can be made to hang behind a previous float. When a list of floats reaches the right side or the parent, the next element will either hit the left-most side or the right side of a previous float sticking out at the bottom. Once again, this can be useful in some particular cases, so it really depends on the situation what you would be using.
4. white-space
The biggest down-side of inline-block elements is that they take into account html white-space just like other inline elements do. I still haven't found a good way to eliminate this yet through css, of course you can always use the old html trick to do this, but clean it ain't. Floats don't have this problem at all, which could be a strong factor in choosing which method to apply.
conclusion
Seeing all the differences, there are quite a few differences than can help you decide what method to use in a particular case. If you want control over alignment, inline-block is usually the best option, but if you want more control over individual elements then floats are still preferred.
Then there will still be situations where both methods will yield the same result. For now I guess I'll go with the inline-block method, if only to learn more about the ins and outs of this display value. I'm sure there are more differences, be sure to list them if you think I've forgotten something.
Later this week there will be more info about inline-block in IE, after that there will at least be one more article revealing a pretty interesting technique using inline-block. So stay tuned.