Why are HTML tables so abhorred?

October 8, 2005 1:14 PM

Why is it so bad to use tables for web layout?

Granted, if it's done poorly, you end up with layouts that all look the same - crappy. But that's true of bad design in general. Beyond this, there seems to be a deeper feeling that tables are inherently bad, and I'm curious exactly why.

posted by freebird to computers & internet (54 comments total)

Not sure -- I think they're great. I use tables all the time for establishing the geometrics of a page. Then again I still write all my HTML by hand... I haven't yet found an HTML editor that I trust.
posted by rolypolyman at 1:21 PM on October 8, 2005

Tables are good; frames are bad.
posted by wsg at 1:28 PM on October 8, 2005

Because some think tables should only be for tabular data, like stuff you might show in a spreadsheet.

Also, for very long tables, the browser will render the entire table at one time after all the data has loaded, so before broadband and faster computers, some pages would be blank for awhile when loading.

They also don't fit in with the idea of separating content and layout, ie: CSS versus xHTML. But used sparingly, I think they're okay, and you're more likely to have browser support for them over some div float layouts.
posted by gramcracker at 1:33 PM on October 8, 2005

During the browser war era, wasn't there a time when Netscape and IE rendered tables very differently? Maybe it's leftover enmity from those days.
posted by aiko at 1:33 PM on October 8, 2005

tables as layout devices are bad becase they confuse content and presentation in a document. they were originally designed to display tabular data (charts, tables, etc) in orderly ways, and their use as layout tools is essentially a hack dating back to the earlier browsers. what happens when you use a table to create the presentational aspects of your page is that you divide the content into chunks based not on what the chunks mean or their function in the document, but instead based on visual characteristics. this makes it difficult for non-traditional devices such as screen readers for the blind or web-enabled phones to display or render your site in any meaningful way. it's better to use CSS for visual presentation because it allows non-traditional devices to make sense of your page and reinterpret it based on the needs of the end-user. it also allows you to create context sensitive versions of a document with a single set of markup (ie, making print-friendly or WAP-friendly style sheets for one single html document).

there's plenty of other reasons, but basically: you're sacrificing the flexibility and accessibility of your document by using tables as a presentational device.
posted by cathodeheart at 1:33 PM on October 8, 2005

Tables are for organizing tabular data, not laying out text. HTML should contain no presentational markup; all presentation should be handled by a linked CSS file.

This approach improves accessibility: if your markup only describes the content, not the content's look, said content can be interpreted by non-standard devices that may not consider presentation (a common example is screen readers), or by older equipment that may not understand presentational rules (somebody out there still uses Netscape 3, I'm sure).

It's also easier to code and easier to maintain.

(On preview: dammit. Should've typed faster.)
posted by S.C. at 1:35 PM on October 8, 2005

Also, for very long tables, the browser will render the entire table at one time after all the data has loaded, so before broadband and faster computers, some pages would be blank for awhile when loading.

And because of this you also can't control what part of your page loads first -- it will always be in display order. If you use DIVs and things instead of tables you can set it so the content loads first and the navigation last, so people on slow connections can read even while the page is still loading.
posted by ArmyOfKittens at 1:41 PM on October 8, 2005

Accessibility, standards, semantics, etc. are all good things, but that's not my biggest gripe with table-based layouts.

I don't like tables because I've had to maintain pages built by other people with table based and CSS layouts, and CSS wins hands down.
posted by revgeorge at 1:45 PM on October 8, 2005

I would be cautious about maintaining that tables degrade accessibility for screen reader users per se. If the page is coded so it makes sense if the contents are rendered one cell at a time in order of HTML code then many accessible web solutions, including screen readers, will present the content just fine.

The issue here is when the page is presented to someone who does not have the advantage of the large 2D visual presentation space and is forced to read your page in linear order of HTML code: will your page still make sense? There is a Firefox extension called Fangs that lets you see your page rendered linearly. You could also check out using WebbIE for assessing accessibility (disclaimer: I develop WebbIE). However, your best test might be to try checking out one of your table-based pages on your mobile 'phone using WAP: does it make any sense, or do you have to wade through loads of navigation links and find the content hops about - headers after paragraphs, images divorced from captions. If the latter then your tables are making your page less accessible, and you need to rework or drop them.
posted by alasdair at 1:49 PM on October 8, 2005

Sorry, I'm an idiot: Fangs, the Firefox extension for examining accessibility.
posted by alasdair at 1:50 PM on October 8, 2005

Tables are not nearly so evil as some might suggest. Yes, they're primarily for tabular data (spreadsheets, lists, etc.). You're not supposed to mix content and presentation; the problem some people seem to forget is that sometimes the presentation has text, and needs to be laid out in an orderly fashion.

Perfect example: A picture, and underneath two navigations: < - previous and next ->. You want the previous to be left aligned under the picture and the next to be right aligned. And you want suitable margains in between. And that's in the middle of a block of text. In this case, using tables is not only much easier, it doesn't break the "content/presentation" rule, since the "previous/next" might as well be graphical... that is, they're already not part of the content, so who cares if they're comprised of actual text or not?

People get all hung up on "best practices" and miss the forest through the trees. Tables are handy, useful, and most important: just about every single browser going back a decade supports them without needless hackery (see: CSS Box Model).

Oh, and to those worried about their precious accessibility, tables defined in a stylesheet will [gasp!] validate perfectly fine, even in XHTML 1.0 strict. So phooey to the table haters.
posted by Civil_Disobedient at 1:54 PM on October 8, 2005

Civil_Disobedient: What's validation have to do with accessibility? And, Why do you hate America blind people?

Besides the content vs. presentation and accesibility issues, layout not based on tables (i.e. using CSS as God intended) will tend to be smaller, easier to understand, and (being smaller) use less bandwidth.

Syling your content instead of using tables also means that if you decide to change your site design, you can probably just tweak the style sheets without having to go back through editing hundreds of pages of TABLE-based layout.
posted by nmiell at 2:18 PM on October 8, 2005

Oh, and to those worried about their precious accessibility, tables defined in a stylesheet will [gasp!] validate perfectly fine, even in XHTML 1.0 strict.

Ummm....accessibility and standards compliance are two different things. Complementary, yes, and often advocated by the same people, but different. Accessibility means it is accessible to people with disabilities such as people with limited vision (though there are other issues such as people with limited manual dexterity and increasingly with deaf access to an increasingly multimedia WWW). Using tables is a hack and makes things difficult for screen readers, period -- even if arranged "correctly" it would be helpful to know if somnething was tabular data.
posted by dagnyscott at 2:19 PM on October 8, 2005

Forgive me, but validation to HTML standards is not the same as accessibility. Tables have accessibility problems because of the way they change the flow of information, not because they aren't valid HTML/XHTML.

Here is an example:

<h1>Holiday snaps</h1>
<table>
<tr>
<td><img src=Bob.png alt=Bob></td>
<td><img src=Kate.png alt=Kate></td>
</tr>
<tr>
<td><a href=morebob.htm>See more pictures</a></td>
<td><a href=morekate.htm>See more pictures</a><</td>
</tr>
</table>

This validates just fine and looks just great on a 2D layout. Picture of Bob, picture of Kate, link beneath each for more photos.

But render it in a screen reader or other accessible solution and you probably get this:

Bob
Kate
Link: Click for more
Link: Click for more

The link after Kate goes to Bob! You'll probably have to at least follow each link to work out where each goes, and navigating round pages and working out if the content you want is there is painfully slow in a screen reader.

With CSS you would be able to do something like this:
<div class=photocategory><img src=Bob.png alt=Bob><br><a href=morebob.htm>See more pictures</a></div>
<div class=photocategory><img src=Kate.png alt=Kate><br><a href=morekate.htm>See more pictures</a></div>

This would probably render in a screen reader as:

Bob
Link: See more pictures
Kate
Link: See more pictures

However, you could use CSS to make it look just the same to visual users as your table layout, so you get to have an accessible page that also looks good.

Tables are not automatically inaccessible and CSS is not automatically accessible, but if you know what you are doing then CSS gives you more flexibility to create the visual impact you want while maintaining accessibility.
posted by alasdair at 2:32 PM on October 8, 2005

nmiel: layout not based on tables ... will tend to be smaller, easier to understand

Indeed. Here's the accessible table form of the CSS code for Bob and Kate:

<table>
<tr>
<td>
<table>
<tr><td><img src=Bob.png alt=Bob></td></tr>
<tr><td><a href=morebob.htm>See more pictures</a></td></tr>
</table>
</td>
<td>
<table>
<tr><td><img src=Kate.png alt=Kate></td></tr>
<tr><td><a href=morekate.htm>See more pictures</a></td></tr>
</table>
</td>
</tr>
</table>

Renders as:

Bob
Link: See more pictures
Kate
Link: See more pictures

This is probably as accessible as the CSS solution, but it's a pain to handle as a web designer because of the number of nested tables required.
posted by alasdair at 2:43 PM on October 8, 2005

So why does CSS suck so much as a layout layer?
posted by cillit bang at 2:52 PM on October 8, 2005

I'm a big advocate of replacing table layout with CSS whenever possible, but there are still some situations in which tables are the only solution. The one I run into most often is when I'd like to have a 3-column layout in which the columns extend to the bottom of the screen even when content is short. Without going into the nitty gritty, I've not yet found a way to make divs have a minimum height equal to the height of the window, and I've seen some confirmation that this isn't possible (on IE, at least). You can fake it by putting big solid borders on the body element and using absolute positioning (Google "faux columns"), but this seems really ugly to me. So I use tables.
posted by gsteff at 3:20 PM on October 8, 2005

So why does CSS suck so much as a layout layer?

Because of (a) bad cross-browser support and (b) lack of a table-like construct, which really is quite useful (and in some cases easier to understand than some of the CSS tools).

Don't get me wrong. I like CSS. I've paid my dues and can do cross-browser table-free layouts. But sometimes, given project constraints, tables are the best tool for the job.

Because CSS is a tool, not nirvana. Accesibility is a Good Thing(TM), but it may or may not be a project priority, and it may be achieved with or without table-free layout markup.

See also some earlier AskMe discussions:
I Want to Believe in CSS
Convince Me CSS is Worth It
posted by weston at 3:28 PM on October 8, 2005

Browsers read through tables twice before displaying their contents, once to work out their structure and once to determine their content.
posted by furtive at 3:29 PM on October 8, 2005

Tables aren't bad. Tables are good. A lot of what Jakob Nielsen says is bad advice (some of it isn't).
posted by Hildago at 3:42 PM on October 8, 2005

A post to try and condense, perhaps clarify, perhaps loosen the strictures a little

HTML tables used for presentation are bad in the "semantic web".
By that (as you may or may not want to know) we mean "web code which means what it says". The "semantic web" implies that, when included in HTML, <TABLE> means "tabular data", like figures in categories; <BLOCKQUOTE> means an inset quotation; <H1> means "the most important heading"; etc.
That means HTML structures are there to create web content which makes sense, and not merely there to help you with that tricky layout, or to make your text stand off to the right a little bit.

Additionally, tables can be a f*cking pain in the ass for screen-readers. How does one read the content of a table linearly when it has colspans and rowspans all over the place? Nested tables (and I've tried this) make even often-visited and well-known sites utterly unusable in a screen reader. Information appears where you don't expect it to and the one piece of info you really want is always in the very final table cell.

However, there's a redeeming factor: tables can make layouts a lot easier to achieve. Personally, I don't use tables for layout at all, but that's because I'm able to use my experience to get around them. Make no mistake, my life would be easier if I used them more!

And so there's a trade-off between standards, accessibility and visual impact.

If you find that you can't use CSS for layout, then use a single, simple table to arrange the various bits of your page on screen. Don't nest tables, use very few if any col/rowspans, and use the summary attribute of the table to explain what the content is.

Tables are big, they are pretty, but they're not clever; use them for layout when you have no choice, but do everything else you possibly can without them. Learn more about other layout techniques, practise using stylesheets to achieve the look you want with the elements you should be using ("semantic web", remember) and eventually your question will change from "why shouldn't I?" to "why would they want to?"


...OK, so that wasn't so brief. If you managed to read all of it, good show. If you didn't, you probably weren't as interested in the answer as you first thought; never mind, I wish you had been. In either case, the more people who think about why things are done, the better - the "why" is just as important as the "how".
posted by NinjaPirate at 3:52 PM on October 8, 2005

I apologise for that post, it was supposed to be a lot less... massive.
posted by NinjaPirate at 3:54 PM on October 8, 2005

Table-less design folks will rave on and on about semantic markup or Tim Berners-Lee's "The Semantic Web", yet it really is at the heart of the issue. Tables, used for layout, are unnecessary bloat and obscure a page's content inside its code. It is amazingly useful to meet vastly different design goals (i.e., rss feed, "Print this Page", mobile devices, as well as your regular browser display) simply by swapping out a stylesheet... Tables, when used for overall layout, can thwart this ability and make it hard for people to get at your data in any other way than through the browser window.

Plus, I'm so tired of typing <table><tr><td></td></tr></table>, I'm happy to never, ever use nested tables for layout again.
posted by maniactown at 3:58 PM on October 8, 2005

Tables are evil things, and if you ignore all the accessibility/purity of content/whatever evangelism, there's still one reason why you should stop using tables for overall page layout.

If you ever have to go back in and edit that page, especially in a text editor, you will have no idea what the hell is going on. Table cells for border effects, table cells to split up images, table cells to add padding—a mess. And then you add all the "width='20px' " attributes you have to add, and colspans and rowspans and oh my jeebus. Your code becomes a nightmare to maintain, and if you ever leave it for a period of time and come back, you'll forget how that intricately-designed table worked. I want to add a link to the static sidebar in my table-layout blog! Okay, find the table cell(s) that contain it. Cripes!

Even tables with CSS code are a damned sight better than plain tables, because then you do away with all the table cells you would've expended on borders/padding instead of actual content. But it's still difficult to add to or modify the actual table structure because you have to keep track of the number of rows/columns there are, and what's been merged and what hasn't been. Imagine trying to break a merged cell in a Word table. Now imagine doing that without a GUI.

And if you're an awesome coder that's managed to solve all these problems, congratulations. The next person who has to touch your code, however, probably isn't like you and will have even less of an idea of what's going on.

This is not to say that CSS layout code can't be messy or complex; it's to say that table layout code often is messy and complex, and often necessarily so.

I dislike CSS as much as the next person, and would love to see it changed. Like it or not, CSS is used mostly for visual design, and I'd like to see some changes to the model that facilitate simple visual treatments (like, oh, I don't know, horizontal or vertical centering of an element within its container?). But compared to the table layouts of yesteryear, CSS is easier to maintain, far more human-readable, and less bloated. Plus it can do nifty things tables can't.
posted by chrominance at 4:01 PM on October 8, 2005

Please separate "CSS sucks" and "CSS implementations suck" comments, please. CSS supports centering, for instance (margin:auto) but a certain implementation blows it. Such arguments are almost a form of ad-hominim attack (except that that certain implementation is a de-facto standard... sigh)

CSS uses bandwidth much more efficiently, it separates content and presentation, it makes more sense than table flotsam, it probably renders faster due to the smaller doc tree, style can cascade through the document tree for specialization effects, it supports measurement in units other than pixels (something that will become more important when operating systems start rendering in a dpi-independent manner).

These advantages make the occasional browser bug not such a big issue.

There are other benefits, but I am almost in shock that table-based designers still exist :(
posted by clord at 4:27 PM on October 8, 2005

Tables are great when you want to create a multi-column layout WITH A FOOTER (or other content block(s) that reside below the columns).

Yes, using CSS is a great idea, and the concept of the "semantic web" is noble. However, when you look at the CSS only solution for a multi-column layout, you will notice that they are indeed HACKS themselves.

The core problem is that the CSS specification (no, it's not faulty implementations here folks) does not state that a containing block must recalculate its height attribute based on the height of the tallest child block that it contains.

What happens is that you are forced to put your floated content blocks into the document, rightmost first, with the main body section tacked onto the end. Or you are forced to use javascript (of all things) to recalculate the container box-height of container so that the footer appears AFTER the content blocks. In the end, they're both bullshit hacks on the same level of using a table to solve the problem.

Don't let any design snob tell you that tables should be ddone away with. At least not until the CSS specification itself is fixed to provide a way to create a properly dynamic layout without resorting to hacks.
posted by C.Batt at 4:32 PM on October 8, 2005

What's validation have to do with accessibility?

You're right, I should have said, "those worried about validation." This is particularly important to those trying to stay in compliance with certain laws. And everything C.Batt said.

Why do you hate America blind people?

I never trust a man that don't look me in the eyes. /kidding
posted by Civil_Disobedient at 4:53 PM on October 8, 2005

C.Batt pretty succinctly sums up my problem with CSS.
posted by cillit bang at 5:04 PM on October 8, 2005

CSS positioning sucks so bad and is so inconsistent that I have never really switched over to it. I'm still happily building table-based layouts in 2005, and using CSS mostly for fonts.

Sure, I've experimented with CSS positioning, but generally I find it far harder to translate designs into code using CSSP than using tables. That's what counts for me.

I don't like being lectured about what tables are "supposed" to be used for. If we only built web sites the way they were originally "supposed" to be built, the web would be hella boring.

"Tabular data" is any data you put into a table. Saying that putting pieces of an image, or other items, into a table is "wrong" is small-minded and moralistic.

I understand the accessibility arguments -- bravo -- but using CSSP will also cause accessibility issues, for people using older browsers. You just can't please everyone. Tables come damn close. If you can't view a table-based website, you're part of a vanishingly small minority.

P.S. I also think frames rock. :)
posted by Artifice_Eternity at 5:25 PM on October 8, 2005

Why Tables for Layout is Stupid.
posted by brownpau at 6:11 PM on October 8, 2005

furtive--I translated the programmer's comments in a web browser once--a relatively simple one intended for i-mode phones. This iterated over every table 7 times (each time using a different algorithm) in order to calculate cell width.

Artificial_Eternity: ""Tabular data" is any data you put into a table"--this is a humpty-dumpty argument. You want to argue that the front page of the American Airlines site is "tabular matter"--consisting of a bunch of sliced-up images--you don't do your own position any favors.
posted by adamrice at 6:12 PM on October 8, 2005

CSS positioning also used to be a lot worse than it is now. Browser support for it was a complete nightmare and that reputation has hung on -- mostly because of developers who played around with it early on and became so frustrated they've never come back. There are lots of non-hacky ways to implement layout (most of the hacks I've had to use were to get freakin' IE to work and play nice).

I have encountered the problem that gsteff mentions though, and that part can be frustrating. Not so frustrating that I'd go back to tables though. I was a web designer for a company that wanted to be Nav 4.x compliant and it was very difficult to have readable markup with so many damn nested tables and spacer gifs. If you want to reposition anything it becomes a nightmare. Or say if you want alternate row colors and the number of rows change because you've added something to the middle of the table, you have to reclass everything.

Ultimately as others have said, using css positioning is just easier to maintain.
posted by Kimberly at 6:21 PM on October 8, 2005

There's a learning curve with CSS layouts, just like there was with using tables for layouts. There's no call for doing tables-based layouts in 2005, and you can do some amazing layouts with just CSS.

Two-column layout with footer. Three-column layout with footer (which works in Netscape 4). Vertical centering with CSS.
posted by kirkaracha at 6:24 PM on October 8, 2005

Has no table-hater ever tried to build a page template for user-supplied HTML with CSS? Can't be done; the "clear" attribute moves blocks down past anything on the page, even outside the containing div element, so you can't put arbitrary HTML in a discrete region of the page and know how it will render - which is the basic operation of template-driven, content-managed, Web applications. Table-based layout aren't going anywhere until the behavior of "clear" is fixed.
posted by nicwolff at 6:42 PM on October 8, 2005

I like the control tables give me. From what people in this thread are saying about css, I am going to continue to steer clear of it for positioning (I do use it for text styles and whatnot).

What we really needed was somebody right from the beginning realizing that there was going to be a great need for people to have flexibility and precision in creating the visual layout of a page, and designing a standard that elegantly met those goals. But that didn't happen.

I don't get all this stuff about content and presentation needing to be separate. People state this like it's an obvious unmitigated good, but I don't see the point. And if I have a database-driven content-holding apparatus, spinning off a simple version of the page friendly to screen readers and the like is pretty trivial.
posted by beth at 7:18 PM on October 8, 2005

and you can do some amazing layouts with just CSS.

For some inexplicable reason CZG is the knee-jerk reaction zealots like point out as a grrreat example of what CSS can do for you. CSS Zen Garden is hardly what I would call amazing--the layout is about as simple as you can get. It's neat that you can re-skin things easily using CSS, I grant you. But nicely Photoshopped header images does not an amazing layout make. The three-column link you provide later on does more to bolster the CSS argument. Unfortunately, the left column overlaps the main center text area about 20 pixels in IE (WinXP). Looks great in Firefox, though.
posted by Civil_Disobedient at 7:40 PM on October 8, 2005

Pretty much everyone has already summed it up pretty well.

I would just like to say that I think a lot of the hatred for tables is actually due to the fact that during the "boom" (say, 1998 - 2001ish) there were a lot of web pages -- usually corporate -- that were designed by people with a background in graphic design and not web design. They used photoshop to design the entire page down to the pixel. Then they would just slice it up and use a giant table to display the pieces as GIFs.

The problems with this are numerous: It's not accessible, it isn't liquid with the size of the browser window, it cannot be resized, it forces the designer's layout on you. Really, these sites were abominations and I suspect that a lot of people in the web design business got really fucking sick and tired of encountering these supposed "web designers" that turned out this bilge.
posted by Rhomboid at 7:55 PM on October 8, 2005

because to use table tags and table elements to compose a page design will not generate well structured html. Well structured html is better then html that is littered with design and "look" attributes. Well structured html should be all about the content and properly describing it. Then you leave the design aspects of the web site purely to CSS.

CSS designing with generic "Block Elements" is also much more flexible then table based design.

HTML tables should only be used if the content is a table. Just like you should use ordered and unordered lists to describe things like "link lists" for your site. CSS will provide you with the flexibility to make that list be presented horizontal as oppose to the default verticle, but the content is better described using list elements.

So much more flexibility is achieved, while at the same time reducing the complexity of everything thus making a much more maintainable web system.
posted by nickerbocker at 7:57 PM on October 8, 2005

tables work fine and there's nothing wrong with using them.

I use CSS in every web page I generate, but still use tables (and even - gasp!, nested tables) for positioning. The complaints about maintenance can be laid to rest with good commenting and use of whitespace. (I'll take the added bloat in trade for knowing it will render consistently in any modern browser.)

If it makes my opinion worth any more I'm a CS grad who sometimes writes intranet based apps for my employer. A lot of my code (PHP/ASP/CGI) is used to generate HTML, complete with ugly old tables. Never once had a negative comment from coworkers or management.
posted by login at 9:46 PM on October 8, 2005

To Hell With Bad Browsers is one of the manifestoes that began this movement; it's still worth a read.

Part of the worry at the time was that there would never be a standards-compliant browser -- IE still held 99⁴⁴/₁₀₀ of the market, Netscape 4 was still on incredible numbers of ancient machines, and web designers worried that the trend toward slice-and-dice image-based designs would lead to the abandonment of HTML completely for Flash or other closed plug-in environments, killing search engines and accessibility. Frankly, at the time, I thought it was an uphill battle -- Zeldman and others seemed voices in the wilderness. To my (and perhaps their) surprise, they had an impact, and today not only do we have much higher browser compatibility with standards, we have a path through the browser and HTML to the dream (some still say fantasy) of the semantic web.

You have to understand it in this context -- it isn't just that tables have their drawbacks, it's that table-based layout allowed broken browsers to proliferate and threatened to sideline the hard work on CSS and XHTML specifications. Tables were just a skirmish in this larger war.
posted by dhartung at 9:58 PM on October 8, 2005

Whoa, I feel as if I'm back in 2003. Or was it 2002 that this argument was going on? People who haven't moved from table-based layouts to CSS-based designs are stuck. It separates the novices from the professionals.
posted by strangeleftydoublethink at 11:51 PM on October 8, 2005

In short: You can do almost everything you can do with tables, plus a whole lot more, using CSS.

However, I say this as I am about to use a simple table for layout on a site. I spent three days testing CSS solutions in different browsers, and the only thing that came close to working was such a hack (seven nested div tags) that I felt worse about using that than writing a simple three-cell table to solve the whole problem. A cross-browser, non-full-page-width, three equal-length column, elastic layout with a footer and no column overlap is possible with CSS, but it's ugly. Oh man is it ugly.
posted by Nothing at 1:28 AM on October 9, 2005

One short answer to this question is "because the W3 consortium says so".

More specifically, it says it here.

"Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media."

The fact that they use the word "layout" instead of the two words "lay out", and thereby set my teeth on edge, is something we're going to have to ignore.

Here's the problem in a nutshell:

Is it wrong to use tables for layout? Definitely. Is it easier? Yes, still, after all these years, a lot easier.
posted by AmbroseChapel at 1:33 AM on October 9, 2005

Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media.

This should be rewritten: tables should not be used purely as a means to layout document content if you want to avoid potential rendering problems to non-visual media.

The difference is subtle, but in a nutshell: the W3 is not the final authority in web design. If you want to do things your own way, fine. Just understand what you're getting into, evaluate the benefits and drawbacks of choosing one thing or denying the other, and balance what you're trying to accomplish with the means to accomplish it.
posted by Civil_Disobedient at 2:10 AM on October 9, 2005

If the table tag and its dependants were called something else, I wonder if this would be such a heated topic. Find a different word to satisfy semantic advocates and half the problem goes away. Encourage better client identification so that pages can be tailored for the agent on the server-side and accessibility problems can be handled much more precisely. I'd rather code my server to deliver entirely different markup to screen readers and the like than rely upon the current mess of poorly implemented standards and uncertainty about how the same tags will be interpreted by a mess of different clients.

In the meantime we have a schizophrenic CSS standard that's trying to do it all and making it much harder for the non-expert to overcome the barrier to entry of making web pages. Years later it amazes me that tools as easy to use as a word-processor don't exist for folks who want to make reliably marked-up pages without taking a six-week course in web-design. Productivity is the forgotten step-child of web development advocacy.
posted by normy at 7:10 AM on October 9, 2005

the left column overlaps the main center text area about 20 pixels in IE (WinXP). Looks great in Firefox, though.

Which nicely illustrates the point that the majority of the challenges with CSS design are due a faulty implementation of CSS, and not with CSS itself.

CSS Zen Garden is hardly what I would call amazing--the layout is about as simple as you can get. It's neat that you can re-skin things easily using CSS, I grant you.

All of the layouts use the same HTML file; the only difference is the CSS. And they aren't the same layout; the navigation appears in different postions and different confgurations depending on the CSS.
posted by kirkaracha at 8:27 AM on October 9, 2005

I'm still working up the energy to give a rat's ass about various high-minded agencies and their standards. I'm still trying to care about "well-structured HTML" and the intense Puritanical demands it makes of me. But then I also struggle to care about split infinitives and the other theoretical sins of grammar.

The point is that even the tackiness and hacks and vulgar touches that gasp! graphic designers bring to the Web have enriched it over the long run, just as the bits of slang and other "improper" English of the centuries have enriched the language. Prescriptive grammarians of all stripes are a bore.
posted by argybarg at 8:32 AM on October 9, 2005

I don't get the whole anti-table thing, either. I mean, I just got done designing my company's newsletter in Excel, and it was so much easier than trying to do it in Word. I mean, trying to get a headline centered over several columns of text was just easier in a great big grid.
I know, it would have been easier to spend a little time getting out of my shell and learning something new, but then I don't like to learn anything new.
And using the right tool for the job at hand is totally out of the question. I mean, I have a screw driver at home, that I can use to turn screws, pound nails into the walls, and even punch holes when I need them. So why would I ever need any other tool?
posted by robhuddles at 9:55 AM on October 9, 2005

Yeah, except this computer doesn't have Word on it. All I could find was Wordpad v0.71.
posted by cillit bang at 11:21 AM on October 9, 2005

Wow, thanks for the spirited discussion. This looks to address what I wanted a lot of the stuff I was interested in.

I get that it's good to seperate form from content in many projects, but wanted a little more depth behind what seems like an article of faith for many designers about the use of tables.

Frankly, as a programmer, the horror stories about changing hundreds of pages when the design changes don't really hold water - everything I do is templated and generated, so to me css and html are *both* largely on the content side.

It looks like some really good points are made on both sides above. I will continue to explore the world of css because it just seems like a much better way to do it. However, I will now not feel like the biggest jerk in the world if I want to just throw some columns in a simple table when that seems easiest.

Thanks!
posted by freebird at 11:37 AM on October 9, 2005

I mean, I just got done designing my company's newsletter in Excel, and it was so much easier than trying to do it in Word.

That may be the case, but you do realize that there are programs out there specifically made to do the sort of thing you're looking for? Word isn't a layout program any more than excel is; it's a word processer. I like PageMaker, myself, but Microsoft Publisher does many of the same things and I believe Adobe has another program to replace PageMaker.
posted by dagnyscott at 12:29 PM on October 9, 2005

InDesign is Adobe's "Quark killer" replacement for PageMaker.

tools as easy to use as a word-processor don't exist for folks who want to make reliably marked-up pages without taking a six-week course in web-design

The last couple of versions of Dreamweaver have been pretty good for creating clean code, and the latest version (Dreamweaver 8) is supposedly good at CSS layouts.
posted by kirkaracha at 12:35 PM on October 9, 2005

It's worth quoting here the words of the guru himself:

"Web Standards" is not a set of immutable laws, but a path filled with options and decisions. In our view, people who insist on absolute purity in today's browser and standards environment do as much harm to the mainstream adoption of web standards as those who have never heard or are downright hostile toward structural markup and CSS.

- p208, Designing With Web Standards (2003)

The book may be 2 years old but the user agent landscape hasn't changed, so this philosophy is still applicable, IMHO.
posted by elphTeq at 4:37 PM on October 9, 2005

Tables are abhorred because of all the above reasons, and more. It wouldn't have been a problem on the scale of what it's made out to be if it weren't for all the damn WYSIWYG editors that used them. Basically every person who could use Word could suddenly make a webpage, and tables were the magic bullet. Need two items side-by-side? Let's hit that table button in FrontPage's menu bar one more time and add a table that's two columns wide. Pretty soon you've got four nested tables that not only bloat up the page, but are not even drawn until the page completely loads.

I think for 95% of layouts, CSS is the better choice now. I haven't put together a page in a while where I haven't had a good example readily available in CSS or even a template I could go use -- and it looks fine in multiple browsers. Besides, we'll have more tools to generate bloaty CSS for us before long.
posted by mikeh at 9:31 AM on October 10, 2005