CSS vs. Tables: Maybe the design is to blame?
There's been some backlash lately against CSS, and some of it seems so well reasoned that even I find myself wondering if tables are really so bad after all. From giveupandusetables.com, which says the maximum time to spend before abandoning CSS is 47 minutes, to the well-illustrated blog post by Ron Garret, the general argument is that CSS isn't up to the task of faithfully reproducing elaborate designs cross-browser in an acceptable amount of developer time. In his post about Garret's article, Dion Almaer at Ajaxian opines:
CSS purist[s] 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.It seems that while developers are thinking about sacrificing web standards for the perceived simplicity of tables, the viability of the design rarely enters the debate, and that's a shame. In my experience, some of the most difficult designs to produce using CSS were fundamentally flawed from the get-go, created by designers who failed to grasp that the web is not like print. The web is not like print. In print, designers have near-total control over the output, because the number of new "pages" -- items of content -- is limited by the cost of printing. If a print designer wants text vertically centered in a fixed-height column, or two columns that are exactly the same height, or rounded corners with drop shadows on top of gradients, there's no reason they can't have that. The cost of printing is sufficiently high, and print graphics programs are sufficiently sophisticated, that making those design decisions has no impact on the marginal cost of production. On the web, the marginal cost of creating a new page of content can be approximately zero, but to achieve that we must build pages that adapt to unpredictable content and unpredictable users. If we don't, we won't realize the economies of scale that the web has to offer. The tradeoff for that infinitesimally small marginal cost is that the rules have to be different, because the cost of implementing those print-centric design decisions is inordinately high. Instead of sophisticated graphics programs, the web has mere humans to turn PSDs into working pages; instead of content created by experts and pored over by editors, the web has volumes of user-generated content, and the ability to change it on a whim. On the web, equal-height columns will cease to be equal height when the content changes; vertically centered content will outgrow its fixed-height bounds; and rounded corners with drop shadows on gradients can't possibly be worth the cost of producing them. These are not problems with CSS that should be solved with tables. They are, fundamentally, problems with the design. When I talk about this to other developers (and any designers who are willing to give me the time of day after I'm done pointing out how costly their design will be to produce), I make the analogy that it's just as absurd to impose these print-centric design conventions on the web as it would be to use holograms for every picture in a magazine. Sure, you can, but that doesn't mean you should. So what's a web developer to do? When designs reach the desk of the CSS developer, more often than not they've been through so many rounds of review, revision, and approval -- by people far-removed from the realities of the web -- that the developer has little choice but to toil away at reproducing them faithfully. The best defense may be a good offense, which is to say, the burden is on you, dear developer, to educate the misguided designers. Here are some tactics I've used:
- Impose yourself early in the process, insisting on wireframes and information architecture documents (even if they're just sketches and an outline). Identify potential problems early on, but don't become a naysayer -- make sure you offer ideas, not just criticism.
- Push back -- gently but firmly -- on design decisions that have the potential to cause problems down the road. Ask lots of "what if" questions and insist on answers.
- Be honest about how long it will take you to accomplish a design -- with yourself and with your boss or client -- and identify opportunities to make cost-saving changes to the specifics of the design without changing its spirit.
- Have examples at the ready of similar problems solved in more web-centric ways. The Yahoo! Design Patterns Library can be an excellent resource for this, but look also to other sites in your industry or genre.
Useful things:
18 comments
Design works best when it works with the medium, not against it; the challenge is to work out what the medium is and to communicate this; to make sure that its constraints are understood before you get to the stage of 'make it look exactly like this'. It needs engagement rather than just throwing designs over a wall. It also needs imagination: what will this design look like when the title is twenty words long rather than three?
I'll definitely be using your apposite expression, 'the marginal cost of creating a new page of content can be approximately zero'.
Html/css in its current form is broken and needs to change, and it needs to change fast. Otherwise we risk it being supplanted by other proprietory systems such as flash and silverlight.
I have found that most of the people who complain usually have only a cursory knowledge of how the Internet works now (compared to how it worked in 1998, when "meta keywords" counted). That or they've simply not studied CSS. Maybe they looked at some code examples and went from there without looking at any good books or reading any good blogs on the topic (for which laziness is to blame, surely, and I can't click two links without hitting one or the other).
I also hear these complaints coming from people who have their own small sites that they built 5-10 years ago using a WYSIWYG, feeling shortchanged that the Web, its users, its search engines, its traffic, are moving on ahead of them. This is like someone sitting at their home computer sad that they can't print their memoirs from Word directly into a bound book on their desk. It takes a professional. Always has, always will, and that is how it should be.
If the Internet has shown us anything, it's that amateurs have to be curtailed and reined in. You can't slow the pace of progress because some people don't want to study or ask questions.
CSS has problems, yes, and we're using hacks to make it work at times, true, but tables were nothing more than hacks even back in their heyday, so calling CSS-based design ineffective because it uses hacks is the pot calling the kettle black.
But we are working toward a hack-free day when anyone can go online, even the blind. We're going where tables couldn't. And I think tables would have wanted it that way.
Let them go. Let them go...
Humans should be able to do with technology what they will, not the other way around. If there is a problem with doing what we want, the technology should adapt, not the other way around. Yes, the web isn't print, and print isn't the web. However, if I want rounded corners, for whatever reason, shouldn't I be able to have them? My desires for some design element should trump the (in)ability of the current technology to accommodate me.
The web is such a technological advance from anything we've had before that I think it's tempting to say "I should be able to have whatever I want! Computers are magic!", but it's a medium just like any other. Think about the limitations of print, of film, of sound, and think about how long it's taken to whittle down those limitations. Somehow I doubt the director of Casablanca stomped his feet about the fact he couldn't make the movie in color.
Web developers are working every day at overcoming some of the existing limitations of the web -- see sliding doors and all sorts of other CSS patterns that have arisen in the past several years. In the meantime, designers would do well not to stop pushing the limits, but to embrace the input of the developers who will have to produce their design and realize that the vast opportunities of the web come with some practical limitations.
Don't be a fool. Tables are part of the standard.
This is why tables seem strange when coming from a DTP background: There is no need for that kind of adjustable grids when working with paper, since the paper won't change dimensions. The web is different.
The adjustable-grid model of tables is also included in CSS through the display:table property, but that is not supported by Internet Explorer. This is the reason many choose to use markup tables - to get a more flexible design better suited for the web. Due to the limitations of Internet Explorer we have to use presentational markup to achieve this.
I like your take on design and its impact on dev time. As F2Es become more senior, I hope they will be included in the decision making process more. Then we can have more input into the design earlier.
-- Stubbornella
Unfortunately, a table-based layout is still the only layout that displays correctly across all mail applications...unless I'm mistaken?
As Stubbornella explains you have to work within the realm of each medium. As they say in Python Simple is batter than complex, complex is btter than ecomplicated. Mark up of tableless layouts is simple. Css is complex but table based layouts are overly complicated. I imagine that if they remade Casablanca in colour it would be a flop, if they colorized it it would lose its magic. The way forward is to make css that need not be added (in most cases - and when it must be extended its clear how to do so) this eases the maintence of content and templates too.
Don't build for the past but prepare for the future, whilst working within the present. By which I mean sure IE6 is a pain - its a dying breed. IE7 is a headache but will soon be a dying breed too & IE8 is much better. Compromises will always have to be made we should learn which ones to make and where - I imagine that print designer have to make them also (butI don't know enough about print to say whay they would be)
What few seem to realize is that no standard or technology is perfect and we should only play the cards we have in our hand (that means not betting on things that may never happen).
So how do I see it? Play to your strengths not your weaknesses. No matter how many fans of CSS will tell you that CSS is a one-shoe-fits-all solution, it isn't.
A reasonable developer will look at both CSS and Tables and know where to use each and they *will* use both if they are smart.
And before anyone pipes in with "Yeah your right. a good dev will know what each is for. Tables are for *tabular data* and CSS is for nice layouts"...
Let me remind you standards (not the W3C kind, but the 2/3rds majority kind) determine what a hack is and isn't a hack. This is unrelated but look at the C language, it's one massive hack atop Assembly, and C++ is one massive hack atop C.
It is not committees, or corporate giants that set standards it is the people that utilize the inherent technology. Use dictates purpose. At one time tables where for tabular data. Now many, many people use them for layouts. There purpose is now for layouts.
"These are not problems with CSS that should be solved with tables. They are, fundamentally, problems with the design."
I think you are both wrong and right at the same time. They are not problems that should be solved with tables. I agree wholeheartedly. But they are not problems with the design at all. The problem is that CSS is deeply flawed.
You say that you cannot have rounded corners, with gradients and drop shadows on the web. I say, why shouldn't you? It is one thing that it is impractical because of the limitations of CSS (creating images, wrapper div's etc), and the other to say that this is something that is not possible on the web.
CSS is the best we have right now, but it is not at all the one size fits them all. At the time it was created, they actually never intended it to be used for layout. The first spec said somewhat along the lines of "make those li elements green", and similarly simple tasks. Those simple tasks they accomplished really well, but designers want to create designs and layouts that push the limits of the language.
Why can't you vertical center something? Or have equal height columns? Or gradients, rounded-corners, effects (shadow, glow, etc), transfer modes, doing something like "100% - 50px"? I could go on... those are not limited by the medium, just by the specifics of the technology.
For those who say that those banging their heads against the wall while trying to get CSS to behave should learn more CSS, my response is that a language should be designed to be easy to use, not criptic and hacky. And that notion of it being good if it is complicated because of amateurs with poor taste is sheer nonsense: you will always have amateurs, but if the language is harder, even good designers will be limited.
Finally, every existing technology has its problems. HTML+CSS is no panacea, and neither is Flash. I wish for something completely new to replace them, to allow us to do all that we are longing for.
Cheers
Miro
