

Everything you know about CSS is Wrong - The changes tables layout will bring - jwilliams
http://www.digital-web.com/articles/everything_you_know_about_CSS_Is_wrong/

======
thedob
Great, now we just have to wait until every IE6 and IE7 user has upgraded to
IE8. By then, we'll be on to new browser technologies completely.

~~~
pg
Or you could just use html tables.

~~~
staunch
You could but that would clearly be a very big mistake! Sure it will work
perfectly in every browser and it's really simple and easy to work with. But
it's a big mistake! You'll have to deal with the fact that it's not trendy and
cool. You will be looked down upon by those who are flogging themselves at the
altar of cargo cult methodology. Come to think of it, quite similar to the
situation those of us who still think Perl is awesome face. Try using Perl and
HTML tables in 2008! You won't get invited to any of the cool parties...

~~~
benbeltran
no, it's a mistake because it's semantically incorrect.

~~~
pg
It's no more meaningful to talk about the semantics of html generated by
programs than it is to talk about the semantics of machine code output by a
compiler. Complaining about using tables for layout on semantic grounds is
like complaining about using shift instructions for multiplication.

Semantics applies at the level of abstraction where humans look at something.
That's the fundamental mistake of CSS zealots. Without consciously realizing
it, they have a model of the world in which one is editing web pages by hand,
or at least editing templates that are only a thin layer of abstraction above
web pages. Which is actually quite backward.

~~~
tdavis
I disagree, more or less completely. The semantics of HTML matter to the
following:

    
    
        1. Browsers which render the HTML
        2. Machines, such as search engines, which "look" at it
        3. People who edit the HTML (in the case that it is a 
           template)
    

Whether your HTML is semantically correct, or even stylistically valid,
doesn't much matter to modern browsers because they've been designed under the
assumption that most people will be too lazy or inept or uncaring to generate
"proper" HTML. Obviously, this issue doesn't exist for compilers, where in the
case that a compiler doesn't output proper machine code the program simply
doesn't work.

When this starts to matter, however, is when someone leaves the comfort of
their Firefox 3 on a huge screen and goes to Safari on a iPhone, for instance.
Hacker News, for example, does not scale properly on the iPhone which leads to
unnecessary and annoying horizontal scrolling past a certain nesting level,
among other issues. This is tied to semantics, though whether or not a font
element is used doesn't matter -- what does cause this, however, is the
ridiculous reliance on tables, which obviously aren't semantically proper
since you're not displaying strictly tabular data.

What about these limited browsers, and "machines" like Google? If you want a
sidebar on the left side of your page, with tables that has to come before the
main content. Using proper CSS techniques (semantics of HTML withstanding),
you can place this after the actual content. People with smaller browsers
could view your main content before your navigation with minimal changes and
crawlers such as Google will index your content more accurately because of the
placement of content in the source document. Semantics come into the picture
when elements are misused or not used, such as header elements. These elements
_do_ have meaning to search engines.

How about screen readers and other assistive devices? Many of these take
context clues from the HTML, such as the type of element used to wrap content
and its attributes, as a way to present pages more accurately to the user.
Semantics matter a lot when it comes to accessibility. What about page size?
The more tables you have on a page, the larger that page becomes to download.
Perhaps Broadband is becoming ubiquitous in many places (as far as America
goes, at least in somewhat urban areas), but that doesn't mean that it makes
sense to waste time transferring bytes.

There are a slew of other applications where HTML semantics bleed out into the
real world, such as Microformats and the like, but many of these applications
haven't gained wide-spread traction so probably aren't worth adding to my
argument.

The point being here is, semantics matter when whatever is "looking" at
something cares about the semantics of it. Machine code is very simple: A
machine looks at it and executes it based on strict rules. If a shift
instruction is used, it's because that instruction will (assumedly) give some
kind of performance benefit, not because the machine views it as having a
different "meaning" from any other multiplication method. The fact that you
can achieve the same thing with a table as you can with a div or paragraph tag
doesn't mean it's correct to do so. If everything was _meant_ to work properly
and to its full potential as a table-based element, why have all these other
silly layout elements?

So, at the end of the day, what do we "CSS Zealots" and semantic HTML
proponents get ourselves? Well, we get more maintainable, easier to read,
accessible, flexible, more accurately indexed web pages. And in my world (the
world of skilled web developers) we all still edit our web pages by hand --
using templates that are just a thin layer of abstraction above web pages. The
day you see a META tag that says "Generated by Dreamweaver" on TicketStumbler
is the day Dreamweaver has managed to produce equally good or better HTML than
I can by hand -- HTML which affords all the advantages and luxuries that the
stuff I write does.

Edit: As a final note, I'd like to point out that there is a middle ground
here. You can create generally "good" HTML without spending a day deciding
what a class should be named. TS supports Microformats for events, but running
it through an HTML validator would likely produce some menial errors. I'm not
suggesting everyone put 10x the time into writing proper HTML and CSS to
present it, I'm just suggesting that they put _a little_ time into it -- for
the sake of their site, their visitors, the search engines, and the sanity of
web developers like me everywhere... if I have to write another XPath string
that looks like /table/tr/td/table/tr/td/table/tbody/td[...] I am going to
spit on somebody.

~~~
pg
1\. No. Browsers just have to execute html, not understand it, just as a
processor when it shifts bits doesn't have to know that the purpose is
multiplication.

2\. If you want programs to understand the information on a page at something
above a textual level, the right way to do that is to explicitly encode
whatever you want as xml, not by using divs instead of tables.

3\. I agree: this is the case where you'd want something like CSS. But editing
html by hand is not the only way to get web pages. You can also have software
generate them. And in that case munging the results afterwards is as inelegant
as patching machine code.

~~~
tdavis
1\. Yeah, I guess I worded that incorrectly, though you can see the tie-in
between semantics and how that html is executed (rendered). Using proper
semantics = not using tables for page layout = better rendering (under
circumstances mentioned)

2\. ... so you're saying we should write HTML, then write XML to describe that
HTML? Why not just write HTML which describes itself in the first place? It
seems awfully redundant to do it any other way, considering HTML comes with
all these handy tags which, when used correctly, describe the content already.
Hell, XHML was created as an HTML which conforms to the XML spec for precisely
this purpose.

If you write something like:

    
    
        <body><div id="content"><h1>My Cool Site</h1></div></body> 
    

You've already "encoded" it. If you write:

    
    
        <body><table><tr><td colspan=2><font color="red"><big>My Cool Site</big></font></td></tr></table></body>
    

Then, yeah, you've got your work cut out for you to give _that_ any sort of
meaning...

3\. _"And in that case munging the results afterwards is as inelegant as
patching machine code."_ \-- Right, so your choices are write it yourself or
get a bunch of garbage generated by an IDE or Framework or whatever. If you're
happy with the garbage then you probably don't need to edit it afterwards or
just "edit" it using the same IDE or language or whatever. What happens when
your IDE or framework or language can't generate HTML/CSS to do something you
need? Then you have to start editing that crap by hand... this should
eventually lead to suicide.

~~~
netcan
Personally I think the most important of the anti zealot side of this debate
is the insistence on everything being centred on code being written by hand.

Dingy little WYSIWYG editors, machine generated web pages, & (in this context,
I suppose) software that allows users to generate anything from blogs to shops
to social news sites without any technical knowledge, and all their friends
have probably done more for for the web (& it's accessibility) then standards
have.

We aren't there yet. From online shops to Slinkset, you still need a little
css & html to get you past a certain level of control. But I think it would be
an achievement, if these weren't needed any more & 'view source' got taken out
of browsers from lack of use.

~~~
tdavis
I don't really know what "View Source" has to do with not writing your own
HTML, but I completely agree with your argument. I'm not saying I _want_ to
always write HTML by hand, I'm saying it should be done until such a time that
WSIWYG editors, online web site creators and so forth get to the level that
they generate proper HTML. I don't get any more pleasure out of writing
boiler-plate HTML than I do from writing boiler-plate code for the backend. If
someone has created a framework or library that already does what I need (or
gets me on the road to what I need without getting in my way), I'm certainly
going to use it.

Needing a little CSS and HTML to get you past a certain level is no big deal,
assuming the initial code generated is semantic, (mostly) valid, extensible,
blah blah blah. Having tables nested 5-deep is none of these things.

~~~
netcan
No sorry, I think I as unclear. I meant the opposite. 'View Source' will be
removed because no one should want to view source.

What I was saying is that the ability of non technical users to make sites, no
matter how bad that code, is much more important then anything else in this
debate. Standards should (i think) almost be written specifically for
machines.

Sure, you can think of creating the best possible environment that makes sense
& so that the pages can be used on future browsers & browser like things, but
that is dwarfed by the prospect of letting grandma have a website.

Standards should not be built for hand coders.

~~~
tdavis
_Sure, you can think of creating the best possible environment that makes
sense & so that the pages can be used on future browsers & browser like
things, but that is dwarfed by the prospect of letting grandma have a
website._

I would argue that the continued evolution and improvement of the Web are far,
far more important than letting Grandma have a website. Besides, Grandma can
already have a website -- there are dozens of services out there like Typepad,
Wordpress, Blogspot, etc. which allow Joe Public to have a website -- and he
should be able to have a website, so long as whoever (or whatever) makes that
site uses proper HTML, CSS, and Standards to create it.

Would it be great to get to a point where Standards are written for machines,
I can write some super high-level markup that describes how I want a page laid
out (or just draw it!) and nobody has to write another line of HTML or CSS,
ever? Sure. But it's not going to happen any time soon and pretending like it
has just hurts everybody.

If your framework generates a 30-character ID for damn near every element on
the page (hi, Microsoft), it's Not Good Enough.

If your language generates tables for damn near _everything_ , it's Not Good
Enough.

~~~
netcan
_I would argue that the continued evolution and improvement of the Web are
far, far more important than letting Grandma have a website_

That's a little cheeky. What I was implying that letting Grandma have a
website is more important to the (not as _then_ ) the continued evolution and
improvement of the Web.' Standards are (to that end) important inasmuch as
they allow the guys that make typepad, wordpress & friends to let her do so.
That is the criteria they should be judged by.

------
nocivus
About time. Maybe now a lot of people will stop using tables to define the
site layout :)

I know it can be a pain to style a website with divs, but putting presentation
inside HTML is definitely worse.

~~~
axod
Users don't care if you use tables for layout. Sure, if you're nesting tables
deeply then maybe it's an issue, but this "avoid tables at all costs" is a bit
silly. Especially when the equivalent css is longer, more complex and far less
compatible. Try doing some complex colspan/rowspan type things in css, with
unknown cell widths etc.

There are more important things to work on :)

~~~
Jasber
Initially switching to table-less design is harder. CSS has its own quirks in
every browser that can drive a developer mad.

That being said there's a few very good reasons to use a pure CSS design.

 _More accessible_ : Specifically I'm thinking mobile phones and alternative
stylesheets where "turning off" a table cell completely breaks the design.
This is a breeze with pure CSS

 _Smaller File Size_ : Generally speaking, a site designed with CSS is smaller
than a site designed with tables

 _Efficient Caching_ : External stylesheets will cache speeding up response
time for the user. For an eCommerce site every second is key.

 _SEO_ : Some may argue with this, but presenting important content first is
just one of the many factors involved with on-page SEO. This is accomplished
quite easy with CSS and absolute positioning.

 _Faster Updates_ : I find updating a CSS design to be much quicker than a
design nested with tables. Want to completely change the look of your site?
Modifying only the CSS you can get some impressive results
(<http://www.csszengarden.com/>).

For a programmer the time spent ironing out the initial kinks can be spent
better elsewhere. But for designers its necessary in this day and age to use
and understand table-less designs.

~~~
josefresco
Please not another advocate that uses CSSZenGarden.com as a reference. It's a
great 'proof of concept' but it no longer impresses me or means anything in
the real world.

Show me YOUR site, and how it can be completely changed with just a flick of
the CSS switch and I'll be impressed.

Most (arguably all) CSS designs are built to accomplish 1 layout and 1 design.

Now, for more simple changes, like fonts, colors, and small layout changes CSS
is the tits.

~~~
Jasber
Yes, another advocate of CSS Zen Garden. Its the best available example to
display the power of stylesheets.

Here is my site: <http://www.bradjasper.com/>

As you can see, even though the header is presented first the the stories are
all first in the source. This touches on my SEO point earlier.

 _Show me YOUR site, and how it can be completely changed with just a flick of
the CSS switch and I'll be impressed._

Let's switch the sidebar from the right to the left.

 _#inner { float: left }

#sidebar { float: right }_

Granted that's not completely changed, but its enough of a change to show the
effect I'm going for.

~~~
Hexstream
CSSZenGarden cheats by using images for text...

------
arockwell
I like this, because I always thought that tables for layout were a lot more
intuitive than the mind bending stuff I have to do with css to get a layout to
look right. Semantic markup is nice for the flexibility, but I have always
struggled to understand css.

------
STHayden
IE6 has been phased out fairly quickly for IE7 and I'm sure IE8 will come in
just as fast.

CSS seems like it's here to stay and it will still be around when it's finally
fully implemented.

This is good news for web designers everywhere.

~~~
elai
Lots of corporations still stick to IE6, and the fact that they put it under
the "genuine advantage" wall made it that upgrading to IE7 wasn't as easy &
automatic as it should of been, much to the dismay of the internet.

------
yesimahuman
Thank God. I think CSS wastes a lot of good behavioral design time with the
way it's implemented right now. Hopefully these upgrades will change that.

------
sant0sk1
It would go a long way if MS would retro this into IE7 via a browser update.
IE6 is slowly being moved from, but IE7 will be around for years to come.

------
jdavid
i think the best thing about tables design is that you can design something to
work on multiple platforms and to flow better.

when using tables you are stuck to the resolution you are designing for, but
in a good table-less design you can accommodate a number of form factors,
which is important in the emerging mobile device platform.

------
rlm
This will be good.

I'm really looking forward to the day that IE6/7 doesn't need to be supported
anymore.

------
markbao
And it'll be six years before IE somewhat supports it. And another five for
the majority to upgrade.

~~~
arockwell
The point is that IE 8 does support this. But, it will be at least 5 years
before a majority of users have IE 8 :(

~~~
briansmith
That seems to be an overly pessimistic estimate.

IE7 Was released almost exactly two years ago and it already has 45% market
share (compared to 25% for IE6). Next year it is likely that over 50% of users
will have either IE7 or IE8. I think a slight majority of users will probably
have IE8 in 2010, and a significant majority will have it in 2011. I expect
Microsoft to push IE8 more vigorously than IE7 because IE8 is significantly
more secure (on paper, at least) than IE6 and IE7.

~~~
arockwell
You're probably right. What I really meant to say was that it will be at least
5 years before the numbers of IE6/IE7 are low enough that anyone can afford to
drop support for them. We're going on 7 years of having to support IE6
(although some sites are starting to drop support for it finally).

