Why Tables are Bad: A Response to My Colleague
Category: Web Standards
This is the discussion I had yesterday:
Colleague: Check out this new application I’m building for the web.
Me: Wow - that’s cool! Well, except you shouldn’t be using tables of course.
Colleague: Why not?
Me: Well tables are bad. You know…
Colleague: Nah, tables are fine. Why shouldn’t I use them?
Me: Well, because you should be using HTML and CSS.
Colleague: Why?
Me: Well, there’s lots of reasons…
Colleague: Well give me one…
And that’s where I sort of froze.
Now, imagine this. Someone studies History for 4 years and graduates from college with a degree. First day out and someone says, “History isn’t important.” And the student replies, “Yes it is…” To which the other person says, “Why?” At this point, the student’s brain freezes as there mind goes through the hundreds of possible answers to this question. There are endless numbers of reasons why History is important. But the student’s brain gets so frustrated, that it gives up and just says, “Because it is!!”
Now that’s now a very good argument and that’s what happened to me yesterday. I’ve been studying HTML, CSS and Web Standards for about 2 years now. And I’ve become so engrossed in that world, that when someone asked me a simple question, my brain just froze.
It’s now another day and I’ve had a chance to calm down : ) and think of a sensible reply. For this post, I could go out to Google and just list the numerous reasons why current web sites should not use tables. But, it’s probably better if I just stick to one “real world” reason for today and we can keep this as an ongoing discussion.
So to start, here’s reason #1:
Separating Layout from Design is More Efficient
As any technical developer knows, the client is always changing their mind. Most of time, they don’t know what they actually want until halfway through the project. And then that’s when they really start moving things about!
Now if you write your web page using valid XHTML, the CSS (or design) is totally separate. At this point, if the client wants to change the colour of all their Heading 1’s, it’s a single change to the style sheet. And if they want to change the width of all their pages, it’s a single change to the style sheet.
Width: 500px;
Width: 600px;
A single line change instead of moving about table cells, rows, etc. (Now I know you can apply styling to tables as well, but it’s nowhere near as flexible. You get the point.)
To see a classic example of this, you can visit the CSS Zen Garden. Just click on a style in the left menu and the entire design changes. While all of the HTML remains the same!
So that’s it for now. Like I said, there are lots of other reasons, but I think that’s a good start.
And a final message to my colleague - “We can continue this conversation in the pub : ) ”
Dennis
Separating data and design has been used for several years, systems like Mason, ASP, ASP.Net and others all manage it efficiently using, amongst other structures, tables.
The problem with tables has always been machine generated HTML or shoddy programmers. I have been “using”, occasionaly even creating ;-)), cleanly designed tables, style sheets, templates and Design/Code separation for years.
What benefits does the use of Div tags bestow over and above a well designed, table based, template system?
What age/versions of browsers does it exclude?
Do they make code developed by bad amateur/developers any easier to modify?
Is this just the next fashion/buzzword?
Quoting Google does not constitute a non fad influenced source ;-))
Tonight 1700 sharp, mines a Grolsch! ;-))
The standard answer to the question “why not use tables” is separating form from function. In other words separating the content from the layout.
The real reason to this is somewhat longer and has to be tinged with pragmatism; if tables are better, then use them. However, this will be a rare exception and by no means a reason to continue with sloppy coding practices.
There are many reasons for avoiding tables:
* Accessibility.
Fundamentally this states that tables should be used for data not structural markup. http://www.w3.org/TR/WCAG10-TECHS/#tech-avoid-table-for-layout
The reason is quite simple and is to do with the way screen readers read the page in a linear fashion - if you’ve ever tried to fast-forwards through a speech podcast, you’ll know how difficult it is.
Developers are generally quite lazy and don’t bother adding the required summary attributes, etc. This makes it harder for screen readers to read.
* Tables are inline markup
If you’re using a table to lay out your page, and say there’s 1000 of them, if you need to change this layout in any way, you’ll need to revisit 1000 pages. Doh!
Using CSS you place certain structure in the code, e.g. DIV tags. Apart from that, everything else is kept in the linked stylesheet. A change of size, colour, layout, all done in one file.
* Smaller code
As there’s minimal structural markup in the HTML when using CSS, the files are smaller, download quicker, and everything’s more responsive.
* Small screen devices
Tables are great. You decide on specifying a screen of, ssay, 1000 pixels wide. I view the page using a smaller screen device and I *have* to scroll sideways. Sorry, I hate you! Just because *YOU*, the developer, have a wide screen doesn’t mean that *I*, the visitor, am going to use the same equipment.
Using CSS, most small-screen devices will ignore the structural layout of the CSS, so will ‘linearise’ the page. Therefore I don’t scroll sideways and everything’s fine.
* Google et al
A CSS-compliant page will be smaller and therefore easier to parse for search engines. They love this!
Google has an accessible search (http://labs.google.com/accessible/) where the rankings are altered according to the accessibility of the page. CSS pages will rank higher than table-based designs. One site I re-designed went from 100th to 2nd.
* Don’t be lazy
Just because you’ve always done it this way isn’t because it’s right, it’s because you’ve always done it that way and in 1994 there was no other way of doing it. Just learn CSS and you’ll soon see how much better it is. There’s even courses available (http://www.learningtree.co.uk/courses/uk522.htm)
OK, there’s no tools available, but it’s not that difficult. Once you’ve a suitable template, it’s a breeze.
* Cons
Yes, there are difficulties. Most of them related to browser incompatibilities, and most of these are down to the market leader (you know which one this is). Once you get stuck into CSS development, you’ll soon learn the problems. http://www.positioniseverything.net/explorer.html will get you started.
The other thing to avoid is “divitus” where everything gets wrapped up in superfluous div tags. This is tough to learn, but once you’ve got it you’ll soon realise that life still goes on.
Finally, there are certain things that CSS won’t easily - or ever - do in comparison with tables. Most of this is related to vertical layout. Again, get over it and get on with developing standards based websites.
So, to summarise, pages are faster, easier to manage, are more accessible, better indexed by search engines.
Sorry, what was the question?
.Glenn
Yeah, what Glenn said!!
No, seriously, thanks for the reply Glenn. I knew you would have an excellent answer to this question.
And Murray, yes, “CSS” is a buzzword right now. But that doesn’t mean it’s a fad. Because it is definitely here to stay. The Web has come full circle now and we are getting back to the way HTML was intended to be used in the first place.
To quote the O’Reilly book “CSS, The Definitive Guide”:
“HTML was originally intended to be a structural markup language, used to describe the various parts of a document; very little was said about how those parts should be displayed. The language wasn’t concerned with appearance. Then came Mosaic.”
And we know the rest of the story. Pages became bloated with tables, in-line styles, hacks, etc.
CSS really is the best way to create a site - and as you investigate it, I’m sure you’ll come to the same conclusion as us.
Cheers!
Dennis
Yeah, if you want a W3C compliance label at the bottom of your page, you’ll have to run the verifier. And if you run even the 4.0 Strict verifier (let alone the XHTML one) then you’ll geta bunch of warnings if you use tables for layout (it can only warn because it’s not sure you’re not using them for tabular data).
And to be fair, asp and asp.net aren’t layout designers, they’re coding frameworks, and those using them can (and should) use css for layout design. I started using css a few years ago on my private stuff, then work stuff soon after and the difference in maintenance was miraculous.
If you’re interested, Muzza, then I can show you the QXLVA code (which used tables, despite the fact that css was established by then) and compare it with the css stuff we use now. The difference in markup code is easily 400% in size terms alone.
Apologies for the double-post, but there’s no edit button.
Evidence for the css-is-no-passing fad position would be a cool css competition I remember NTK running back in 2002: you can still see the description here, though the stylesheets have gone from people’s personal hosting by now. It took advantage of the fact that you could specify an external stylesheet to format a page in the way *you* wanted, and the competition was to show their home page in the style of other websites, or in various other cool fashions.
Also, appealing to you as a developer, there is something so elegant about writing a webpage where you have a few function calls or #includes to populate shared elements like navbars, so that the work there is done in the appropriate places, some layout with divs for positioning and formatting where the work is done in the css, and a few %= type links or #includes for the content. Suddenly a huge monster of a page is reduced to three or four smaller, easily-maintained and logically discrete layers of functionality.
Good points Endie.
And I’ll see about adding that “Edit” button to the comments section.
Cheers
Dennis
I’ve a feeling in my water as it were that it’s quite possible to have a standard(ish) layout that would fit most pages, then it’s just a matter of applying the appropriate stylesheet.
OK, this has to be tinged with a lot of caveats; the “main” layout would only fall to this ’standard’ and there’s a lot inside. But then again, ZenGarden is pretty much this. OK, in this case the HTML is well over the top with just about every paragraph having a different ID. But it does sort of prove the point that it’s possible.
For me, I’ve always thought that you should be able to define a page with a main content, header, topnav, leftnav (lets call that the context nav), rightnav (this would be the optional menu), central section, body section, footernav, post footer.
To this you’d have to have specific styling for things such as logon and search forms.
I know this is inviting howls of derision, but it will cover most of the types of sites I’ve built in the past.
One day, if I’ve the time, I really feel like sitting down and defining something like that.