CSS Tables for layout are A Bad Idea.
There has recently been quite a bit of attention paid to the idea of using CSS Tables for layout, now that all browsers support display:table; and its associated attributes. Using CSS to force layout in a table-like manner has been written about in books, talked about in blogs, and hailed as a revolution in CSS based design. It’s not. It’s really bad. Don’t do it. I’m writing here to convince you why you shouldn’t.
First a little background: These values have been in the CSS specification for over eight years. It so happens that a certain popular browser didn’t support them and it’s taken until now for that browser vendor to catch up. I’ll let you guess who we’re talking about. Anyway, this isn’t anything new, and it’s not the product of any radical new thinking. Which leads me to my main issue with this idea: using CSS to perform table-esque layout is just as bad as using <table> for layout. It is a product of the same flawed thinking and it produces many of the same flaws as using a real <table> would. Allow me to break it down for you.
Pro’s of using display:table;
- We get equal height columns at last. Real ones.
- Things will line-up horizontally as well as vertically.
Con’s of using display:table;
We introduce a whole load of redundant, meaningless, only-there-to-position-stuff mark-up. Mark-up that makes future design changes as much of a pain in the ass as back in the day when you spent all those hours trying to re-factor a web page that was stuck inside a load of table mark-up. Remember trying to find the start and end of those table cells so you could cut the content out and move it somewhere new? Welcome back to a work methodology that sucks as hard now as it did then. The only difference is instead of this:
<table>
<tr>
<td>here's some content</td>
<td>here's some content</td>
<td>here's some content</td>
</tr>
<tr>
<td>here's some content</td>
<td>here's some content</td>
<td>here's some content</td>
</tr>
</table><div class="table">
<div class="table-row">
<div class="table-cell">here's some content</div>
<div class="table-cell">here's some content</div>
<div class="table-cell">here's some content</div>
</div>
<div class="table-row">
<div class="table-cell">here's some content</div>
<div class="table-cell">here's some content</div>
<div class="table-cell">here's some content</div>
</div>
</div>Now sure, you can kid yourself that you’ll somehow wrangle the results you want out of your existing mark-up, or at least you’ll be able to trim it down and get a bit more semantic - but when you’ve spent an hour trying to get your faux-table to work, and then it turns out a bit of content needs changing and now so does your faux-cell structure, you’re going to throw up your hands and just wrap stuff in otherwise pointless divs. And you’ll do that because that’s the practical thing to do - not because you’re not a good developer or designer. And when it comes time to re-design the site you’re going to spend a lot of time trawling through that mark-up, because now you’ve thrown it in there you can’t just tweak the CSS files to change the layout, you’ve got to adjust your mark-up too.
The “problem” with display : table; is that it not only re-introduces chronic cases of divitus, it also takes you back into a mindset from the dark days of the web. Soon you’ll be seeing designs in terms of slices. You’ll want to cut up visuals into neat squares. Your designs will start to go boxy again; you’ll lose the flexibility of scaling and adaptive layouts. You’ll slip into the mind-set that adding bits of mark-up purely for visual purposes isn’t really that bad.
CSS’s ability to emulate the layout characteristics of a table is a tool that was born back in the day when the default mindset for any layout was to use a table. It is a tool that works in exactly the same way as a table, the only benefit of which is to remove the semantic issues of using a table. But the other issues still remain. To flock to display:table now would be to take more than a couple of steps backward after eight years of learning how to do this web stuff properly.
How has it comes to this?
So why are designers clamouring over it as though it’s the best thing to happen to layout in years? Because, despite the horribleness, the suddenly animated ghost of yester-year is the best thing to happen in years. The W3C, still, are not willing to believe or are somehow incapable of understanding that the abilities of CSS today are inadequate for the job it must now perform compared to the job it was created to handle. And they are unwilling to re-think the very fundamentals of CSS that are crippling designers today. It’s almost a decade since CSS could be said to have “gone mainstream” - and yet designers are still waiting for a way to make things line up horizontally that doesn’t involve butchering the mark-up. Are still waiting for layout tools that allow us to do some really fundamental basics. Are still waiting for layout options flexible enough for us to use without resorting to complex hacks. And the future looks as bad as the present if the god-forsaken horror that is the “Advanced” layout module of CSS3 is any indication.
CSS tables do bring something new to the table (harhar!) - but that something new is a haggard ghost from the past dressed up in fancy new clothes. It is not the solution we need to our layout issues. We’ve done well enough for the last half-decade using floats and positioning. The web hasn’t fallen down, designers haven’t left the industry in droves, and progress in visual interestingness has continued to be made using the tools at hand. Please, keep using them - display:table is simply not worth the regressions it’s use would involve.
I’ll be talking about what we really need to see from CSS, my proposals for solving our layout problems, and why I am so very frustrated with the W3C, in the next post.
Entry Information
- Posted:
- Thu, 20th Nov 2008 at 14:11 UTC
- Filed under:
- Tags:
Comments
skip to comment formWhen I first heard about display:table I wasn't overly impressed. Mainly because of the title of the book associated with it: "Everything you know about CSS is s*** and you're rubbish!" - or something like that
My spidey-sense kicked in and I thought: "Hmmm, marketing spin?" - Lets make some noise and sell some books!
Don't get me wrong, tis an interesting method and worth a chin rub or 3, but can be summed up as follows:
Benefit = no need for clearing divs or other
Downside = flakey support for position:relative
And when I read that a solution to the position:relative issue was to 'design around it'. Well. "Tab closed".
"I'm going to get my mate CSS to tell my lies, because no one will ever know!"
Very good write up Matt, I agree 100%. I've not looked into or rather I haven't bothered looking into the whole display:table kafuffle because, as you, I just doesn't sit well with me.
I feel that the fundamental problems with web designers/ developers wanting to use such methods is that they never took the time to understand CSS and to learn [technically] how it all works. Once that is understood then the designers mindset will be to design with the constraints that cross browser CSS imposes in mind.
Of course the designer will argue that they shouldn't have to limit their designs but surely this is a better compromise than the s4it markup and hacky CSS that is being produced by some.
I've spent the last week building with my Dad and brother and if I may use the analogy of carpentry. If a carpenter does not understand and know his tools and materials completely then any structure built using said tools and materials is never going to be good. From afar it might look fancy but look closely and you'll see the mess that it really is. The very same points go for web development. It's your job - you're the expert… know your tools.
As for the W3C, they seem to have adopted a mentality or mindset akin to that of upper management in a large corporation. What they need is a Michael O'Leary (of Ryanair fame) to go in and shake the place up and start getting results. I've no idea who that person might be but if it doesn't happen soon we'll be going around in backwards circles forever.
[/end rant]
Given the fact that I, among many others, am enamoured with strict grid-based layouts, the ability to place elements in table-like form seems - dare I say it - sensical.
That being said, I whole-heartedly agree with the main stance of this article, in that we need something new. Unfortunately, I really don’t know what that something is. I want my BODY element to contain only semantic children. I want my presentational layer to be able to group the aforementioned semantic children as needed, and slide them across the screen when the behavioral layer dictates. And I want other people to chime in and describe their own web development utopia.
Yes, we can do this stuff now - I do it every day. But there is so much of it that just doesn’t make sense when you step back and look at the whole picture. Any programmer worth their weight will tell you coupling is bad, so why then am I using Javascript (behavior) to set an element’s style property (presentation)? Why do we jump through hoops to create extra elements just to clear a float?
Better yet: why do I need "display: table" or floats when I really just want to create a layout grid?
Matt, I'm totally with you, and I have a solid idea on exactly what needs to be done - including ways of getting Grid layouts to work flexibly. I've even written about it before - however, time after time, the only thing the W3C will say is "give us a specific use case" which is absurd, or "this is too hard, why would anyone need something so powerful?". They are hearing without listening.
I've an article coming up which I hope will answer those concerns and finally convince the W3C that at this point they don't need use cases, they need to step back, see the big picture, and implement an architecture enhancement rather than bolting on quick-fixes to specific issues that miss the mark.
"after eight years of learning how to do this web stuff properly"
…you mean negative margins, a hacked box model and inconsistent, bashed-into-shape floats?
While I agree that css-tables is not the ideal solution [i fully support your DOM idea], I think it is infinitely better than the dependence on current techniques for layout, which is basically taking advantage of quirks in css intended for completely different purposes [take float for example].
You're essentially right about CSS being inadequate and generally sucky. I agree with that. But I think you are making a strawman argument regarding display:table.
You don't actually need that class="table-row" or class="table" business. The spec clearly tells browsers how to handle a bunch of sibling cells that don't have a display:table-row parent. It's not well supported, but it's clear that browser makers are working on supporting it better.
The problem with tables-for-layout isn't that there are a lot of elements. The problem is that table, tbody, tr, and td *mean something*, so using them for layout is a lie. A div is semantically meaningless. While it's certainly better to use fewer unnecessary elements, I fail to see how display:table makes this problem any worse, compared with the hacky hoops that we need to jump through today. (Which leads to the point we agree on, of course, that CSS is stretched well past its intended capabilities.)
Regarding slicing up designs, we *already* do this in order to support floated and relative/absolutely positioned elements. The fact is, ultimately, we're presenting our designs on a 2-dimensional pixellated canvas. We can wave our hands and say "flow", or we can admit that a grid is a very useful tool that people have been using for centuries to do 2-dimensional layouts in every flat medium.
Like you, I'd definitely like to see some better tools for layout. Table display, at least how it's implemented, is not an ideal grid mechanism. Of course, the table tag was hijacked unexpectedly as a layout device, and wasn't ever intended for that task. CSS table display is better, but still far from perfect.
The w3c is not an innovative organization. The only way to fix the problem is another browser war. Unfortunately, the CSS spec is just good enough to stay broken.
Please, don't use underline decoration for non anchor text (use it for anchor, only different color is not good). I click on em like idiot
"Better yet: why do I need 'display: table' or floats when I really just want to create a layout grid?"
One can only hope - w3.org/TR/css3-grid/
I think you're spending way too much time on the semantic meaning of the word "table"
If this were a new element of CSS named something like
header {display:whatever;}
You too would be studying it, buying books on it, implementing it, and pushing it.
And really…who names there classes -table….table-row…table-cell. Way to exaggerate your point.
Also…I think putting "Best viewed in a modern browser [Firefox, Safari, Opera]" is tacky. Learn how to make your page work in all browsers or don't come at all.
Brandon: You've rather missed the point, and judging by your website that seems to be because you're not a web designer or developer. If you're going to leave criticism it might be an idea for you to know what you're talking about, and how to leave polite and useful feedback; learning both will make you look less of an asshat.
You might try a few resources to get you started:
http://htmldog.com
http://alistapart.com
Good luck!
Sorry to wade into the discussion so late but I have to side with Brandon (if we ignore his google pages website) because he has a good point. It does seem that if the CSS rule where called {display: grid} as opposed to {display: table} people would be a lot happier.
Whilst I agree it'd be a better if we could use only the HTML we needed and not have to suffer all these container s - I just want equal height columns.
Phil,
it doesn't matter what the CSS label is called, this is not about the semantics of the CSS itself. This is about the fact that it's a solution that depends very heavily on the mark-up, is highly likely to require a large amount of otherwise redundant mark-up in order to achieve the visual results we're after, and as such is a very poor solution for web-page layout. It may well be fine for laying out minor sections of a page, but not a full page.
Yes it will get the job done. No it is not the way it should be done, it has all of the drawbacks of using tables for layout because, apart from changing some mark-up names and thus removing the semantic problem of tables-for-layout, it IS tables for layout.
sounds like you just haven't noticed all the tools available in css3. Theres no need for all that semantic markup.
I would recommend checking out this presentation:
http://creatingsexystylesheets.com/
slide 49 onwards shows how to use css3 table layouts with semantic markup and fairly straightforward css.
I think the problem is that you are treating css3 tables exactly like html tables, which is an easy mistake to make.
But the point of css3 table layouts is not to replace with , but to use the advanced selectors to pick out repeated elements without having to modify the html itself.
This issue highlights the importance of understanding web standards, not just following them blindly. The argument against tables is not that the markup is messy, but that is for indicating data, and using it for layout is not semantic, in that an entire webpage is not strictly 100% data.
There's no rule that says messy or complicated html is wrong or inaccessible, quite the contrary. Addressing accessibility usually requires extra markup and attributes.
That is NOT wrong.
Semantics and standards is not about making things simple, it is about making them correct.
Using css to make content appear in a tabular format is not semantically incorrect.
Also, no offence intended, but it sounds like you are unfamiliar with grid systems in design.
" Soon you’ll be seeing designs in terms of slices. You’ll want to cut up visuals into neat squares. "
^^This is absolutely not the case with grid-based design.
grids have always been an important part of graphic design, and their increasing adoption by web designers only aids in accessibility and clarity of communication in design.
On grid design, I would recommend mark boulton's series of articles:
http://www.markboulton.co.uk/articles/detail/five_simple_steps_to_designing_grid_systems/
Matt, Thank you for inspiring me to create this website:
http://isdisplaytableabadidea.co.uk/
Dan,
We agree on a lot of points, including a good few where you've assumed I'm lacking in knowledge where I'm not
I don't claim to know all the ins-and-outs of all the CSS3 modules, but I'm familiar with all of them in a general manner (and some in a much more detailed one). None of the CSS3 layout modules offer good solutions to our layout problems (and Table layout CSS is not CSS3, it's been in the spec for years). As for grid design - I've not mentioned it, I know full well it's not the same as table layout - that is in fact another problem with using table-based layouts to achieve a grid-like result.
Once again; display:table for page-layout is bad because it relies very heavily on the structure of the mark-up. Advanced selectors can go some way to mitigating this point, but you can't select something that isn't there; chances are still very good that to achieve a particular layout you will need to add redundant divs in at least a few places. Re-designing will therefore require re-authoring the HTML, which is wrong (in principal). Chances are also extremely good that you'll not be able to use those advanced selectors for layout for years yet, because of IE6 and 7. Further, what we all want is grid based layouts, and display:table is a very inferior solution to that requirement. It encourages bad thinking, bad mark-up, and harms the separation of style from structure by relying too much on the mark-up to give display structure.
Well, this entire article is predicated on the mistaken assumption that the entire table>table-row>table-cell tree must be rendered. No doubt the whole group of CSS haters will link to it.
Brianary - it's based on the view that display:table and associated values do not de-couple presentation from mark-up, rather, the opposite. It's mark-up dependant layout, and poor layout at that - tables are in no way a replacement for a grid.
I don't care what has to get rendered (and you're right, you can skip the lot and just hit table-cell) the use of display:table-cell for whole-page layout requires the tree, and even were it not to, it's still a very poor option for layout.
I quite like that this is an option and it should only be viewed as one option in many.
A lot of the time we have no control over the design of a page because it's all been signed off before it gets to us. I had a grunge one come along recently that required multiple backgrounds with everything moving except for the content and sidebar. This is the first time in my career that I would actually consider using this method because all others I can think of are nasty and very messy.
This is one of those things that can help in some situations but should never be considered the defacto for all creations.
"Brianary - it's based on the view that display:table and associated values do not de-couple presentation from mark-up, rather, the opposite."
Sorry, I just don't see it.
…
…
Those things *should* be delineated by separate containers.
I agree it can be used as an option… but it does feel a bit like mutton dressed as lamb!
It is my opinion, to start with, that html derailed in the wrong direction. CSS seems to follow the path. I have even doubts that a grid layout is ok. Because every web-surfer views the page on a different monitor and window size, an inflexible layout is like going in the stone age and painting a cave. Unfortunately, really flexible tools are missing to achieve anything else (excluding a lot of programatically laying out the page with js).
If we need a fixed grid, than SVG is way better than anything html/css offers. But this misses the point. Matt mentioned correctly in a different post, that constraining one object to another would add enormous flexibility. This was indeed my idea: have the ability to loosely couple elements (e.g. the widht, or the height, or the top or the left-position). This way you are able to create a fully flexible and fully dynamic solution.
What people probably miss, is the fact that web-pages try to display a basically linear document (html) in a multi-dimensional view (at least 2-dimensional), but still maintaining the liniarity of html (and providing some very poor tools to break it, especially when it is NOT needed).
I may rant the whole day on html and css - unfortunately it does not seem to help a lot. Another problem I was thinking recently, and where people try to limit CSS instead of making it more powerfull is described in: https://bugzilla.mozilla.org/show_bug.cgi?id=557013.
And a last issue for people to think about: How to split a generic web page into sections of equal height, and add a header and footer to all those sections?
Use bold text is better than for underline text.