Tables vs CSS: CSS Trolls begone
iamelgringo.blogspot.com
iamelgringo.blogspot.com
The way you see beauty in "perfect" code, they see in pure designs.
But there are benefits to their methods. Usability, accessibility, SEO, increased caching and reduced page load times are all side-effects of "pure" CSS designs.
I'd suggest taking the 80/20 approach to CSS. Take the best of what works and then just get it done and move on.
Also, my time limit for CSS problems is 1 hour. After that I use the best solution instead of the perfect one.
The author seems to think it's either all tables, or no tables. From one extreme to another.
I prefer not to use tables for layout, but I will if I have to. :-)
I don't think he is saying that at all.
For me, (mostly) pure CSS is always faster in the long run, but I would never tell another person how to build their site. I usually, however, get pretty cranky if I have to make any layout changes to sites with nested tables that someone else built. But that's my problem, not theirs.
If anything, CSS would be worse as its difficult to render the same across all the different browsers and platforms. With fixed width tables, you can pretty much guarantee your results.
I'm not advocating either and tend to try to use as much CSS as possible but sometimes you spend twice as long to achieve an inferior result. After many years of working with HTML, I think most people find that happy medium.
CSS did a good job of freeing us from layouts that were dominated by concrete layout, stretchy invisible gifs and so on. But CSS does not separate content and presentation. CSS still depends on concrete layout to work. You often can't have a feature of your style that doesn't have a div or whatever attached to it. (The pseudo-selectors are a horrible hack to try to fix this.)
The problem is that we were all collectively duped into not wanting things that CSS didn't give us.
An example: I used to lay out the music and entertainment section of my college newspaper. With CSS, you can't even do a multiple column layout that flows, and PageMaker had that on day one.
Sometimes, I would design a headline that ripped right through articles in the middle of the page. Even diagonally. I can't imagine how you could do that in CSS, without tedious calculations and placing concrete divs into your text.
Even if some of what I've said is possible, very, very few designers seem to be able to cope with this. The evidence is that most of them struggle just to get two-column layouts that don't even flow, if one judges by the number of tutorials.
But another side-effect of many CSS purists is also being an HTML purist. This leads to good semantic practices all-around.
Things like properly annotating title/alt properties. Or attaching checkbox fields to labels. Making sure the tabindex is in an order that makes sense.
As you said, with practice, everyone learns the benefits of each style and develops their own personal medium.
View you page using a screen reader, then ask that question again. There are valid reasons not to use CSS, but accessibility is a clear win against tables, hands down.
While I don't know these individuals, I find that most CSS advocates favor purity in the sense of obeying the rules, not purity in the design sense.
And usability and accessibility, come on! How is a DIV based page more accessible (what do you mean by this anyway?) or more usable then a tabled layout from the users point of view?
Maintaining table based layouts for sufficiently complex sites can be quite a time drain. In that sense, I agree with gigawatt that CSS is much easier to deal with.
I get sick of people complaining about doing thing right being too hard. You wouldn't say someone taking the time to use a relational database is wasted if it meant they didn't try to serve web sites from CSV files.
Everyone sees different aspects of quality, and some of us have spent our time learning how to navigate the inconsistent waters of browser implementation to find the benefits than can be had. If that makes me a CSS troll, then I can live with it, warts and all.
CSS zealots are a lot like TDD zealots. Both CSS and TDD have huge, huge benefits that you shouldn't write off before you actually take the time to learn them. The problem is the zealots talk about them as panaceas and ignore the fact that there is no one methodology that separates the pros from the amateurs. Instead they use their expertise in one tiny niche to prove to themselves how their work is so much better than the majority of similar work due to a few arbitrary criteria. Then they form small self-congratulatory communities to pat themselves on the back about how brilliant they are and how much everyone else could learn from them.
These are the people who you find trolling your blog. Usually they aren't even particular skilled at what they do, which is why they cling to dogma and feel the need to attack other people.
But let me be clear. I haven't layed out a website using tables since 2001 (and I used tables for 5 years before that), once you develop your mental model of CSS (and browser deficiencies) there are actually only a few edge cases where tables are easier. CSS can actually solve 90% of web design challenges more elegantly than tables. CSS makes it easier for designers to and developers to work together (I am both). There are many techniques which are only available in CSS. All future technical developments in web design will be in the realm of CSS.
So it really is worth the time to slug it out with CSS and figure out what's what. That said, web design coding (ie. HTML/CSS) is just one tiny piece of a huge potential set of web development skills. Why does google put CSS inline? Because their design considerations are driven by 100 things that are so far over CSS Zealots heads they can't even fathom it: scalability, latency, back-end HTML generation, js compiled from other languages, etc.
From: http://www.fastcompany.com/magazine/100/beauty-of-simplicity...
But the original [Google] home-page design was dumb luck. In 1998, founders Sergey Brin and Larry Page were consumed with writing code for their engine. Brin just wanted to hack together something to send queries to the back end, where the cool technology resided. Google didn't have a Web master, and Brin didn't do HTML. So he designed as little as he could get away with.
I think that's what guided Google's decision in 1998, and I still think that's what guides their decisions now.
What makes a great UX? A clean UI, a fast service and possibly no hiccups (to make it very short). The UI has changed a lot from 98 to now (check out web.archive.org) and so did their HTML code. A single line HTML page is obviously a conscious decision and so is the inline CSS.
I don't know you, so I have no idea on your experience in this field, but when you get to deal with I'm not saying huge, but decent amount of users you simply have to deal with scalability under every single aspect. If you don't, chances are you end up delivering a crappy service OR you spend WAY more money (bandwidth, cpu power, etc) than you actually need to.
EDIT: google is obviously more than html and css, and if you really want to have an idea on how they are paranoid with performances you should check out their google app engine documentation.
The primary factor motivating any design over time is inertia. When were these sites started? What was the state of the art then? Who were the people that laid the groundwork for the site?
Google is unique in that A) they can hire top experts in any technology they want, and B) their homepage is extremely minimalistic and easy to change. So to suggest that Google does things out of frustration is just incredibly naive.
You didn't seem to get the point of my original post very well. Allow me to paraphrase a little more bluntly:
* You don't need to be a designer to do awesome things and succeed on the web.
* If you are a web designer and you don't know CSS inside and out, then you are a hack whose skills are already obsolete and sure to become moreso quickly.
If big sites do it, it must be okay!
If I can't be bothered to do proper research to learn why one should not use technique X, the reasons must be trivial and stupid!
If I am too lazy to learn how to do something properly, I must justify doing it improperly somehow!
------
I haven't used tables for page layout in roughly a decade. I think I used a table improperly for the first time since then last week, when I was laying out a form and couldn't get it to render consistently after a Javascript update. I don't consider this the end of the world, nor do I take it to mean that CSS is unnecessary and I'm going to go back to pretending it's 1999.
The problem with sensationalist bullshit like this article is people will read it and form an opinion based on it, without doing their own research. Do your own research (and looking at the table counts of Alexa Top 100 sites doesn't fucking count as research, FYI). Learn the real reasons why you shouldn't use tables for layout (or why to adhere to various other web standards). If you don't find those reasons compelling enough to switch, then do whatever the hell you want -- at least you know why you're doing it.
Learn that if you choose to use the proper methods, all the layouts have already been made for you, so you can be as incompetent as you'd like and still layout a page better than Google (and yes, Google are complete shit bags when it comes to adhering to Web Standards. Thankfully, what Google does should be irrelevant to you!) Finally, at the end of the day, just because you use tables occasionally doesn't magically mean CSS IS DEAD. I can't think of a sufficiently funny metaphor for this obvious fact because I am too god damn pissed off.
"CSS is floating DIV tags, that's it."
The author ought to take the time to discover why tables are not used for anything but data display by the so-called "purists". CSS stands for Cascading Style Sheet not for some raging group of evangelists pushing the "right" way to do something. The movement that utilizes this tool is about implementing standards, following rules, and building a more semantic web. DIV is not semantic. Regardless of if you are a designer or developer, first understand XHTML/HTML... certainly before you write about it.
Beyond that, why let the big guys be your standard. iGoogle is no modern marvel of web design or development. I'm guessing the same guy who built the backend of Google finance was tasked with the front; logically he/she would approach that in the fastest way they know. Also note that tables are intended for data. What's finance? Data. They'd better be using tables... just not for layout.
Please, we all came to here to escape individuals like yourself.
Yes. Yes, it does count as research. When you see people who have done what you want to do, looking at how they did it is likely to guide you in how you should do it. That doesn't always work, but it's a damn fine start.
Edit: He also managed to not even properly conduct this simplistic research considering that many of the tables used on the sites were used correctly, e.g. for tabular data.
css layouts can sort of cope if you specify everything in pixels. For fluid layouts they just don't work at all. The amount of hacks and hoops to jump through is just ridiculous waste of time when tables do the layout without any fuss at all.
Do you think the 'float' 'clear' properties in css are nice? To me they are an ugly inadequate hack at trying to specify layout.
Just trying to get a div to vertical-align center is enough to drive anyone crazy.
In fact, there are so many, that the rate to do such a think is between $100 and $200: http://www.google.com/search?hl=en&rlz=1C1GGLS_enUS291US...
In my mind this leaves only two defenses for not having a website done in (roughly) proper CSS + HTML:
1. You believe that it is better to layout pages in tables.
2. You can't do it personally and don't have $150
Defenses? It's a crime now?
3. You just don't care.
which is by far the most common explanation in all situations of this type.
Or, you wish to lay things out as in a table, and would like to use CSS to do this, ie:
#box { display: table }
but in practice you must support legacy browsers (IE6/IE7), so you choose to use actual table tags instead.
Personally I have an abstraction layer which allows me to express my layouts as s-expressions and then be rendered either as "html" (tables, great for quick development) and then rendered to "xhtml" (divs + css) for when I am polishing things up.
Right now it is written in php (yes the s-expression reader and everything, and yes it caches the interpreted files so the overhead is worth it) and I plan on releasing it on googlecode when I am happy with the "interface" of required methods for each "layout adapter".
edit: I forgot to mention malo is like 9 lines of css w/out comments.
Its only gotcha is to adjust the negative margin value for IE6 if you change your default font-size. You can also add your own partitioning percentages. Lastly, the standard triggering of "hasLayout" for floats in IE applies.
http://developer.yahoo.com/performance/rules.html
It seems as if having external CSS is only good for scalability due to caching. If you knew a page wasn't going to be revisited, you would inline it to save an extra http request.
Personally, I like using tables for forms, which makes it relatively easy to line things up for both the labels and the input elements, and it also makes the css rules fairly straightforward to read. I'm sure CSS purists might disapprove, but I think it's a good tradeoff and hopefully not much of an additional hassle for screen reader users.
This is also why the author's argument doesn't interest me in the slightest. Claiming that "all the popular sites" use tables is nothing more than an appeal to authority. Furthermore, it's a blind appeal since the author doesn't even consider the backwards compatibility logic in using tables.
If you're going to tell me why tables are better than CSS, then tell me why tables are better than CSS. Don't just show up to the argument with a bigger gun...
Using one of the css frameworks like yui grids or malo gives you table like designs quickly and easily. Yeah there could still be cases where a table is easier for layout but I feel like there are less and less excuses for that.
For the same reason jquery is offered minified and YUI offers a tool to "compress" javascript and CSS: http://developer.yahoo.com/yui/compressor/
Inline css and javascript for 1 http request instead of 3. Much faster, and less load. The content-length of the google home page is 2752 bytes (gzip).
I'm certainly not a CSS purist, but I'm sure you could've found better reasoning than "all the big guys use tables, so I should too."
I've walked the same road as the author has and currently use tables for layout and CSS for text style, paddings, margins, borders, colors, backgrounds, rollovers...
I completely think this is cheer leading for anti-CSS trolls.