floatitis pt5/the future of inline-block
In this pre-final article on float prevention, I'll be digging into a method which though very interesting, has little practical value (yet). This of course does not mean people shouldn't be more aware of it, as there will be times ... far away times where ie6 will be nothing more than a long forgotten myth. And now's the time to get prepared.
what's inline-block?
Inline-block is a lesser known and somewhat poorly supported (that's where ie6 comes in) display property value. It's pretty interesting as it makes the element it's applied to behave like an inline element from the outside, but makes it behave like a block element from the inside.
Practically speaking this means that when, for example, applied to li elements within a ul element, all li elements will behave like they were set inline, placing themselves next to each other while also maintaining the same baseline for the content. Something which is pretty much impossible to achieve using floats.
But at the same time, the li elements can be given widths, heights, paddings and margins in all directions. That's where the block part comes in. It's actually the best of two worlds.
the float alternative
.paging ul {text-align:center;}
.paging ul li {display:inline-block; white-space:nowrap;}
The inline-block display value comes quite in handy when all elements within a parent are otherwise floated in the same direction. Typically, this method is very suitable for styling horizontal (navigation) lists, as can be seen in the example above. All you need to do is make sure the element itself won't wrap to the next line (something inline elements do), which is easily done by adding the nowrap value.
In the example above, all li elemets within the paging container will be set to display-inline so they will all align to the same baseline. One
added benefit is the fact that inline elements can be centered through their parent container. A mere text-align:center
suffices to mimic the often begged for float:center behavior.
not all is well
Sadly, this method has a few drawbacks too, most notably the lack of support in ie6. You can use this method in all modern browsers, but you'll
still need to revert to alternative methods when dealing with ie6. In some cases a mere display:inline will
suffice though, as long as the block behavior of the element is of no further use. Otherwise, it's back to floating in ie6, defeating the purpose
of this method.
Still, there's a more irritating problem. Inline behavior is partly influenced by the source html itself, in the way that all spaces between elements in the source are converted to one single space in the page. This becomes a problem when you're stacking li elements underneath each other, as a space will be added between each element in the page. Not something you want when all elements should be aligning right next to each other.
<li>...</li><
li>...</li><
Only solution I've found so far is to stitch these elements together in the html source. A very dirty way of writing html which I don't and won't support, but that's a decision everyone needs to make for himself. Apart from that, little experiments with the css word-spacing property amounted to very little. If anyone has any bright ideas to solve this problem, be sure to let me know.
conclusion
While there's a lot of potential here, this method can still only be used in controlled circumstances. Only when ie6 does not matter, or when a display:inline will suffice in ie6 is this method of any use. Even then there could arise some problems with added spaces between the elements.
Next time I'll be closing off with a little recap of what we've ran through and a quick look at what the future will bring us to counter the abuse of floats. So stay tuned.
Inline-block does indeed work in IE6, you just need to trigger hasLayout and set display:inline instead, see http://www.brunildo.org/test/InlineBlockLayout.html. You can even use a selector hack to achieve it:
ul.nav li { display: inline-block; white-space: no-wrap; } /* enough to work in FF, IE8, Sa, etc. and will trigger hasLayout in IE6 & IE7 */
:first-child+html ul.nav li { display: inline } / this will get applied in IE7 only to trigger inline-block behavior */
I thought it was interesting that you picked on IE6 in this article too when a more obvious candidate for attention is Firefox prior to version 3 which doesn't support it at all without a -moz vendor-specific extension.
And a better way to write:
<li>...</li>< li>...</li><is:
<li>...</li><!-- --><li>...</li>(Mmm, can't work out how to get the line break in there. :/ )
Thanks for the heads up Damian and John. Interesting stuff there.
All too right, I tend to do that a little too often. I'm still not used to supporting multiple browser versions besides IE I guess :)
Hey underdog, just checking your blog, stuff still looks good! Greets back there
You can write your lists more cleanly this way:
The use of -moz-inline-box is straightforward, its behavior is consistent, it doesn't cause a bunch of other bugs to crop up, and it just generally - you know - works.
It's not some crazy thing that seems like it's going to work one way, but then once I try to use it I notice some pointless discrepancy in implementation or that a bunch of other seemingly unrelated properties have to be set some random way for it work. There's a specific shortcoming, and Mozilla fixed it.
IE's problems, on the other hand, are the result of attempts to implement de facto standards, piled on top of cover-ups, piled on top of a backwards compatibility nightmare, piled on top of the underhanded decision to throw a monopoly around to create artificial dependencies on MS products, piled on top of an utterly adversarial attitude towards the web in general. It's not just one problem, the entire project is garbage, and the lock-in factor is the only reason Microsoft even bothers.
So yeah, if you want to make sure everyone knows that you are, indeed, an M$ drone, make an earnest attempt to convince people that IE isn't clearly the worst browser in use. Every single time I write css for a site, it looks exactly the same in every single modern browser but effing one. It's not "Microsoft hate," it's just an empirically-backed fact of life that Internet Explorer makes web development twice as tedious as it needs to be.
So in summary: firefox's "bug" - straightforward problem with a simple solution. microsofts bugs - convoluted mound of crap where the only solution is trial and error.
Any questions?
* required fields