Do anti-CSS people have a point?

[vgarcia]

ESPN did a nice job on their site but I'm not convinced that they cut down on page size. With a huge CSS file and large amounts of neccesary javascript added to the page I doubt they've descreased their source code size by anything more than 10%. With huge servers running the site I really doubt that they've been saving any money on bandwidth. The bandwidth argument is flawed IMO.

You don't think that even a 10% decrease in bandwidth would result in big savings for a site as popular as ESPN?

Zen Garden and Sitepoint.com's recent CSS design competition had certainly made me believe that complex visual CSS layouts are very possible. In contrast I know that there are some designs and styles that just won't translate. Tables give you much more flexability than a CSS design anyday.

And I think that a sensible approach to design will give you the greatest flexibility. Sometimes tables for layout are needed, I'll give you that (at least they may be with the current limitations of Web browsers; in a year or two this may not be an issue). Flexibility is in the mindset of the designer/developer. Imagine a mix of tables and CSS and how powerful that would be. But if you don't need a table then why use it?

[Zoef]

We don't do good things because God told us that we should do good things, we do it because we think it's good to do good things...
Sort of

Doing good things? I must say, that stumps me. That a choice of tool or technologie somehow seems to have a moral dimension. Faced with a nail, I grab a hammer, for a screw I take a screwdriver.

And I think that a sensible approach to design will give you the greatest flexibility. Sometimes tables for layout are needed, I'll give you that (at least they may be with the current limitations of Web browsers; in a year or two this may not be an issue). Flexibility is in the mindset of the designer/developer. Imagine a mix of tables and CSS and how powerful that would be. But if you don't need a table then why use it?

You hit the nail on the head, Vinnie.

Rik

[jofa]

Easier to maintain (no complex nested table structure), consumes less bandwidth ...
well that's good to me.

"Faced with a nail, I grab a hammer..."
Faced with a layout problem, grab a table ??? Nooo...

[Zoef]

Easier to maintain (no complex nested table structure), consumes less bandwidth ...
well that's good to me.

Complex nested tables are a mess, yes. Spacer gifs are a complete nono. But a nice, lean, hybrid design also has the advantages you mentioned and functions as a stepping stone to a full implementation of CSS.

Rik

[John Colby]

Perhaps not language translation, but choice of language is an issue with accessibility because of visitors with dyslexia or other cognitive disabilities. Granted, I don't think that all Web sites should be written at a first grade level, but the usage of obscure or overly technical terms should be watched sometimes.

To some extent I disagree. If the site is written in unambiguous language, no matter what the complexity of the language and phraseology used, then it is up to users of the site to understand it if it can be presented unambiguously. This is especially true of academic references where complexity of phraseology and "long words" is necessary to economically explain concepts that would otherwise take verbosity and lose meaning in so doing.

However if such a site is being technical for technical's sake, then its time to give alternative explanations. The Plain English Campaign over here is great at reducing jargon and highlighing gobbledegook.

I think here we're in danger of confusing dyslexia, the inability to distinguish written words correctly, with the inability to understand them. If we have to cater on all websites for people with every learning disability then langauage will be reduced. Dyslexia can be associated with learning disability, but not necessarily. Theres list upon list of famous and clever people with dyslexia (and Albert Einstein features, but his biographers disagree - try a google search).

But I feel that this thread is straying severely off topic.

Back to the question, and my answer. Anti-CSS people do not have a point. The technology exists, is proven, enables more than it prevents, so it's time to use it and ditch the HTML tags that that were a hack in the first place as a product of totally unnecessary Browser Wars.

[vgarcia]

However if such a site is being technical for technical's sake, then its time to give alternative explanations. The Plain English Campaign over here is great at reducing jargon and highlighing gobbledegook.

That's more towards what I was getting at. A highly technical document is usually for those who understand them well (i.e. a how-to book about audio captioning for television shows would never be written with novices in mind because it's not a general-purpose topic). I think we're arguing on the same side in different words .

[Winged Spider]

You don't think that even a 10% decrease in bandwidth would result in big savings for a site as popular as ESPN?

That really depends on what they use for hosting. I'm assuming that all major sites have huge amounts of bandwidth at their disposal even their own server clusters. They probably aren't even metered for bandwidth.

[redux]

ok...let's see

1) benefits/ROI
no need to create "printer friendly" pages. easier to offer separate versions of the same page via stylesheet switching. a complete redesign of an entire site takes far less time/money/effort (change css and images, not each and every page). content can be repurposed more easily (and if you're using XHTML, it can be achieved pretty much automatically via XSLT).
yes, it may cost more initially to find a designer who knows his/her way around good CSS based design. little 15 jimmy with his cracked copy of DW down the road won't have a clue. however, the gain is made on larger site. the more pages there are, the less time designers will have to spend getting each and every page's nested tables etc to work...they design a single solid css, and from then on it's pretty much "keep writing structurally correct markup".
when you switch to css, you also do away with a lot of useless spacer graphics, empty rows/columns/cells, etc...not just the <font> tags.

2) does he surf all his pages on his l33t adsl connection, or has he ever tried using a 56K modem, or - god forbid - a mobile phone / pda ?
stylesheets (used across an entire site) are loaded once, then cached. this, combined with the reduction of actual code in the html, makes them faster to transfer. plus, no more spacer gifs etc
will users be able to notice ? on slower connections, definitely.

3) yes, 50% or so is images. that still leaves 50%. on a high impact site with lots of traffic, it definitely adds up quickly. the rest is generic drivel, as it all depends on what market we're talking about.

4) heh...it does make a difference for such little trivial things like "let's move the whole navigation from the left to the right". as for the bit in red...who is he talking about ? has he got any figures to back this up ??????????????

5) hate to break it to the guy, but the browser wars years are over. listing sites that fail validation is not a measure of how useless standards are. without any standards, we'd have "internet for internet explorer", "internet for netscape", etc, and not an interoperable standard.

6) obviously for the one man designer/developer, it might initially make little sense to talk about separation. out in the real world, you have a lot of non-designers having to update content. taking the presentational aspects out of a document means they can get on with their work without fear or danger of breaking the presentation. for the rest, see point 1

7) "most web sites" bullcrap. the rest is drivel, and shows a deep misunderstanding of what tabular data means (or how CMS' actually store page data in a database...in many cases i've come across, only a single column is devoted to the page's body itself, with the other columns containing meta-data - page title, author, appoval flags, etc -, so effectively the page itself is a single blob of information from a table. what you going to do ? a single cell table for each page, just to prove the point ?)

8) has he actually EVER used accessibility technology such as screenreaders ? yes, sure, they can magically infer meaning from an arbitrary id assigned to any of your crappy table elements...
99.99% of the "normal" population ? idiot...
"There is a spell checker and a GRAMMER checker in Microsoft WORD" which he obviously DIDN'T use...

9) yeah, division is just useless...
ok, extremism is bad, for sure. the boxyness of current CSS sites is also a part of the current design trend in general (not just in web...print etc all have seen a return to clean, swiss typography, new minimalism). rounded corners are around the corner (forgive the bad pun) and can already be used in Moz.

10 which goes to show it's not just a mouthpiece for css, but has real world grounding

11 standards aren't always changing, so that's misguided. if everybody had used standards from day one, rather than perverting tags and getting used to bad coding habits, we wouldn't even be having this conversation.

in short, the guy is an idiot. and you may quote me on that. thank you, and good night (can't believe i even spent time working out some counter-points for this drivel)

[redux]

That really depends on what they use for hosting. I'm assuming that all major sites have huge amounts of bandwidth at their disposal even their own server clusters. They probably aren't even metered for bandwidth.

it may come as a susprise to some, but even if they have their own clusters, they have to pay at some point (e.g. the telco)...
no, i'd be surprised if they were metered, but if they have a contract stipulating a certain max bandwidth, they'll be charged more for higher network usage above the limit...

[vgarcia]

the boxyness of current CSS sites is also a part of the current design trend in general (not just in web...print etc all have seen a return to clean, swiss typography, new minimalism).

Off Topic:

I always attributed it to the relative newness of CSS and consequently a designer's inexperience and desire to just get something up. I've seen some very cool all-CSS layouts lately though.

[jofa]

Off Topic:


Mmm, my favourite, the old forgotten <perversion> tag
I think my next hobby project will be a site completely built on <perversion> elements and misuse of css class attributes, and then I will write an article, complaining that css didn't make the structure of my documents any clearer

[jofa]

...rounded corners are around the corner (forgive the bad pun) and can already be used in Moz....

Hmm, boxes with round corners, isn't that a bit out of date?
Or is some kind of round-corner retro trend coming soon?

[redux]

Hmm, boxes with round corners, isn't that a bit out of date?
Or is some kind of round-corner retro trend coming soon?

of course it is...but mr idiot who wrote the rant is obviously a huge fan of 'em...

[redux]

Off Topic:


Mmm, my favourite, the old forgotten <perversion> tag
I think my next hobby project will be a site completely built on <perversion> elements and misuse of css class attributes, and then I will write an article, complaining that css didn't make the structure of my documents any clearer

Off Topic:


if you then make liberal use of the new text-decoration: blink style, i'll be in hog heaven

[John Colby]

I think we're arguing on the same side in different words .

And I think we've been in this precise position befrore.

[John Colby]

Hmm, boxes with round corners, isn't that a bit out of date?
Or is some kind of round-corner retro trend coming soon?

There's been qute a bit of correspondence on Eric Meyer's CSS mailng list about making round cornered boxes in the past month or two.

[vgarcia]

And I think we've been in this precise position befrore.

[BenANFA]

I think the important thing when coparing CSS and table layout is to note the limitations of each method. CSS is not perfect (even if all the browsers implemented it perfectly) and I hope most people here would agrre with that.

CSS is certainly not designed to make multi-column layouts easy (but did I hear that that was coming in CSS 3 ?) as can be seen from the number of threads request help doing basic column layouts.

However tables were not designed to do this either as they were not designed for page layout. There is in fact no designed method of producing a muti-column page, we have always used the what is avaiable in the best way possible.

CSS does have the advantage that although it was not design to support multi-column layouts I suspect it's designers took into account that it would be used to do this anyway so at least it isn't a total flop at doing it.

In many cases CSS does produce more readable mark-up than tables and this is a huge advantage in my opinion.

The only point in the article that is made (badly) that is worth considering is that of cost. At this time why should any company spend lots of money to change a site that already works, even if it isn't standards complient, just for the sake of it. That doesn't mean that if the decide to redesign the site for other reasons (change of corperate image for example) they shouldn't then change the underlying structure of the site.

I think this guy is arguing against something that he thinks is unnecessary. And I know how he feels because I basically felt the same until a couple of months ago DougBTX showed me how to design a portion of my site that did use tables without them. It was only when I saw the results of a proper CSS design that I started thinking there might be something in it.

It was also at this point that I realised that there are a lot of sites that give the lists of CSS properties and what they do and a lot of sites that show examples of CSS layout but almost none that descibe the thought process required to form a CSS design. This is rather different and completely incompatible with the thought process required for a table design.

If you aren't aware of that and try to use the table design thought process for a CSS layout you will end up in trouble.

Tables and CSS both have there place in site design, but you need to know how to think about each of them.

[jofa]

... It was only when I saw the results of a proper CSS design that I started thinking there might be something in it. ...

Nice feeling, isn't it?

I really like your post, agree totally, just one minor objection here: "...the thought process required to form a CSS design." The thought process, what do we want the site to look like?, should never involve the tools, languages etc you will use later, when developing the site.

[firegryphon3207]

I think the important thing when coparing CSS and table layout is to note the limitations of each method. CSS is not perfect (even if all the browsers implemented it perfectly) and I hope most people here would agrre with that.

CSS is certainly not designed to make multi-column layouts easy (but did I hear that that was coming in CSS 3 ?) as can be seen from the number of threads request help doing basic column layouts.

However tables were not designed to do this either as they were not designed for page layout. There is in fact no designed method of producing a muti-column page, we have always used the what is avaiable in the best way possible.

CSS does have the advantage that although it was not design to support multi-column layouts I suspect it's designers took into account that it would be used to do this anyway so at least it isn't a total flop at doing it.

In many cases CSS does produce more readable mark-up than tables and this is a huge advantage in my opinion.

The only point in the article that is made (badly) that is worth considering is that of cost. At this time why should any company spend lots of money to change a site that already works, even if it isn't standards complient, just for the sake of it. That doesn't mean that if the decide to redesign the site for other reasons (change of corperate image for example) they shouldn't then change the underlying structure of the site.

I think this guy is arguing against something that he thinks is unnecessary. And I know how he feels because I basically felt the same until a couple of months ago DougBTX showed me how to design a portion of my site that did use tables without them. It was only when I saw the results of a proper CSS design that I started thinking there might be something in it.

It was also at this point that I realised that there are a lot of sites that give the lists of CSS properties and what they do and a lot of sites that show examples of CSS layout but almost none that descibe the thought process required to form a CSS design. This is rather different and completely incompatible with the thought process required for a table design.

If you aren't aware of that and try to use the table design thought process for a CSS layout you will end up in trouble.

Tables and CSS both have there place in site design, but you need to know how to think about each of them.

That's truely excellent.
The difference between the arguement put forth in that article and the the arguements put out here is this: those people here (in this thread) who advocate not disposing of tables for layout, know how to do table-less design. They've taken the time to learn the ins and outs, to fully understand the limitations and advantages of both methods. They are perfectly capable of combing the two in a myriad of ways to come up with the best solution. The author of the article clearly doesn't. His own misinformed statements and flawed logic gives away his ignorance. He proposes we do away with CSS all together, while the better informed population of Sitepoint proposes that you tailor your solution to the individual situation (for the most part).

[vgarcia]

I really like your post, agree totally, just one minor objection here: "...the thought process required to form a CSS design." The thought process, what do we want the site to look like?, should never involve the tools, languages etc you will use later, when developing the site.

To tell you the truth, my thought process is a bit different now that I've done CSS layouts for a while. I now opt for rules-based design when coming up with new layouts, where your content dictates the best layout, rather than looking at a photoshop template and trying to make my content work with it. I can still take a template from photoshop and turn it into valid CSS and XHTML, but if I have the choice I prefer working around the content first.

[bonkedproducer]

This article is coming from someone that has obviously not taken the time to work with CSS layouts at all. He doesn't even to seem to grasp the concept all that well.

I recently converted my site to a 100% CSS layout, the same look with less bloat and proper formatting - in the weeks since, my search engine placement has skyrocketed, due only to the fact that my articles are now the first thing in my code is the body content - not tons of layout tables for the heading to appear correctly. As far as speed - my benchmarking tests of the old site layout vs. the identical to the user CSS compliant layout is about 80% faster over dial-up and is even noticable over broadband (not that my site was ever "slow" but 2 sec. display time vs. 8 sec. is a HUGE difference) further I reduced the number of server requests for images to less than 20 where the old layout was utilizing 67 sliced graphics to achieve the same look.

This also makes it much easier for me to optimize and edit my page graphics, because using divs with a single background image keeps me from having to slice and size tons of tables in Fireworks because my ImageReady skills suck (Now my Photoshop skill OTOH... .) So development time for me is vastly improved.

We won't even get into the fact that I'm now buliding alternative selectable style sheets for users that don't like the default layout or the text doesn't have enough contrast - or the fact that my blind friends that had limited trouble using the pages before have all commented that new site is excellent for their screen readers or the fact that my site takes up about 30% less space on my server - and since I live with a 10GB p/mnth transfer limit, that my transfers have dropped even though my visitor counts have more than doubled.

This is the worst research I have ever seen in an article, and I've rarely seen anything other than a trolling post on slashdot with more inaccuracy in reporting.

CSS is a tool, tables are a tool, and when you learn to use both tell me how you're on a merry-go-round - it seems to me that if you can use both effectively that you are a more marketable developer with a much more rounded ability to compete.

[Jeremy W.]

The only thing I'll chime in on is from the corporate perspective.

I currently work for a fairly popular site (15M visitors per month), but I've consulted hardware/software for some much larger players (recently Amazon was among them) on just this issue.

Once you get to a certain level of traffic, each Kb counts in 3 ways:

1. Generating each "layer" of code requires measurable amounts of hardware (ie: if you're running through <tr><td>!content!</td></tr> (basically how Amazon's code looks btw, those extra characters and rows and processes take a lot of extra hardware)
2. At the bandwidth level, because believe it or not at some point every organization hits a threshold and needs to upgrade. The longer companies can stay away from that threshold the better.
3. Actual webserver request times. The larger the page, the longer it takes.

I was actually able to help Amazon drop 50 servers through some small code/caching arrangements. I mean, the guys there are complete geniuses (who are, btw, looking at an all-CSS layout), and my help was really minimal, all things considered.

Similarly, you'd be surprised how much $$$ the CSS thing is saving ESPN.

For us here at work, we're working towards a mostly-CSS new version (which Vinnie is helping with). For us it's not so much the bandwidth savings as wanting this site to last long-term. We feel CSS is more stable for the future than an all-tables design, and any changes which do need done will be easier to put onto the production servers than if it were tabled.

So, yeah, from a corporate perspective, the more you can put tables in their rightful place, and CSS to fill the gap (until something better comes along), the better. No, you'd never redesign your site just because of that, but most corps are do for a relaunch in the next year anyways (in fact 90% of the Fortune 500 are, and half of those have contracts being tendered right now).

Just my 2 cents. Not sure I'll have more to contribute so I'll be unsubbing. If I need to come back someone can PM me

J

[bonkedproducer]

Brilliant commentary there Jeremy. I'm impressed that a Sitepoint has been able to avoid a huge zealot pro/con on this one.

Something that most people overlook in table vs. css design is that in a tabled environment for layout - you tend to use a lot more graphics for the same amount of content. It is faster for your server to send one 50k image than five 10k images because you have to wait on the server to request each image with an average of .5 seconds per request (read that on SitePoint awhile back) you can completely avoid the cut and slice stuff that you have to do with a tabled layout with CSS. The other advantage is it's much easier to edit source graphics (graphics are my primary skill set) without having to worry about where slices will occur.

[Steelsun]

I've pretty much stayed out of this, as I am Pro-Table. This does not mean that I am Anti-CSS, infact I like CSS, but not for positioning.

I have seen too many broken pages due to CSS positioning not supporting older browsers such as IE 5 (which is not that old really) and Netscape. While positioning problems can occur with Tables, they are much fewer.

So for the interim, I'll continue to use Tables to get the positioning that will be consistant and use CSS for other parts of the visual aspects of the page.