Give Floats the Flick in CSS Layouts

If you’re new to CSS layouts, you’d be forgiven for thinking that using CSS floats in imaginative ways is the height of skill. If you have consumed as many CSS layout tutorials as you can find, you might suppose that mastering floats is a rite of passage. You’ll be dazzled by the ingenuity, astounded by the complexity, and you’ll gain a sense of achievement when you finally understand how floats work.

This is a sign that the CSS author is a follower of the one true layout; a believer in the magic of floats. Followers believe they’ve found the only layout technique they’ll ever need. Enshrined into CSS frameworks everywhere, using one of these is equivalent to deciding that you’ll never need to learn another CSS layout technique.

The truth is using floats for layout was the best kludge anyone could come up with six years ago with the limited CSS support available at the time. Here we are in 2011, browser CSS capabilities are leaping ahead and the floating crowd are still coding CSS like it’s 2005. Floated layouts are strangling CSS innovation.

The bugbear of floated layouts is the need to clear floats. When you have a stack of floated elements they are taken out of the document flow, and their container element collapses. If you want that container to properly surround its floating children (I call them floaters) you’ll need to clear those floats.

The methods for doing this are varied and depend upon the specific layout requirements. If you have a group of floaters within a containing element, and you need that element to extend to full height, then float the container too. The most popular technique, however, is to apply a clearfix: add an element that will refuse to yield to the floaters.

The original clearfix was to add a block element after all the floaters with the rule clear: both; like so:

<div></div>
.clearfix { clear: both; }

The need to add structural markup for no real semantic purpose was annoying enough to inspire people to seek another solution.

You simply add the class clearfix to your container element and let the magic happen. It’s so progressive, it’s even included in the HTML5 Boilerplate project.

I find it more than a little ironic that the only browsers that support this method—that support the :before and :after pseudo elements and generated content—support almost all of the CSS2.1 spec (plus some of the CSS3 spec) and so have no need for kludges like floated layouts anyway. We’re talking about IE8-and-above-level browsers here.

The Real Problem

We’ve had a decade where the only choices for layout have been inline or block display, and floated or absolute positioning. Creating a layout is really the combination of many small, simple layout tasks. These tasks have often been made needlessly complex by using floats to position elements. The ingenuity required to solve this introduced complexity has become a benchmark for CSS prowess.

Why not stop using floats and remove the complexity instead?

Here’s a collection of CSS properties and values that have been avoided in the past due to boring compatibility issues, but are now widely enough supported that we can begin to use them in our CSS layouts. There are no floats in any of these examples and I hope by exploring the possibilities I might convince you to stop and think before automatically reaching for your toolkit of float-based kludges.

Display: inline-block;

Inline-block is a value for the display property that lets you consistently apply properties like margins, padding, width, height, and vertical-align while remaining an inline element. It’s incredibly useful in any situation where you want to align block elements horizontally in rows.

A mainstay of blogs everywhere is the use of an unordered list for the navigation menu. Turning that list horizontal would normally require you to float all the menu items left or right, then deal with the height of the containing element, and any clearing problems. All of these problems are nullified by applying display: inline-block; to all the li elements. If you want to make the anchor elements fill up the space, apply display: block; to them.

You may have spotted the fact that the list marker is no longer visible. That’s because list items have a display value of list-item by default; changing the display value has also removed the list marker.

The inline-block elements will also respond to the vertical-align property. So if you have elements of differing dimensions you can create different effects like so:

The top menu uses vertical-align: middle; and the bottom menu uses vertical-align: bottom;.

Here’s another example that uses inline-block to create a 2D grid of elements. What I like about using inline-block in this way is that the elements wrap so nicely for different browser widths. Once again the HTML and CSS are simple:

With the addition of some cosmetic styles and appropriate widths the effect is complete:

If you use media queries you can make sure that the containing element width is set to an optimal value to avoid any orphans on the last row. It’s just like laying tiles. Check out the example in the code archive if you’d like to see this in action.

Inline-block is also helpful with form presentation. It’s a great way to apply a consistent width to your labels without using structural markup:

If you apply display: inline-block; to multiple fieldset elements you can align them horizontally, like so:

Box-sizing: border-box

Box-sizing is actually a CSS3 property, but is supported by all browsers except IE6 and 7. By applying a box-sizing value of border-box to a block element, the browser will include the padding and border widths into the total width of the element; shrinking the content space in the process. This is exactly how IE5 used to work. The problem with the now-standard way of calculating element width—the sum of the element width, padding, border width, and margin—is that you can’t specify a width of 100% and then apply padding or borders because that would increase the element width past 100%. Box-sizing: border-box; is the answer.

You can happily apply a width of 100% to an element (or the widths of two or more adjacent elements that total 100%) and also add padding and borders without worrying that the elements will grow past 100%. Very handy for fluid layouts.

An important note: depending on the browser version you may need to use the vendor-specific prefixes -moz-box-sizing for Gecko-based browsers, and -webkit-box-sizing for webkit-based browsers. Firefox 3.6 and Chrome 10 appear to support the property without the vendor prefix but Safari 5 still needs it.

Min-height

Here’s a common layout situation: two columns; one for the main content and one for complementary content. The HTML might look like this:

The content column is full width, but we add extra margin on the left hand side to accommodate the menu. The menu is then positioned using absolute or fixed positioning. In the past the main drawback of this method was when the complementary column was longer than the main column.

Because the complementary column is positioned absolutely it’s out of the document flow and the container element will collapse to the height of the shorter content column. In these times of widespread compatibility for the min-height property, we can easily avoid this problem and apply a min-height value on the containing element; enough to make sure it surround the complementary column.

Here’s the result:

If you want the column on the other side, no need to adjust the markup, just adjust the CSS values.

Other CSS properties that are useful for layout, but have traditionally been avoided include position: fixed;, max-width, min-width, and max-height. You should take another look at these properties as well because browser support is extensive these days.

For example, if you choose fixed positioning for the complementary column, it’ll stay fixed to the viewport, while the rest of the page scrolls. You can see this effect on simplebits.com.

Display: table

With the arrival of IE8 all browsers support table-related value for the display property. This allows us to apply the layout behavior of tables, rows and cells to any HTML elements. For alignment into columns or rows, these display values are the quick and easy solution.

There’s often quick resistance to anything table-related mentioned in the same breath as CSS layouts. In fact some web professionals are so outraged at the suggestion of using display: table;, you’d think we’re killing kittens.

Table-based display values are unrelated to using HTML-tables for layout. The debates have come and gone. They’re boring now. Let’s move on.

All the previous examples using display: inline-block; can also be achieved using display: table; and related values. Here’s our navigation menu again, but this time each menu item is displaying like a table cell instead of an inline-block.

The HTML is the same and the CSS only requires a couple of simple changes:

You might notice that there’s no element playing the part of the table row. There’s no need: browsers makeup the missing parts of the table structure using anonymous elements. You might also notice that because we’re applying the table display behavior to the ul element, we can also apply table-related style properties like border-spacing.

Our new menu bar has one big behavior difference to its inline-block-based cousin. Because it acts like a table with a single row, those menu items no longer wrap. Instead, if the browser window becomes narrower, they’ll bunch up—each cell’s width will be reduced just like a HTML table. It’s worth keeping in mind when choosing your layout method; sometimes you may want elements to wrap, sometimes not. The choice is yours.

If we want to make a fixed, equidistant grid of elements, CSS tables come to the rescue. This is a modification to the previous grid example, except this time we’ll need to adjust the HTML. We’ll use multiple ul elements and each one will become a table row:

Equal height columns, without the need to specify a min-height value, with a minimum of fuss. Of course to adjust the position of the complementary column we’d have to change the order in the HTML source. It’s a slight downside you have to consider when choosing to use display: table;.

Equal height columns is particularly useful when you want to include vertical borders between columns. Using display: table; has an added bonus in this situation: the border-collapse property. Take, for example, a typical three column footer you might find on a WordPress-powered site:

Defenders of the floated layout are quick to point out the strengths of their technique. Here are the often cited benefits:

Source Order Independence

As I mentioned above, dependence upon HTML source order for the columns when using display: table; is a common criticism. But I question the implication that floated layouts are indeed independent of source order, the belief that they are the only way to achieve source order independence, and the notion that source order independence is even important.

First let’s clarify something: pure CSS layouts are pure fiction. All current CSS layout methods rely on the document flow to some extent. CSS lacks a way to describe a layout that is completely independent of the order of the markup, although it may gain one in the near future.

Claims of source order independence usually only mean that you can reorder columns. With a simple CSS change left becomes right and right becomes left. Headers, footers and the content within columns are usually still in display order. But, how often is this column-switching ability put to real use? This ability is only possible in specific circumstances and the markup and CSS have to be constructed with this ability in mind. If this ability is actually required for a specific reason, it may be worth all the trouble. If you only use it to prove that it can be done, then is all the added complexity and brittleness worth a slight decrease in source order dependence?

The only real way to position elements without regard to source order is to use the position values fixed or absolute. The min-height layout demo above is an example. Also, if you use display: inline-block; to horizontally align block elements, you can use a combination of positive and negative margin values to reorder the elements visually without changing the source order.

If you remain unconvinced that the source order issue is a red herring, consider that, as this 465 Berea St article points out, the Web Content Accessibility Guidelines clearly recommend that HTML source order should match the display order. Consider also that the rise of HTML5 makes the source order issue a moot point. HTML5 provides explicitly semantic elements. The order in which you place them in the source will make no difference to the indexing of your content. The article element will contain the article content, the header element will contain the header content, and the aside element will contain the complementary content.

Browser Compatibility

IE 6 and 7 compatibility are frequently used as a yoke to reign in unbridled enthusiasm for new layout techniques. If you’re still clinging to the idea that one stylesheet should work everywhere, on all browsers, the concept of responsive design should destroy that notion for good. With so many web-enabled devices you need to customize the experience for these devices anyway.

With the release of IE9 it’s time to put these old clunkers out to pasture. Treat IE6 and 7 like the least capable mobile devices and use conditional comments to provide a minimal experience. If you’re using the advanced clearfix rule I mentioned at the beginning of this article, but lack an alternative stylesheet for IE6 and 7, you’re already ignoring the browser compatibility issue.

There’ll Always be Floats

Of course floats are useful in some situations. There will always be a need to float an element so that other page content flows around it. There’s just no need to always press them into the service of a complicated layout.

Is That It?

You might be thinking “Is that it? It seems very simple and obvious.” I agree! That’s the whole point. The floating crowd would have you believe that the only way to build advanced CSS layouts is through complicated stacks of floated elements. That’s not true any more. We now have a stack of easy-to-use properties available. Combine some or all of the above methods into a single layout and you’ll be able to do whatever you want without floats.

I watch my kids play Little Big Planet 2, and see them create their own worlds from scratch. I want them to see the web in the same way: like a playground. When layouts are simple to create, making tools that generate CSS layouts will be easy too. People will no longer need to code by hand.

Browsers have come leaps and bounds since the bad old days. Spurred on by the adoption of Ajax and now HTML5 and CSS3, browser makers are working harder than ever. We have to keep this momentum going, use the new technology as much as possible. These experiences give people a reason to upgrade their browsers, browser-makers a reason to keep developing, and tool-makers a reason to create better, easier-to-use tools. We have to explore the boundaries, develop new techniques, and boot those old, cherished layout recipes out the door. They’re holding us back.

The Future

CSS3 layout is set to provide far more exciting layout controls. But, we’ll have to wait a few more years before these standards have widespread support. To me it feels as if a large segment of the web industry is standing still, waiting around until CSS3 layout standards are fully supported. Why wait? Much easier layout methods are available right now.

All the source code for the examples in this article is available on GitHub.

Free JavaScript: Novice to Ninja Sample

Get a free 32-page chapter of JavaScript: Novice to Ninja and receive updates on exclusive offers from SitePoint.

Stormrider

Excellent article, lots of good techniques to put into practice here!

hook_world_alter

I think the approaches here are really interesting, particularly the ones that use the table-related styles. Could you comment about why you think these styles are appropriate outside of table markup? My initial thought is that we’re keeping the markup semantically correct, but we’re kludging a bit here on the CSS (although less so than current practice). Just wanted to see if you’d thought about that.

Andrew Tetlaw

Hi hook_world_alter,

Not sure what point your making here. We don’t worry about making a block element display:inline or an inline element display:block, which is equivalent IMHO. Without any real way to describe layout in CSS we make do with what we have available.

Stormrider

There is a difference between HTML tables and CSS tables. HTML is there to give the semantics to the content, and tell it what part of the document represents what, so you wouldn’t want to abuse the table element for layout purposes, and instead keep it for tabular data.

In the CSS however, all you are specifying is that you would like the elements to display as though they were a table – but that doesn’t turn them into one. It doesn’t affect the semantics at all, and the css display property doesn’t ‘add’ semantics just because you specify it should lay out like a table, so it is perfectly fine to use this.

ServerStorm

Yes agreed, excellent article. A tonne of ways to use these techniques and they really do simplify… awsome!

revsorg

You say no kittens were harmed but I suspect you may have hurt their feelings.

powerpotatoe

Great info. I do not like using floats for many of the reasons stated. I will reference this article on new projects. Thanks.

Aaron

I still love floats, but I will try this approach too. Aaron age 14.

John

Very persuasive article, look forward to using these techniques in the future

Emil

Flexbox please!

Andrew Tetlaw

I agree! It looks great.

rubiii

just wanted to say that i really enjoyed reading your article!

Andrew Tetlaw

Thanks!

kaf

Oh no! Not another cat person!

In all seriousness tho, this technique can’t really be used at the moment because of IE7 incompatibility. It would be nice. But it just can’t happen. All clients use IE7. Especially when your code assumes they don’t. Thats when they really like to make sure that they only use IE7 and they think that because they do, everyone else must as well and they won’t take no for an answer.

Also it has a really annoying bugbear which is if I want my elements to be right next to each other I would need to have the markup all on one line! Browsers translate a newline to 4 pixles of annoying space for inline elements!

stevo

All good and well if you have decided you don’t need to design for ie6 and 7, but here in the real world that is still unfortunately very necessary.

Andrew Tetlaw

No one’s suggesting ignoring IE6 & 7, it’s just that you need to decide that it’s doesn’t have to look the same in IE 6 through 9, which is a silly proposition.

Sean Rice

I’m okay with things looking different in older browsers as you suggest, however in this case things will look *broken* in those browsers because of incompatibility.

…that is unless you decide to write special stylesheets for those browsers that use floats to emulate inline-block. But that may require some additional junk in your markup (not to mention several extraneous stylesheets) to get it to work right… and then we’re back at square one.

Appreciate the article though. It’ll be nice when I can use this in 10 years.

Andrew Tetlaw

Sean, getting inline-block working in IE6 & 7 is trivial and doesn’t require floats either, as others have explained already in this thread.

Do you really want to keep using the same old techniques for the next 10 years? That’s paralysis. The world is moving on.

John Faulds

I think you could’ve pointed out that the inline-block method can at least be made to work in IE6&7 with a few additional rules.

@Silver Firelfy: Using inline-block can often solve a lot of problems that using floats creates. Sure, you could move the invalid lines to an IE-only stylesheet served up by conditional comments, but my approach is to use as few stylesheets as possible to save on the number of http requests.

But validation is a tool and not the be all and end all. If you know why your code is invalid and you’ve tested adequately in all your target browsers, then I don’t see any problem in using it.

noonnope

Finally, an article sensing the change in the Force lately. ;)

I’ve been given some bashing on SPF for being open minded about not using floats for layout.

You did a better job that me saying that there is life outside floats. I totally agree we should look not at the common denominator when implementing CSS. We should look at the advance CSS part that’s most common for most UAs, and downgrade with CC for IE. Another thing I took some bashing for on SPF.

display: inline-block shows gaps between list items in this example (based on font size since gap is like space). And there is a lot other issues.

But I like that thing with vertical align, thats useful, thanks for advice

Anonymous

Quality article! Nothing was new to me, but it’s the first time I’ve seen such observations written out in such a well thought out manner.

Web design these days is getting much less frustrating than it use to be. I wasn’t even designing website’s in the really bad ol’ days; I came in at around the time IE5 usage was rapidly decreasing, so IE6 is basically the worst browser I’ve had to design for.

Just a tip on the inline-block technique. I use inline-block’s all the time, and they work in everything except IE6 (IE7 needs a little bit of a hack, but it works as you’d expect once the relatively simple hack is implemented). One got’ya though which I encounter regularly, is that inline-blocks are treated as any other inline element, which means spaces between inline blocks are respected. You can see this in your horizontal menu example. All the menu items have white-space between them. The only reliable way to currently remedy this is to get rid of any space between inline elements, which means you’re going to have to reformat the source code (either put it one long line, or wrap the whitespace in HTML comments). The CSS3 property white-space-collapsing property does hold promise however: http://www.w3.org/TR/2011/WD-css3-text-20110215/#white-space-collapsing. Though sadly, not even IE9 supports this one.

HTML/CSS has improved a crap load in the past few years, but it’s still a bit of a dog. I’m still convinced that a whole re-think will need to happen in the not too distant future. HTML/CSS and web applications are an awkward match. HTML and CSS have received new features to help accomodate web applications, but it’s still awkward. It’s awkward because HTML and CSS are still document oriented markup languages, and web applications are becoming less and less document-like.

isMe

Since no one has mentioned them yet, but they are useful for this article…

I’ve been reading this article off and on this morning and just now realized Andrew was CSSing a site that sells baby cats as food/pelt products. Nice touch and very informative tech article too. =)

TheRealWorld

At the moment (2/24/2011), this doesn’t make sense.

“Treat IE6 and 7 like the least capable mobile devices and use conditional comments to provide a minimal experience.”

Perhaps when IE7 is considered a legacy browser you can say it. To that, if you were to say this to me in an interview I would say “NEXT!”

Andrew Tetlaw

It makes perfect sense. IE7 _is_ a legacy browser. If you gave clients the option: pay for me to create the most progressive modern experience possible for the overwhelming majority of visitors, or pay for me to ham-string the experience and make sure that it looks the same for the small percentage of users using a legacy browser. OR I can make sure that users of IE6&7 can still access your content in a clean and attractive layout, but not focus to much of my attention to those browsers.

ServerStorm

Yup, Like you said earlier, we developers have to stop thinking/promising/influencing our customers to have the site “look the same” in IE6 and IE7 and provide a good experience for them but allow us to flourish with more modern capable browsers.

In my experience customer with the right information are open to differences in rendering if earlier versions of IE can be supported. In fact, these days more customers are asking for iPhone support.

TheRealWorld

I just took a look at the usage share of web browsers, here is the link:

I will agree with you that IE 6 is legacy, but IE7? The numbers are still not low enough to say that. If you have some numbers to back what you say then post them.

With regard to options, I wish I had the option to do what I want, but the world is not made that way. The real truth is that the client wants EVERYTHING, and if you can’t deliver that then that is fine, we will live with your LIMITATIONS.

IE7 has LESS market share than IE6. It often barely makes 10%. IE7 is now more than 5 years old.

Avangelist

business world ignorance I am afraid.

You’ve made the cardinal mistake of most web designers.

The business world runs on Windows XP SP2 and Internet Explorer 7.

It will be another 10 years before that is obsolete.

Anyone who has been working in offices for more than 10 years knows this already.

IE7 is far from a legacy browser it is actually the market shareholder not even close to being legacy.

Andrew Tetlaw

Avangelist,

Are you seriously saying that we should avoid doing anything that is not IE7 compatable for the next 10 years?

That’s just a crazy position to take.

It ignores the need to examine your target market and it ignores the potential of building the best experiences for all your users.

It also ignores the change that is happening everywhere: the rise of smart phones, tablets and other devices within the enterprise, and the transformation of ICT into ICT as a service.

If you think things are going to remain stable in the world of ICT for the next 10 years you’re dreaming.

Jordan

Many big businesses are extremely unwilling to drop IE6, and their managers *will* complain if your sites don’t work in that browsers. Our biggest clients (by which I mean, in the range of £1–£10 billion turnover—not huge, but substantial) universally use IE6 beyond the confines of their IT departments, although one of the smaller ones has been rolling out updates for a while.
Simple, elegant code gets torn to shreds if “the corners are all square” in IE6. Their technical staff are perfectly sympathetic, but the PM whose eyes are currently blazing into your “gracefully degraded” UI couldn’t care less if you use tables and font tags, so long as it looks at least 99% the same as the mocks.
Big clients want to know that the 15% of their customers using an older browser (not to mention every single one of their employees) are going to enjoy the experience, and don’t feel like they’re getting the “lo-fi” version because their clever nephew hasn’t bothered to update their browser in the past three years, or their IT people are terrified by the prospect of testing their whole intranet on a new browser when it already works fine, not to mention planning a roll-out across several hundred branches and retraining tech support for the new browser.
Web developers absolutely should encourage people to look forwards instead of backwards, and it is our sad duty to educate managers to understand and expect things to look or work a little differently in their ten-year-old browser compared to one released last week. But Newton’s laws of motion apply: mass is essentially inertia, so the bigger it is, the more force you need to apply to move it even a little. If you want to win big clients with the attitude that old browsers don’t matter, either they’re already in motion or you better be an irresistible force—and stars above, I am not. I want that contract and am damn well prepared to write conditional stylesheets for Old Nick himself to get it.

Andrew Tetlaw

Jordan, I feel your frustration and I’m happy for you that you found an outlet to vent about your situation. But this article is not going to fix your problem, and niether will jumping on every article that explains modern layout techniques with the opinion that if it doesn’t work in IE6 or 7 then it’s pointless to even discuss it.

Your response is one massive tangle of problems that is difficult to unravel, but I suspect that some of the answers have nothing to do with code and more to do with expectation management, project methodologies and so on. But I know nothing about your specific situation and you said it yourself that your prepared to do anything to keep the contract, including supporting the demand that legacy browsers have equal footing.

I’m interested to know how do these project managers approach mobile browsers?

Jordan

I’m not looking for catharsis, nor am I opining that there is no point discussing techniques that don’t work in IE 6/7. I’m not clear how you decided that either of those were my aim. I’m just responding to the suggestion that you can treat IE 6/7 like “least capable mobile [browsers]” and “provide a minimal experience,” or that this is justified by the idea that you must “ham-string” the experience otherwise.

Granted, visitors from mobile browsers are becoming more common, but few sites have anything close to 15% of their traffic for all mobile browsers combined, let alone the “least capable” devices. Many do see this sort of traffic for IE 6/7, however.

I’ve been using inline-block to lay out product pages for a couple of years myself, with the requisite conditional comments to make it also work pleasantly in older versions of IE. I don’t have a problem with using intelligent techniques or advocating to clients that , I’m just disputing the wisdom of treating IE 6/7 dismissively, which Yahoo! still consider to be A-grade browsers (i.e. bugs are treated with high priority), as do our larger clients’ own web development guidelines.

Andrew Tetlaw

Jordan, just for accuracy, Yahoo only considers them A grade on Windows XP.

I wonder if clients would feel differently if they knew exactly how much it costs in time and money to support legacy browsers used by a small fraction of visitors with not long to go before they’re extinct.

http://www.brothercake.com/ James Edwards

These are good ideas, but why is it either/or? inline-block is a useful trick; so it table display; so is float. All of them have their advantages, and all have their drawbacks (technical limitations, behavioral implications, browser problems …)

Don’t throw away floats — floats are useful. But do take these new ideas on board as well.

Andrew Tetlaw

James, I agree. I think I said that above (“there will always be floats”). But I’m intentionally heavy handed because I think the idea that floated layouts are the be all and end all of CSS is pervasive.

As a side note, I agree with TheRealWorld, our job is not to “educate” users, but to give them the best experience possible (at a reasonable cost) in whatever device they choose to access documents we author.

noonnope

I’ve found a thread of mine since Oct.2010 saying the same thing:

“ok. so i’m trying to see if divs set as inline-block elements based layout can (sometimes) be a replacement for a floats layout.”

There’s been so much effort put into exploring how to use floats for layout; it’s great to see effort being placed into other methods.

Michael Hall

I don’t design for the masses since i’m a freelancer, but if i did have to support the old browsers i thought the conventional way to do so is to use conditional comments to load a seperate stylesheet for the older browsers instead of trying to put it all into one stylesheet – but i suppose the html or xhtml source code might interfere in some way.

i really liked this article and will have to look more into the techniques.

mmj

According to quirksmode, inline-block should work fine on IE6 and IE7 if you use it on a span instead of a div.

Surely it can’t be as simple as that?

Andrew Tetlaw

mmj, yeah apparently in IE6 & you can only apply inline-block to elements that are inline by default. But it apears that you can apply inline to block elements in IE6 & 7 and they act just like inline-block has been applied anyway. Someone correct me if I’m wrong.

Dawson

You’re not wrong…

My issues with inline-block (applied to a div) came when trying to use .my_div {text-align: justify} <–works awesome in non IE browsers to create a grid in a fluid layout. IE6/7, of course displayed .mydiv(s) as a single column.

My solution was an IE6/7 specific CSS file where display:inline-block became display:inline….text-align:center, which as you can guess does not look the same, but it was a decent compromise.

Thanks for the article. Nice read.

Louis Simoneau

Yeah, that’s correct. I recently encountered this issue trying to use inline-block on list items for a nav menu—IE7 doesn’t apply inline-block as they’re block-level by default

Andrew Armitage

Gotta say I’m really suprised and to an extent disappointed by the viewpoints from some of the comments about that this article is 10 years ahead of its time and doesn’t contain anything that can be applied practically today.
Aside from the statistics, IE7 is an old browser and it’s up to us in the industry to drive people beyond it and into using more up to date software. I’ve heard and appreciate all the arguments about corporations and companies stuck on XP, but if we keep making such strong points about working with old browsers, that adds to the arguments for sticking with them!
This is a great article with some new techniques which is what we should all be working with. The web is a fluid medium and will always change. In 10 years do you think they’ll be nothing else new and we’ll all be up to date? Not likely, we’ll have moved on again and there will still be web designers working 10 years in the past.
Lets embrace the new ideas and features CSS3 gives us and work for the majority, not the minority (although there will always be special circumstances). Together we can push our audiences into better browsers!

Andrew Tetlaw

Andrew Armitage,

Right on brother!

Robin

MS is no longer supporting IE6,7 or even WinXP! Companies that force their employees to stay on those outdated systems are only doing so until they have to buy new hardware – which will then be loaded with newer OS and browser software. Time to wake up and smell the change people – if you don’t learn to develop for newer technologies (CSS3, HTML5, mobile) then you may find yourself stuck in a place where all you do is fix legacy websites for companies that didn’t adopt and fell behind… (ie; Hell)

Interesting article but I believe that telling people they can “flick” using floats is very misleading. I’m too busy to rant right now but I’ll leave you with this; If you dont care to make your website accessible to a large portion of the web and you dont work for a large corporation… then perhaps this is good advice. What will really help you is to learn how to use floats and positioning properly, in combination with some of your suggestions. You can go over to the W3 to read more about that.

SK

This may be the most blatantly practical article I have ever read on modern use of the display property. Why are modern display types not discussed more prominently… even HTML5 and CSS3 For The Real World doesn’t even touch on most of these techniques. Bring on more of this progressive thinking, love it!!

AnilG

I’ve been wondering about display:table-cell for some time now. Thanks very much to Andrew for making it clear that it’s acceptable.

Anonymous

This is the best article I’ve read on Sitepoint in a long time

http://modularchameleon.com Joella Molson

I’m just a self-taught wannabe web designer and I spent a great deal of time teaching myself web design and wordpress theming. Just as I got a handle on everything (or so I thought), the entire landscape began to transform before my very eyes. Projects I had on the go suddenly ground to a halt and I despaired that they would never be given life.

I’m starting to grasp html5 and how to use it, but my complex layouts were still problematic. Thanks to this article I despair no more. Wait, what is that I see at the end of the layout tunnel? Ah, it is the light of simplicity.