Tuesday, February 24, 2009

The CSS Holy War

I'm not sure which is more striking, the fact that people are still posting comments on my CSS article, or the degree to which the discussion has come to resemble a religious one. Computer programmers talk about having religious wars about programming languages, but the term is usually understood to be at least partially tongue-in-cheek. I used to think that no one really got religious about these things. Now I'm becoming less sure.

I was really hoping to leave this topic behind but a comment posted today by someone who calls himself Pherdnut just pushed me over the edge. I happen to have a free hour between meetings, so against my better judgement I'm going to take this on yet again.

Did you find the word "impossible"? No, you did not, because it isn't there. What is there is an explicit acknowledgement that all these things are possible:

Of course, all of these things can be fixed. But the point is they have to be fixed!... It [creating a three-column layout that doesn't have one of the many problems I cited] may be possible. I don't have a mathematical proof that it's not.

The problem with CSS is not that it makes it impossible to do the things people want to do. The problem with CSS is that it makes it hard. There is nothing inherently flawed about the CSS approach. The problem is in the execution.

But I don't want to talk about CSS. I want to talk about the tenor of the discussion. Consider this comment:

I recommend CSS Mastery, which gets straight to a lot of the stuff that confuses people about CSS...

I have not read CSS Mastery. I have read a lot of other material about CSS though, including several books, a boatload of web pages, and even some of the original source material. Does it matter that I have not read CSS Mastery? Pherdnut thinks so.

It's by Eric Meyer.

Well, actually, no, it isn't. CSS Mastery is by Andy Budd. Eric Meyer wrote a book called "CSS: The Definitive Guide."

I can assure that he knows a lot more CSS than whoever hacked together those tutorials you linked to.

How can I trust your assurances when you can't even get the most basic facts straight?

(UPDATE: I made an inadvertent but crucial edit in the above exchange. Pherdnut's full quote was, "I recommend CSS Mastery, which gets straight to a lot of the stuff that confuses people about CSS and also the CSS pocket reference which very quickly gets to the point when it comes to the specifics of how things are rendered (or supposed to be rendered) by the browsers. It's by Eric Meyer." The CSS pocket reference is indeed by Eric Meyer. This was simply an oversight on my part. I just missed the second reference, and thought the whole passage was talking about one book. I regret the error, but I stand by the substance of this post.)

But the question I want to ask is not whether or not "CSS Mastery" or "CSS: The Definitive Guide" or any of the other 41,803 results from an Amazon book search for "CSS" is a higher quality source of information about CSS than any of the sources I've actually relied on to date. The question I want to ask is: how is someone who doesn't know CSS supposed to know? Let us suppose for the moment that everything I've read about CSS (including the original source material from the W3C) is crap, and only Eric Meyer (or is it Andy Budd?) can show me the One True CSS Way. How fortunate it is that Pherdnut came along to set me right! What would I have done without him? Among the over 1000 comments that this post has generated in various venues, not a single person suggested either book before now. If not for Pherdnut, I might never have seen the light.

I submit that that in an of itself is a problem. But that's not what I want to talk about either. What I want to talk about is the form of the argument, which is something along the lines of, "Your conclusions about CSS are wrong because you do not have the necessary information."

On its face this doesn't seem altogether unreasonable, but in fact it is a very problematic argument. How much information is enough, and how can you tell? Suppose I read Meyer and I still believed that on balance tables ought to be used for layout. What then? Would someone else come along and say, "Oh, don't listen to that Pherdnut character, he's a moron, and so is Meyer. The person you really want to read is Arglebargle. He'll set you straight."

Notice how similar in structure this line of reasoning is to a truly religious argument: God doesn't answer your prayers? That doesn't prove that God doesn't exist, it just shows that you don't have enough faith, or haven't read the proper holy text. Maybe if you believed just a little harder next time...

Such arguments can never be answered, because there's no way to prove that you've attained a level of faith/knowledge that would falsify the hypothesis. No amount of unanswered prayers will ever disprove the existence of God to a true believer. Likewise, no demonstration of difficulty will ever convince the CSS true believer that there's a problem. The cause will always lie in the person experiencing the problem because there will always be some book he hasn't read or some technique or hack he hasn't mastered.

I think the reason that my original CSS rant got so much attention is not necessarily because I'm right but because I introduced some actual facts into the discussion, and nothing is more threatening to the true believer than facts. Notably, that claim is a hypothesis that can be tested by introducing some more facts into the discussion and observing the responses. Let's give it a try, shall we? Here are some more facts:

1. It has been claimed by the CSS true believers that using tables for layout is bad for SEO. You would think that if this were true, Google would say so on their webmaster guidelines, but they don't. In fact, the only reference to CSS and tables that I could find on Google is this entry from the Google blog:

If you are using a complex, multi-column layout for most of the content on your site, you might wish to step back and analyze how you are achieving the desired effect. For example, using deeply-nested HTML tables makes it difficult to link together related pieces of text in a logical manner.

The same effect can often be achieved using CSS and logically organized <div> elements in HTML. As an added bonus, you will find that your site renders much faster as a result.

Note that this is not an admonition against tables, it's an admonition against deeply nested tables, which is an admonition that I thoroughly endorse.

There's another bit of evidence that the tables-destroy-SEO argument is bogus, and that is that if it were true there would be an absolutely trivial fix that Google could implement: simply standardize a class identifier that indicates that a table is being used for layout, e.g.:

<table class=for_layout_only>...

I submit that the reason they don't do this is because there isn't actually a problem to be solved.

Oh, and if that wasn't enough to convince you that the W3C doesn't agree with the CSS fanatics, check out their quick reference to Web Content Accessibility Guidelines. There you will find a whole pile of recommendations on how to make web sites accessible, including specific recommendations for using tables. There's also this:

Using CSS rather than tables for page layout (future link)

You'd think that if tables were so inherently awful the W3C would have given this item more attention.

You can actually test the effect of tables on accessibility yourself. There are publicly accessible screen readers out there. Pick one and run a table through it and you can see for yourself how bad the "problem" really is.

I'm waiting with bated breath for you to try to write some non-trivial user interaction code with some Javascript (and/or a JS framework), followed by the appropriate posts to reddit and/or comp.lang.javascript. Preferably, you'd say something like "bah, all these feature tests are bunk. you guys should be browser sniffing."

/me pulls out the popcorn and scoots to the edge of the seat. Also, marshmallows, due to the large amount of flame expected.

Just for the record, I have written (and in fact am writing) a fair amount of Javascript, but Javascript isn't nearly as badly broken as CSS is so I don't feel the need to rant about it. (I do sometimes lament that it's Javascript and not Python that is the de facto standard for embedded interpreters in browsers, but I have long since resigned myself to the fact that we do not live in a perfect world.)

I keep a pretty low profile on the internet, and don't waste my time with the religious wars. I have a degree in IT, but I'm basically self-taught (nothing I ever learned on my degree was ever useful outside of the degree). Because of health issues, I had to leave paid employment as a programmer, and started to follow paths that seemed like they would provide interest and income. In learning one web technology I built my first major web application (a bookmarking application that also optionally archived the bookmarked page), at around the time that Delicious was born.

Believing that CSS was the way to go, I spent as much time on the CSS layout as I'd spent building the entire application (including reading a couple of books by Eric Meyer). Finally I decided that CSS was a disaster, and when I went to see how most of the major sites were providing their layout, I found they used tables.

I decided to leave web development altogether and return to desktop application development. There are far better ways to spend one's time than struggling with something as broken as CSS.

For all its success, history will look back on web application development as the biggest hack in 50 years. I will never make the kind of money a successful web app will make, but I enjoy my work, and my level of frustration is a fraction of what it was back then.

http://developer.cmzmedia.com/You can use the web developer Firefox add-on to disable JavaScript and it still works perfectly fine. Are you referring to JavaScript that forces some CSS layouts to work on older browsers? If so, you are saying that we are enslaved by the shortcomings of older browsers that are slowly fading from existence. "Everyone, we must pretend that IE6 is the only browser there is. If you don't agree with me then you don't know what you're talking about."

BTW, valid comments can still be made on posts that are over 30 days old. I always wonder why bloggers think their entry dies after 30 days.

Do you want me to point out more CSS layouts that work without JavaScript or are you afraid to see them?

And if JavaScript shouldn't be used to make page layouts work why are you advocating tables for page layout when tables also were NOT created for page layout? That's inconsistent. "Use hacks to make your page layouts work but only the hack I approve of."

To everybody on both sides of this argument: HTML, Tables, Javascript, CSS, etc are all just tools. For web developers, there is no way to avoid using any of these available tools. Pick the tool that best matches your needs and use it. Quit thinking so much about how imperfect one tool is over the other and just get the job done. If a table does what you need, use a dang table. If you need a style theme, use a darn CSS. Maybe throw in some Javascript to place some menu or tooltip.

It doesn't matter, there is no right/wrong/perfect. As long as your site works, is decently maintainable and meets the customer needs!

> BTW, valid comments can still be made on posts that are over 30 days old.

I use comment moderation only as a spam-fighting measure. It's easier to filter out spam using comment moderation than to have to go back and manually delete it once it's already there.

> http://developer.cmzmedia.com/

Lovely. One column, fixed width. You must be very proud of yourself. Now show us a multi-column fluid layout with dynamic content.

Oh dear, oh dear, oh dear, the comment form at the bottom doesn't look so good.

> Do you want me to point out more CSS layouts that work without JavaScript or are you afraid to see them?

No, but not because I'm afraid to see them, but because it would contribute nothing to the debate. I do not claim that creating good looking CSS layouts is impossible, only that it's hard. At this point in the debate, even if you were able to demonstrate a proper CSS layout that would prove nothing.

> And if JavaScript shouldn't be used to make page layouts work why are you advocating tables for page layout when tables also were NOT created for page layout? That's inconsistent. "Use hacks to make your page layouts work but only the hack I approve of."

Using something for a purpose it was not designed for is not necessarily a hack. The reason Javascript is undesirable is that many users have it disabled for legitimate security reasons. But you can always rely on tables working.

Actually, it's three columns. The front page is anyways. I think you may have only looked at one individual entry. And I didn't code that layout but I do use it for my blog and I have been slowly correcting some of the bad CSS that came with it. That doesn't mean that all CSS is bad. Just shows that some people don't know as much as they should.

"But you can always rely on tables working."

So, you think the BEST way to create a page layout is to use an HTML tag for a purpose for which it was not intended. Great! There is still a shortcoming to what you are advocating. As long as you realize that then great. It doesn't change the fact that many people know how to create non-JavaScript-dependent CSS layouts that work in all browsers and that it wasn't as hard for them to learn how to do so as you are making it out to be. The biggest error here will be you ignoring those sites and the ease with which they were created.

> Actually, it's three columns. The front page is anyways. I think you may have only looked at one individual entry.

I looked at the URL you posted. But I also looked at the front page. We've been through this before: it is indeed three columns, but it relies on Javascript.

> So, you think the BEST way to create a page layout is to use an HTML tag for a purpose for which it was not intended.

That's right, because the ostensibly intended way is badly broken. And it's not just browser bugs. The *design* of CSS is *inherently* flawed w.r.t. layout.

BTW, there is nothing inherently wrong with using something for a purpose that its designers never intended. I doubt Alan Turing and John von Neumann had blogs in mind when they invented the digital computer.

Anyways, my real question is: Do you think tables should be used for layout forever? Do you think we are supposed to act as though browsers will be stuck in 1997 forever?

It sounds like you are saying, "Sure it's not a semantic use of HTML tags but as far as I can tell ALL pages that use CSS layouts need JavaScript, at least I don't know how to properly code CSS, so we are stuck with tables. Not that they are great but that we are stuck with them. They worked in 1997 and some people don't know how to code CSS so tables is the only thing we should ever use for page layout. Don't try looking ahead to the future. Also, ignore the thousands upon thousands of pages that use CSS for layout that DO work. Just pretend those don't exist. And don't tell me about them either. Because if somebody tries to check them in IE6 there's a chance they might not work well. So that means we should never use CSS. We need to stick with the somewhat hacky and definitely non-semantic use of tables for layout." Am I reading you correctly?

For the record, I hate CSS, but Tables aren't so hot either. What this religious war is missing is a good apostate; it's all too easy for table-haters to point to things tables can't do and then say, "See? CSS is superior."

I wonder how far we could get if we designed a skunkworks CSS alternative, one that keeps the good bits of CSS (see below) but throws out the asinine layout model. We could then implement it using a JS library that uses absolute positioning, but responds to window resize events to refresh the layout so it ends up being fluid. We could then set about converting lots of fancy CSS portfolio pages and then show the code side by side and demonstrate once and for all (ha! yeah, I know, wishful thinking) that CSS is a horrible DSL for page layout.

I know some CSS+JS libraries exist for this already, like Yahoo Grids http://developer.yahoo.com/yui/grids/but they weren't designed as *replacements* for CSS, so they don't have the rhetorical weight we need.

Here are some things that are good about CSS:

* Styling. Sure, there's some silliness, like why is it *font*-weight but *text*-decoration, but for the most part getting the text to look how you want is pretty straightforward.

* Metrics. The whole margin-border-padding box model is very elegant.

* Bells and whistles like the myriad border types and text-decorations.

Here are some things that are not so good:

* Inconsistent and confusing inheritance of properties. Think that "C" stands for "Cascading?" Think again! Sometimes you inherit properties and sometimes you just don't.

* Complicated layout, sizing, and positioning rules that all but ensured that early implementations had flaws or inconsistencies.

And of course, the elephant in the room, which is CSS's flawed idea -- ideology, rather -- that layout properties should be declared on the child, not the parent. IMHO, this was the CSS committee's original sin, from which all others descend.

This post is getting too long, but doing something simple like centering should work like this:

Notice how in the first case you only need to specify one property rather than 3? And how if you want to add a fourth child, in the first case it's trivial where in the second two it's difficult or impossible?

Wow. I just ran into this. Quote me in context and attach a link next time you pussy. You leave out all my strong arguments and then misquote me to make it look like I don't know what I'm talking about. I also recommended the O'Reilly CSS pocket guide before stating "It's by Eric Meyers."

If that was an "accident," I can see why you have so much trouble if your reading comprehension sucks that bad.

Oh and for the record JavaScript is far more "broken" than CSS is although what we're really talking about there is that IE isn't supporting the standards everybody else is as always. IE 8 is almost at the place where everybody else was 10 years ago. IE's version of JS is almost its own language.

And no, JS shouldn't have much of anything to do with layout unless it's something dynamic that couldn't be handled with a class change but what they're referring is how much of a pain in the ass it is to manipulate elements in a table layout via the node tree or how the elements relate to each other in an ancestry/familial sense which you of course surely have some awareness of to be a "CSS pro."

Also for the record, IE has almost completely caught up with everybody else on CSS with IE 8. Their version of JavaScript has barely changed in 10 years and they didn't even touch it when they developed IE 8. If you'd done anything even remotely complicated with JS without the benefit of a framework you'd have at least a dim awareness of that too.

I don't know. I haven't thought about it. The glib answer is: no, only until something better comes along. But I'm not convinced that tables aren't the Right Answer.

The problem is that styling applies to elements in isolation, but layout requires specifying the relationships of elements relative to each other. And it's far from clear that separating *that* information from the content is the Right Thing. But whatever the Right Answer is, it's clear that CSS ain't it.

> Am I reading you correctly?

No. What I'm saying has nothing to do with Javascript. It's simply the observation that sometimes you want to say: put these N things next to each other, each in its own containing rectangle, don't let any content flow outside the boundaries of its containing rectangle, and make all the rectangles the same height. Tables let you say that trivially. CSS makes it nearly impossible.

I actually know what you are saying when you point out ways in which table layouts handle some positioning matters better. I have actually presented the same ideas on other boards, although it has largely fallen on deaf ears. As a freelance web developer though I have to show people that I know how to do CSS layouts and that's pretty much all I've done for the last five years. And I have found it to be quite workable. I'm also glad to be doing things in a way that's more semantically correct.

I'm also sensitive in a different way about this whole matter because I have lost job opportunities because people have found instances on my websites where I have used tables to present tabular data. In their mind they dumb the whole thing down to "Tables bad! Hulk smash!" and think that if they found a table on a site of mine that I clearly don't know what I'm doing as a web developer. They don't differentiate between usage of tables for page layout and usage of tables for presentation of tabular data. I have even seen job descriptions that say things like, "If you scoff at the idea of ever using tables then you are the type of developer we need." That's what my blog entry was about and I think you would find reading the whole thing quite enlightening.

Here It Is AgainBut I do think you would stop short of telling someone who has created a functioning CSS layout that they better switch it to tables. You would stop short of that, right?

> I have lost job opportunities because people have found instances on my websites where I have used tables to present tabular data.

Sorry to hear that. But just because there are ignorant employers out there doesn't mean you have to become an evangelist for their prejudices.

> That's what my blog entry was about and I think you would find reading the whole thing quite enlightening.

I'm not sure "enlightening" is the word I would choose, but it made me feel hopeful. I left a comment there, but you hadn't approved it the last time I checked to I'll repeat it here: you present a list of things that are OK to put in tables. But that list looks to me like a pretty comprehensive inventory of everything that can appear on a web page. What are some examples of things that should *not* go inside tables?

> But I do think you would stop short of telling someone who has created a functioning CSS layout that they better switch it to tables. You would stop short of that, right?

Of course. My bottom line has always been: do what works. If CSS works for you, more power to you. But it doesn't work for me, and it doesn't work for a lot of people, and it's not for lack of effort. It's because CSS is b0rken when it comes to layout.

I think I had checked my blog for comments right before you left yours so I didn't notice yours until about twelve hours later. It has been approved now. What's not supposed to go in tables are things that are not being presented as tabular data; and it's true that the vast majority of web developers don't understand just exactly what constitutes tabular data. But just because there are more things that can go in tables than people realize that still doesn't advocate for using tables for page layout. But if somebody wants to do it for a page they are creating I will not stop them. It's just that it doesn't make sense to ignore the many thousands of sites that have a CSS layout that is not broken. Such as this very blog where we are discussing this issue.

Web design tends to be a lot more creative of an endeavor than programming in C/Lisp/etc. What I find surprising in the whole table/CSS debate is how taken people with the idea of "one right way," despite how less structured design is compared with programming.

There may be some good reasons to use a pure CSS layout, but they just aren't compelling enough to forgo an immediate solution. As a programmer breaking into development (using python, django and templates), why shouldn't I structure my page with simple tables, some CSS to make it pretty, and be done with it? I'm assured that whatever data goes in results in a page that is sleek, maintainable, and simple.