When to use tables for layout(olav.dk)
olav.dk
When to use tables for layout
http://olav.dk/articles/tables.html
69 comments
This article is missing the point...it is merely talking about when it is CONVENIENT to use tables for layout, not when one SHOULD use tables for layout. In a modern web world it is extremely inappropriate to use tables for non-tabular data. Yes, this means that oftentimes there will be messy CSS hacks to bring Internet Explorer into submission, but any designer/developer worth his/her salt is old hat at such tricks by now.
The proper time to use tables for layout is when one is laying out out a table. If you aren't, then you are simply performing a cop-out maneuver to save yourself time in website development. If that's what you want to do, do it, but don't call it something it's not. Just because it's easier doesn't mean it's better.
The proper time to use tables for layout is when one is laying out out a table. If you aren't, then you are simply performing a cop-out maneuver to save yourself time in website development. If that's what you want to do, do it, but don't call it something it's not. Just because it's easier doesn't mean it's better.
> In a modern web world it is extremely inappropriate to use tables for non-tabular data [even when convenient]
Why?
Why?
Fair question. Semantically the <table> tag is created for just that, tabular data. If you use it for layout there are a number of problems. First, it is harder for screen-readers and other accessibility-based tools to decipher a website laid out with tables than one properly laid out using standards-based development. Second, you are adding needless bloat and confusion to your markup, as you will have completely unnecessary tags littered throughout your HTML. Third, you will be going against standards-based development, which is a worthy goal in and of itself.
CSS exists to separate markup from style information, that's its entire purpose. To use tables to lay out a page is to explicitly include style information in a place designated only for semantic markup.
CSS exists to separate markup from style information, that's its entire purpose. To use tables to lay out a page is to explicitly include style information in a place designated only for semantic markup.
Perhaps the solution is to make a better screen reader, one that can extract semantic data from non-semantic markup.
Yeah, screen readers seem pretty useless if they cant handle a web page with tables-for-layout, since these are quite common whether we like it or not.
A sensible heuristic would be to treat tables without TH or THEAD elements as layout-tables, ie. just read them serially, while treating tables which contain at least one TH-element as a true semantic table. I'll bet this is the correct interpretation 9/10 times.
A sensible heuristic would be to treat tables without TH or THEAD elements as layout-tables, ie. just read them serially, while treating tables which contain at least one TH-element as a true semantic table. I'll bet this is the correct interpretation 9/10 times.
Heh. It's ironic that XML was designed to represent text documents, but is now mostly used to hold data. Maybe if they had named it eXtensible Table Language, they would have enticed people to put text into it like they do with the <table> element.
The <table> tag may have been designed to be used for table, but this is not what it is used for in practice. Hence screen readers should adapt.
Bate taken. Because it violates the semantics of what a table should be. i.e. a data matrix.
I don't care what a table "should" be very much. How is that even determined? By what some committee says? I care what, in fact, it does. How browsers and others use it.
Yes by a committee... and it's the lack of following W3C standards in the late 90's and early 00's that has created such a headache for web developers today. For example if IE5/IE6 played nice, we could spend more time building out sweet functionality and less time bug-fixing.
It's ok to be a conformist in this regard.
It's ok to be a conformist in this regard.
Of course you can always do what ever you want/what ever works. But the reality is moving away from tables for your layout will make your site more malleable and easy to maintain the future. It doesn't always mean crazy i.e. only clauses in your css either. see: http://news.ycombinator.com/item?id=219809
but didn't the article give an example or two where tables made your site more maintainable?
Tables give you abritary grids, a very important design tool. CSS doesn't do as well. People turn to CSS frameworks to make it happen.
No, that was not my interpretation of this article at all. It sounds to me like you've never built a large CSS/XHTML valid website, or you'd understand why the web is driving toward standards.
I was like you ~3-4 years ago as I grew up using tables. Believe me, just move on... 99% of the job postings I see require an understanding of XHTML/CSS. And this trend will continue as standards are solidified...
Catch up or be left behind.
I was like you ~3-4 years ago as I grew up using tables. Believe me, just move on... 99% of the job postings I see require an understanding of XHTML/CSS. And this trend will continue as standards are solidified...
Catch up or be left behind.
The point of the article is to show how table-based layouts in some specific circumstances are more maintainable than pure-CSS layout. If you disagree with this, it would be interesting to hear your counterpoints.
It's called a table, not a grid. And as information and the internet enlarge (hence the continuous drive for better search), semantics are a very important aspect of the equation. As such, so is using proper markup to define the content of the page.
Your post does not constitute more "maintainable" code at all, and contradicts the years of community contributions to CSSZenGarden. I'd recommend you establish a personal CSS "framework" for tackling common layouts/frustrations.
Your post does not constitute more "maintainable" code at all, and contradicts the years of community contributions to CSSZenGarden. I'd recommend you establish a personal CSS "framework" for tackling common layouts/frustrations.
How would you specifically solve the form-in-a-grid layout problem described in the article?
sounds to me like you've never built a sizable web application.
I've been in the business since the late 90's my friend, and for a significant portion of that time on the side of front-end design and production. I didn't mean anything negative by calling out his inexperience with XHTML/CSS, but after reading through his rebuttal it was the only logical conclusion.
Unlike you, I clicked on your profile and read a vast majority of your comments. You should go back to lurking, and spew your negativity and snide remarks elsewhere...
Unlike you, I clicked on your profile and read a vast majority of your comments. You should go back to lurking, and spew your negativity and snide remarks elsewhere...
oh i didn't mean anything negative either. it was just ... the logical conclusion.
unlike you, i have no interest in your profile.
unlike you, i have no interest in your profile.
[deleted]
it is extremely inappropriate to use tables for non-tabular data
Oh no, you mean everything I've read here in the last 482 days has been displayed in "extremely inappropriate" mode?
Oh no, you mean everything I've read here in the last 482 days has been displayed in "extremely inappropriate" mode?
Amen. This is one of those pedantries that has outlived its justification.
Look: can tables be misused? Yes. Have they been? Yes. Does a static HTML file filled with tables for layout obscure the semantics for things like screen-readers? Sure.
Does any of that have anything to do with whether or not a table should be used for layout? Not that I can see. Two or three lines of jQuery will pack those divs into your table by class.
The weirdest part of all of this is the idea that CSS is "just as good" for typical layout tasks. Not only is it not as good, it's a near-disaster. Nothing works right, ever. It's never possible to just say "line these elements up and put these others to their side" without jumping through awful hoops. Seriously: look at the "layout" CSS for any serious site and it's almost unreadable.
GUI developers have understood this for two decades now, and universally settled on the table as the appropriate layout mechanism. Why the web should somehow be different just baffles me.
Look: can tables be misused? Yes. Have they been? Yes. Does a static HTML file filled with tables for layout obscure the semantics for things like screen-readers? Sure.
Does any of that have anything to do with whether or not a table should be used for layout? Not that I can see. Two or three lines of jQuery will pack those divs into your table by class.
The weirdest part of all of this is the idea that CSS is "just as good" for typical layout tasks. Not only is it not as good, it's a near-disaster. Nothing works right, ever. It's never possible to just say "line these elements up and put these others to their side" without jumping through awful hoops. Seriously: look at the "layout" CSS for any serious site and it's almost unreadable.
GUI developers have understood this for two decades now, and universally settled on the table as the appropriate layout mechanism. Why the web should somehow be different just baffles me.
Again, I find myself agreeing with you :-) People seem to think that if you create CSS based layouts, that they can be repositioned and re-done using only CSS. This is simply incorrect, and anyone with sufficient html experience knows this.
If you want to change the layout of any site, you need access to both the html and the CSS, so trying to separate the two is just overkill. Sure, you'll want to use CSS for colors and fonts, but for page flow, CSS isn't powerful enough by itself.
If you want to change the layout of any site, you need access to both the html and the CSS, so trying to separate the two is just overkill. Sure, you'll want to use CSS for colors and fonts, but for page flow, CSS isn't powerful enough by itself.
You should tell that to the guys over at CSSZenGarden... they'll get a good chuckle.
The CSSZenGarden is - as mentioned in the article - a special case because the content never changes. This means that some of the flexibility issues with CSS is not a problem. You can design everything with fixed sizes and positioning. Every single paragraph is assigned a unique id which you can address.
This approach will never work on "real" web site, because content on a real web site changes.
This approach will never work on "real" web site, because content on a real web site changes.
Whether or not the content is static or dynamic is kind of a moot point, all things considered. <div style="define-my-location"><?php ?></div>
No. That is the main point of the article. Pure-CSS layout is only fine if you know the exact dimensions of the text when creating the layout. If the textual content change later you run into problems.
That is why tables fare better in "the real world" even if proof-of-concepts like zen-garden seem to demonstrate that CSS is powerful enough.
That is why tables fare better in "the real world" even if proof-of-concepts like zen-garden seem to demonstrate that CSS is powerful enough.
In the case of your example, if you truly have a label that resides beside an input box that could hypothetically be as long as a sentence... then you've done more wrong in your content structuring, than you have with your code. :)
As far as your column example is concerned, you made two content areas dependent on each other when that relationship may change overtime too, however with tables... you must recode the entire site structure to adapt to that.
As far as your column example is concerned, you made two content areas dependent on each other when that relationship may change overtime too, however with tables... you must recode the entire site structure to adapt to that.
I disagree with you... and I'd like to think I have "sufficient" HTML experience but as you didn't define what that is, I could be wrong.
A couple of years ago, I ran a styleswitcher on my blog giving the visitor about 5 layouts to choose from. Each one visually different from the rest, not one of them needing any changes to the HTML. The content changed on a daily basis (every time I wrote an entry) and yet it still managed to fulfil its purpose.
Sure, it was only a blog and not a commercial website, but it still shows that CSS is capable of changing the layout by itself. Perhaps sufficient CSS experience is the key?
A couple of years ago, I ran a styleswitcher on my blog giving the visitor about 5 layouts to choose from. Each one visually different from the rest, not one of them needing any changes to the HTML. The content changed on a daily basis (every time I wrote an entry) and yet it still managed to fulfil its purpose.
Sure, it was only a blog and not a commercial website, but it still shows that CSS is capable of changing the layout by itself. Perhaps sufficient CSS experience is the key?
I absolutely love Flex's layout system and it's not table based.
> In a modern web world it is extremely inappropriate to use tables for non-tabular data.
Someone once said (in an admittedly totally different context) that '"Inappropriate" is the null criticism. It's merely the adjective form of "I don't like it."'
Someone once said (in an admittedly totally different context) that '"Inappropriate" is the null criticism. It's merely the adjective form of "I don't like it."'
If tables were good enough for Viaweb in 1995, then they're good enough for the rest of us in 108.
That's 19108 to you, mister!
According to accessibility gurus that I know (proper ones who run real controlled tests with screen readers, not just random people who read blogs) using tables for form layout (as shown in that article) is bad, because screen readers have "forms mode" and "tables mode" and a form inside a table forces them to constantly toggle between the two, making it extremely hard to follow.
The world will not write code for screen readers. How about writing screen readers that can read the code that the world wants to write?
That would be fantastic. The problem is that we're pretty much stuck with the screen readers we've got - even when the screen reader companies do release new versions (which they do painfully infrequently) most of their users stick with their current versions because the upgrades are so expensive. If you care about blind users (which you should; you're missing one of the great benefits of the Web if you don't) you need to cater to screen reader versions that are five or so years old!
Fine, I'll ignore the blind market. I'm not trying to be mean but just realistic. I don't operate a government website which needs to be ADA compliant, and if screen reader software isn't where it needs to be, then maybe there is just no solution.
It is pretty pointless to care about blind users, since they can't use most AJAX based sites anyway.
I thought this was the whole point behind "graceful degradation". If an AJAX based site does not degrade to still be useable/accessible when JS is off or unavailable, then it's not that well desgined to begin with.
HTML table elements are not the solution. They are a convenient hack that happens to be the best alternative in 2008 because the majority of users is still on an IE browser.
In fact, it is quite possible to get table-like layout behavior while using semantically correct tags. This is accomplished through the various display: table-type CSS properties.
As support for IE6 fades this long awaited dream will quickly become a reality.
In fact, it is quite possible to get table-like layout behavior while using semantically correct tags. This is accomplished through the various display: table-type CSS properties.
As support for IE6 fades this long awaited dream will quickly become a reality.
IE7 does not support display:table either, so the long awaited dream is still far away. Reportedly IE8 beta supports is though.
Dude hasn't heard of definition lists for forms? They offer far better screen reader flow for disabled users than tables.
How do definition lists offer a better reader flow?
They don't. A table row has exactly the same recursive structure as a definition list, and will be treated the same way by a screenreader. It's kinda sad how many people like to play the "accessibility card" without any actual understanding of how those technologies work.
What screenreaders do have trouble with, however, is static layouts where the "meaningful" content is buried six levels deep, and often at the end of the logical document, just to make room for a bunch of navigation aids and advertisements.
That, however, isn't a reason not to use tables where they help. Also, note that with just a tiny amount of javascript it's possible to come up with a document that displays in a nice table layout and has a nice logical structure for screenreaders. It just requires that you get beyond the pedantry of the table.
What screenreaders do have trouble with, however, is static layouts where the "meaningful" content is buried six levels deep, and often at the end of the logical document, just to make room for a bunch of navigation aids and advertisements.
That, however, isn't a reason not to use tables where they help. Also, note that with just a tiny amount of javascript it's possible to come up with a document that displays in a nice table layout and has a nice logical structure for screenreaders. It just requires that you get beyond the pedantry of the table.
Arguments about screen-readers seem to be mostly based on superstition or wishful thinking. Some seem to believe that screen readers are actually the fabled and elusive semantic browser which understands the subtle semantic differences between UL, OL and DL, but on the other hand is stupid enough to just crash upon encountering a TABLE without a TH.
This might be the case, but it would be really interesting to hear something about it from someone who actually have real-world experience with them.
This might be the case, but it would be really interesting to hear something about it from someone who actually have real-world experience with them.
Apparently forms inside tables are bad for screenreader users because they have to constantly switch between "forms mode" and "tables mode" to navigate them.
Bingo! Tables should be used for tabular data.
Forms are tabular data -- headers on side, data on the other.
Screen readers should have long adapted to that scenario.
Screen readers should have long adapted to that scenario.
> Forms are tabular data -- headers on side, data on the other.
For very simple form designs, sure. But that idea breaks down when you have a more sophisticated form and need to consider horizontal "flow" between fields.
Tables are hammers, but not all forms are nails.
For very simple form designs, sure. But that idea breaks down when you have a more sophisticated form and need to consider horizontal "flow" between fields.
Tables are hammers, but not all forms are nails.
Thank you for pointing these out. You're absolutely correct -- I'm not sure how the "accessibility card" could still be played without better understanding, but it seems to stick around.
I challenge the hackers here to find a way to teach this to the CSS diehards. I often wonder why the accessibility of CSS based layouts is often preached by the same people who make Flash sites.
I challenge the hackers here to find a way to teach this to the CSS diehards. I often wonder why the accessibility of CSS based layouts is often preached by the same people who make Flash sites.
I get really annoyed by the recurring CSS vs. tables debates, because they seem to be so dogmatic and often based on misunderstandings of CSS.
CSS was initially designed to support every kind of typography or layout which was achievable using presentational HTML. It was rightly recognized that if some effects (no matter how ill-advised) were only possible using presentational markup, people would not migrate to CSS. This is the reason properties like "blink" were included in CSS.
Regarding table-like layouts, the corresponding CSS property is called "display:table", and was included in the CSS 2.0 standard 10 years ago.
IE however did not and does still not support "display:table". Therefore there is no direct CSS alternative to table-layouts which works cross-browser.
A table-like layout can still with some effort be emulated by pushing other CSS features like floats to the limits. But this is actually misusing these CSS construct for a purpose they were never intended for, which makes it generally convoluted and inflexible compared to "just using tables".
But it is important to realize that the problems with the CSS approach is not that CSS is badly designed - or requires a fundamentally different mindset - but simply that the implementation in IE is incomplete.
One should also realize that tables are superior only in some specific circumstances (as described in the article). Generally CSS is better and easier to use for layout, even considering the omissions in IE.
CSS was initially designed to support every kind of typography or layout which was achievable using presentational HTML. It was rightly recognized that if some effects (no matter how ill-advised) were only possible using presentational markup, people would not migrate to CSS. This is the reason properties like "blink" were included in CSS.
Regarding table-like layouts, the corresponding CSS property is called "display:table", and was included in the CSS 2.0 standard 10 years ago.
IE however did not and does still not support "display:table". Therefore there is no direct CSS alternative to table-layouts which works cross-browser.
A table-like layout can still with some effort be emulated by pushing other CSS features like floats to the limits. But this is actually misusing these CSS construct for a purpose they were never intended for, which makes it generally convoluted and inflexible compared to "just using tables".
But it is important to realize that the problems with the CSS approach is not that CSS is badly designed - or requires a fundamentally different mindset - but simply that the implementation in IE is incomplete.
One should also realize that tables are superior only in some specific circumstances (as described in the article). Generally CSS is better and easier to use for layout, even considering the omissions in IE.
[deleted]
Why not instead of blaming designers who use tables for layouts that are nearly impossible to do CSS, blame the browsers (ie 6 and 7) that make these types of layouts impossible under CSS.
I agree that IE is to blame for the situation, but users don't care about standards, they want stuff to work. life sucks
Does it seem like we are still in the dark ages of web design and layout? Lately, I've been excited that I can get away with using alpha transparent PNGs on my sites, even though we've had the technology for the last decade.
From the moment I began to learn HTML, I've been busting my head against this 4x4 beam standing here. The beam is bloody, but I'm still struggling with things that should be ultra-simple.
We have a variety of prior work we can use to investigate better layout strategies, namely from the print design/layout world and from the programming world, where we have layout managers a-plenty. It really is frustrating.
From the moment I began to learn HTML, I've been busting my head against this 4x4 beam standing here. The beam is bloody, but I'm still struggling with things that should be ultra-simple.
We have a variety of prior work we can use to investigate better layout strategies, namely from the print design/layout world and from the programming world, where we have layout managers a-plenty. It really is frustrating.
Using tables for form layout is a bit of a grey area--both in terms of "abuse" and suitability. In my view, if you put your labels in TH cells and then you corresponding form control(s) [see note 1] in adjacent TD cells - and make appropriate use of 'for' and 'id' attributes accordingly - this isn't such a problem.
However, using tables for general page/columns layout is ignorant. It also highlights fundamental weaknesses in your page designs to begin with; if you need to use tables to get around the "limitations" of your CMS, you should be educating your designer(s) as to what is and isn't possible.
In my experience, with considered design and type-setting - plus the "background to create appearance of columns" trick - there's nothing you can't achieve with semantically rich, minimalist markup.
I've been able to depend on the 'One True Layout' CSS columns framework since its inception and have yet to encounter a columnal page design it couldn't handle cross-browser.
[1] You need to be careful with things like groups of related form controls, however--such as radio buttons. These should always be displayed using a fieldset, along with an accompanying legend, which means tables aren't particularly suitable for semantically arranging this sort of complex interface. For things like simple login or user profiling forms though, I think tables are arguably an OK construct to use. But I never do, personally.
However, using tables for general page/columns layout is ignorant. It also highlights fundamental weaknesses in your page designs to begin with; if you need to use tables to get around the "limitations" of your CMS, you should be educating your designer(s) as to what is and isn't possible.
In my experience, with considered design and type-setting - plus the "background to create appearance of columns" trick - there's nothing you can't achieve with semantically rich, minimalist markup.
I've been able to depend on the 'One True Layout' CSS columns framework since its inception and have yet to encounter a columnal page design it couldn't handle cross-browser.
[1] You need to be careful with things like groups of related form controls, however--such as radio buttons. These should always be displayed using a fieldset, along with an accompanying legend, which means tables aren't particularly suitable for semantically arranging this sort of complex interface. For things like simple login or user profiling forms though, I think tables are arguably an OK construct to use. But I never do, personally.
What limitations in the CMS are you referring to? The limitations are not in the CMS, they are in the browsers implementation of CSS.
I was making the assumption that a developer may have limited control of what markup is being output by their CMS - if they were using one.
You can't always nail down every last character coming out of a framework, should you be using one, no matter how great it might be.
Anyway, as I said: it's not so much a problem using tables for form layouts. But I encourage you to look at pure CSS solutions for column layouts (such as 'One True Layout').
You obviously care about what you're producing, you should keep pursuing purer, more semantically rich (and appropriate!) markup.
If you want to discuss this one-on-one, you can get me via Twitter:
http://twitter.com/Wrestlevania
Look forward to hearing from you, Olav!
You can't always nail down every last character coming out of a framework, should you be using one, no matter how great it might be.
Anyway, as I said: it's not so much a problem using tables for form layouts. But I encourage you to look at pure CSS solutions for column layouts (such as 'One True Layout').
You obviously care about what you're producing, you should keep pursuing purer, more semantically rich (and appropriate!) markup.
If you want to discuss this one-on-one, you can get me via Twitter:
http://twitter.com/Wrestlevania
Look forward to hearing from you, Olav!
You could always use the layout tag to take care of the CSS pedants :-)
http://www.codeirony.com/?p=6
http://www.codeirony.com/?p=6
I know he is joking, but this would actually be a perfect solution if it generated HTML tables for IE - and CSS with display:table for any other user agent.
"Using a CSS layout with floating boxes, the sidebar-box does not stretch to the bottom."
"The solution proposed by CSS gurus seems to be to create a background image with a colored area overlapping with the sidebar-area"
What about height: 100% with a dom layout something like:
"The solution proposed by CSS gurus seems to be to create a background image with a colored area overlapping with the sidebar-area"
What about height: 100% with a dom layout something like:
div#wrapper
div#header
div#main
div#sidebar
div#main content
div#footer"A foolish consistency is the hobgoblin of little minds"
- Emerson
That is, using div vs. table or vice versa, just because you're "supposed to" strikes me as being contrary to the true hacker mindset.
- Emerson
That is, using div vs. table or vice versa, just because you're "supposed to" strikes me as being contrary to the true hacker mindset.