Wednesday, February 4th, 2009

CSS for Layout. Another Rant

Category: CSS

The old chestnut has come out again, with this rant on CSS for layout which has caused a fuss, and thus a follow up post.

The basic gist is:

While CSS should be used for styling, tables should be used for layout.

The author lays out annoyances such as, CSS floats:

Apparently the order matters. The reason that the order matters is that this layout, like all multi-column CSS layouts, is achieved with floats, and the way that floats get rendered depends on the order in which they appear. So we have not managed to separate content from presentation. How things appear on the screen still depends on the order in which they appear in the content. Worse, in order to be rendered properly, the order in which elements must appear is different from their natural flow in the layout.

And then shows tables and how he prefers them.

CSS purist may poo poo him and say “he is just dumb and doesn’t REALLY know CSS.” The problem though is that most developers run into exactly the pain that he describes. We’ve all been there. It drives you nuts and when frustrated what do you do? You fluster about and change CSS like a mad man until it kinda looks right. And, you never learn what the real problem was, and thus destined to make the same mistake again.

We need something better for layout. And, maybe a touch more than ASCII art layout? ;)

NOTE: There are some amazing things about CSS for layout. The way you can deal with flow is actually quite interesting, so it aint all bad (it isn’t GridBagLayout!)

What do you think?

Posted by Dion Almaer at 7:36 am
73 Comments

+++--
3.2 rating from 46 votes

73 Comments »

Comments feed TrackBack URI

Tables have symantic meaning, not only for screenreaders, but also for webcrawler technologies

Any code has precisely the semantics a reader can pull out of it. Google is actually a prime example of this. The semantics of the anchor tag were not engineered or specified to be a vote of confidence in a given page, but it roughly turns out that way, especially if you do some contextual data mining. Tables weren’t originally intended as a layout tool, but some smart designers realized they could be used that way, and if you’re willing to do a little contextual analysis, it’s not hard to figure out which tables are for layout and which are tabular data.

I don’t understand the argument here, tabular data aside, does anybody have a valid compliant against using CSS?

Yes.

Of the top of my head, things that don’t require a second thought using tables that may be difficult (and are generally more involved) in CSS include:
* Vertical centering on elements with arbitrary heights. Doable if you know the right (and recent) hacks and the containing element’s height, but certainly not as easy as vertical-align.
* columns that need to be the same height. Especially if the defining visual elements of the column aren’t composable into a single background image (say, equal height rounded corner columns — particularly liquid width equal height rounded corner columns).
* certain situations in which you need an element that’s both height/width liquid which will also strictly contain arbitrary content without hiding, clipping, or letting any of it appear outside the border of the element.
* “gap” columns that may have no other width dependencies other than an inversion of other widths (in fact, CSS is sortof a pain for any dimension that’s not either fixed or proportional to a container).
* precisely proportional columns, with fixed-width padding, no extra markup (OK, OK, easy enough with an additional div for each column, but it would have been simplicity itself in CSS if only we’d gone with the MS box model instead of the W3C’s…)

And please don’t respond with the latest clever hacks. I’m aware that you can find workarounds for just about anything, and when it matters to me, I usually do. And if all else fails, you can fix almost anything with Javascript. The point is that everything I’ve mentioned above rarely requires more than a moment’s thought to work out with tables, even if your experience is minimal.

None of this takes away from the real power CSS positioning puts in your hands. But ignoring its limitations and casting aspersions on people who choose other tools is wrong.

Comment by westonc — February 4, 2009

every now and then, a blog, post, article surfaces which question the wisdom and knowledge of the last 5 years with 2 simple arguments:
– Table layout is easier.
– Table layout is faster.

Add to that: table layouts can be used without the any of the implied tradeoffs. Which is why the question persists.

Comment by westonc — February 4, 2009

@Nosredna

Hey dude, I’m sorry if I offended you. You said, “This could just be a matter of tools. I haven’t seen a CSS tool I liked. Make a tool that lets a designer lay things out in a sane way, and have it produce css that won’t make a developer vomit.” I thought you meant that you were using GoLive or Dreamweaver or some other abomination. I didn’t mean to vent on you. I just recently had to clean up some other developers code and it was really nasty. I’m just really tired of people who claim to know (X)HTML/CSS but really know nothing of the sort.

Those Fortune 500 companies that still use tables are probably in the process of upgrading their websites (hopefully). Remember how Target got sued and lost because their website wasn’t accessible? I think most companies are following suit. Tables (for layout) and screen readers don’t mix very well.

I’ve done work on some of those GE and IBM sites, mainly online annual reports. If I would’ve used tables, I would’ve gotten fired and probably never hired in the first place. IBM and GE both have rigorous standards and all pages must be semantic and accessible. Tables are used for tabular data only.

@BenGerrissen:

I’m with you. There’s definitely not a lot of front-end builders who are aware of accessibility, semantics and SEO as it relates to page structure.

Table layouts may be easier. They serve a purpose to those just learning HTML layouts. But, using tables for layout is simply the wrong way to do it.

Comment by ajaxery — February 4, 2009

@ajaxery,
.
No problem. I don’t want to go back to the bad old days of tables. But I’m not happy with css either. I just get the feeling that the css guys are so zealous they’re not even listening anymore.
.
I think it’s really instructive to look where the smart guys use tables and try to figure out why. Here’s what I’ve come up with. I just went back and looked at the “good” Fortune 500 sites, and I looked at some other sites that use just a sprinkling of tables.
.
1) A lot of the pure css sites are fixed, not fluid. They are very brittle. They either don’t let you increase the size of the font, or they fall apart badly when you increase it. Sites with tables are less brittle, since the table adjusts so well to content.
.
2) Even sites that are almost all CSS have certain common uses of tables. The classic is, say, 5 or 6 equal-sized images in a row. Or Twitter’s left/right division, or the small bits on stackoverflow.com.
.
In my ideal world, there’d be a way to split divs into proportional parts, EITHER left or right (not both). That would get rid of almost every “useful” table I see around. Honestly, I think that’s all we need. Should I write it up in a blog entry? Would I get anyone thinking, or would we just get more yelling?

Comment by Nosredna — February 4, 2009

On the IBM site, two increases in text size (Chrome) is enough on some pages to obscure words behind pictures. Probably wouldn’t happen with a table layout.
.
GE doesn’t let most text scale, but some does an overlaps other text, make both sentences unreadable.
.
Not impressed.

Comment by Nosredna — February 4, 2009

using tables for layout is simply the wrong way to do it.

This is a catechism, not an argument.

front-end builders who are aware of accessibility, semantics and SEO as it relates to page structure.

Yourself included, apparently.

Comment by westonc — February 4, 2009

@Nosredna:

I’m curious where you see this (url?). Text-size increases work just fine for me in Firefox for IBM and GE sites. In IE8, I see some issues on the IBM site using ‘Largest’ text size. And GE doesn’t budge at all. I know there’s IE6 limitations on text-size increases when you use ‘px’ instead of ’em,’ but for the other browsers, it should be fine up to a point. But if you zoom the entire page, everything should be fine. IE8, Firefox, Safari and I’m sure other do this by default (ctrl +). I’m sure someone with poor eyesight would opt for a full page zoom over just text, but I don’t know that for a fact.

I didn’t work on these pages at all.

@westonc:

“Yourself included, apparently.”

I’m sorry, what are you referring to?

Comment by ajaxery — February 4, 2009

I’m referring to the misconception that using tables for layout necessarily has a negative effect on SEO, accessibility, and semantics. You implied that anyone who’d use table for layout is unaware of these effects. I haven’t seen any evidence or argument that supports the idea these effects are a central issue.

Particularly SEO. No reliable source of information I’ve encountered has gone beyond suggesting that specific semantics (title, headings, links, in some situations alt text and title attributes, a few other very specific tags) and well-formed markup have real impact on the searchability or ranking of the site.

Semantics I’ve addressed in a number of comments above, and I get mixed reports about screenreaders (including second-hand remarks from actual blind people stating that *frames based* sites of all things are actually an advantage), and as I said earlier, even something as simple as Lynx has been able to work with the dichotomy between different types of tabular markup as far back as 10 years ago. (see http://lynx.isc.org/current/README.TRST )

The bottom line seems to be that despite a lot of handwringing over the repurposing of tabular markup, it doesn’t seem present a real obstacle in practice.

Comment by westonc — February 5, 2009

@ajaxery. I was using Chrome. Firefox’s scaling is very nice indeed. Still, table based layouts are usually more robust with magnification of text. And we often end up with fixed, rather than fluid, designs with css. And we often get fonts that won’t size.
.
I’m hearing that devs love css, but I’m seeing limited designs as a result.

Comment by Nosredna — February 5, 2009

Sometimes, while trying not to use tables, we end up using unsemantic wrapper divs or get a pseudo-table out of a series of ul elements or divs, etc, which is also unsemantic.

I think tables are great.

Comment by drewlesueur — February 5, 2009

Hmmm… I think that CSS is great at styling documents, thats what it was invented for. However a PAGE is the union of the DOCUMENT (the content) and the LAYOUT (the navigation and overall page layout). The most semantic solution would be to separate the layout elements from the content. I am currently experimenting with a system that applies the layout (table layouts for simplicity, reliability and lack of gotchas) in javascript before the page is rendered. So, the HTML sent over the wire is clean and table free, but the layout (using tables if you want) is applied client side. Thus search spiders and screen readers still see the nice semantic document, but browsers see the nice layout… Interesting idea?

Comment by aljames — February 5, 2009

The false dichotomy between CSS and tables is not the issue here. The issue is that you’re asked to build a house, and you get to choose between a crooked hammer and a bent chisel. Both tools are sub-par compared to other development platforms.

Comment by Joeri — February 5, 2009

Here are a couple of blog posts I wrote on this.

1) Why neither CSS and tables are the right job for layout: http://onewheeledbicycle.com/2009/02/05/page-document-layout/

2) My ideal solution (that will never happen):
http://onewheeledbicycle.com/2009/02/05/html-layouts-ideal-solution-idea-1/

Comment by aljames — February 5, 2009

Joeri said:
The false dichotomy between CSS and tables is not the issue here. The issue is that you’re asked to build a house, and you get to choose between a crooked hammer and a bent chisel. Both tools are sub-par compared to other development platforms.

And while the crowd that stands for all things goods cheers, “crooked hammer” and shuns “bent chisel”, the crowd that stands for all things logical asks, “what benefit is there of using top-grade concrete when your building a house on shallow foundation.”

Comment by Jordan1 — February 5, 2009

aljames, great idea. But do you serve something else for people without JavaScript?

Comment by Nosredna — February 5, 2009

Just one word: XUL

‹hbox› and ‹vbox›, along with the ‘flex’ parameter, beat your puny tables or CSS hacks.

Comment by nixar — February 5, 2009

@westonc:

I agree for the most part. I guess I was trying to say that tables are generally bad for accessibility. Although from what I understand, most screen readers are highly customized based on user preference. There may be a tables-based algorithm that deals with them just fine. If you look at it logically, the screen reader would read the site from the top down. It would expect there to be header tags for each major section. Starting from the top, that would be page title, then page navigation, then page content, then a sub-nav (if present), then the footer. Usually people would tab through these sections very fast to find what they are looking for. I personally don’t think tables work well with this approach.

Maybe when I’m 80+ years old and blind, I’ll finally understand.

Comment by ajaxery — February 5, 2009

link at the top of the article is broken…

:)

Comment by samuraixp — February 5, 2009

Document looks like this (visual order):
1.) Portal navigation
2.) Banner (with page title)
3.) Site Navigation
4.) Content
5.) Banner adds.
6.) Footer (disclaimer/privacy etc)

More solid to do this with tables.

However, for better SEO rankings (of your entire sites content and not just the frontpage!) it’s appearantly better to have the following structure (SEO Specialists hired by clients frequently demand this):
1.) Page title
2.) content
3.) Site Navigation
4.) Portal Navigation
5.) Footer
6.) Adds

SEO is not just about getting your website up high in search results on the obvious topics, but to push all your site’s content pages up high on the search listings. The visual presentation and interface, is not the logical order.

This is moderatly easy with floats whilst still keeping your layout grid and content components decoupled. This is also doable with tables, but the means of achieving this makes the use of tables redundant to begin with…

Also when you work with portal or complex cms systems, you get several layers of HTML, your layouts gets cut up into pieces and each piece will be seperatly maintained and changed over a period of time according to the customers whishes. I’ve seen it all too often in my career, that table layouts actually cause so much maintenance issues in these kind of environments, it actually doubled or even trippled the workload. Whereas with CSS, all your content components are portable and exchangeable by default (unless you’re really bad at CSS/HTML).

Another reason not to use table layouts and designers will most likely agree with me, is that it makes it very hard to theme your pages. If you use CSS layouts, you can just make a new stylesheet without touching your templates and basically reorder the visual presentation. If you use tables, you’re pretty much stuck to the dictated table order and can only theme your pages by creating new templates and restart the whole frontend process all over again. This was the whole point of Zen Garden…

The number 1 reason imo. not to use tables, is that it prevents you from actually learning CSS well. Everyone can write HTML and CSS, but it’s like chess, it takes dedication to master it.

Tbh… I want you all to keep using tables… It makes guys like me make the big bucks… So… erm.. proceed and forget what I said…

Comment by BenGerrissen — February 5, 2009

If a layout basically IS tabular, then a layout who’s elements stretch to accommodate content, and to match their neighbours (two big capabilities of tables) is needed.

That’s why CSS is getting display:table display:table-row and display:table-cell.

Comment by ExtAnimal — February 6, 2009

It’s true that when you haven’t dealt with CSS much, it can be nearly impossible to accomplish what you want. However, tables aren’t nearly as flexible as CSS. With CSS, I can make a three column layout with a header and footer and let the content order be logo and site info, center column, left column, right column, navigation (displays in the header), and footer. You could never do that with tables.

Maybe more projects should hire capable front-end developers who know the ins and outs of browser support and CSS quirks like the back of their hands.

Comment by NatalieMac — February 6, 2009

CSS… tables… WHO CARES? Aren’t we all doing our layouts in Javascript these days anyway?!? :)

I’m currently working on a massive project using Ext JS as the foundation and it’s amazing just how little HTML and CSS I’m actually doing now versus what I was doing previously. Oh, there’s of course bits of CSS sprinkled in, but it’s largely to do true styling, i.e., colors and fonts and that stuff. Hell, I’d go so far as to say that the way we’re using CSS now is *MORE* correct in terms of what CSS is supposed to be used for than what we were previously doing when we were doing layout with it too!

Isn’t this the future that makes the CSS vs. tables discussion kind of superfluous? I say that only half-jokingly… obviously there’s plenty of need for web development where Javascript isn’t prevalent, but let’s face it, devices of *ANY* sort that don’t fairly fully support Javascript and associated Ajax techniques are shrinking in number by the day. Hell, the otherwise piece of crap PocketIE I carry around with me on my phone is more powerful and feature-rich than any browser that was available to me just a few years ago on my PC! That situation is only likely to improve as time marches forward.

I say we all adopt a good, solid RIA framework, Ext JS being by preference but you can choose as you see fit, and stop having this CSS vs. tables debate every few weeks :)

Comment by fzammetti — February 6, 2009

CSS… tables… WHO CARES?
Goverment institutions, Knowledge centers, Enterprise and multi-national companies, basically any client with huge ammounts of data which needs to be accessible by their target audience.

Aren’t we all doing our layouts in Javascript these days anyway?!? :)
Would love to, but javascript layouts to the extend of Ext JS and even ajax driven websites turn out to be very bad for SEO and accessibility unless you make an alternative, in which CSS becomes a major factor.

Tbh. client sided XML and XSLT can easily provide the solution if developed and supported more with search engines jumping on the bandwagon. And even ajax can be accessible in an XML/XSLT driven website as long as you use the links in the XML and not embed data providers in your javascript.

I really need to look into XUL…

Comment by BenGerrissen — February 7, 2009

Leave a comment

You must be logged in to post a comment.