Tables vs CSS: CSS Trolls begone(iamelgringo.blogspot.com)
iamelgringo.blogspot.com
Tables vs CSS: CSS Trolls begone
http://iamelgringo.blogspot.com/2009/02/tables-vs-css-css-trolls-begone.html
72 comments
The way you see beauty in "perfect" code, they see in pure designs.
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.
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.
Agree completely. The author is getting dangerously close to hypocritical by berating CSSers in the way he hates being berated by them.
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.
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.
I think the problem is that doing good frontend is a skill like any other programming skill. If you don't practice you aren't as skilled.
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.
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.
What does "pure CSS" page offer in terms of usability and accessibility that a mixed-use table/css page wouldn't?
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.
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.
In theory, it offers better separation of content from presentation. For example, a news article that renders in one column on-screen and two columns printed. Or that renders as columns for a sighted user but is read aloud in the correct order for a blind user.
It doesn't, not even in theory.
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.
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.
In theory it does. And for simple things, it works great. I often find (and like the author, I assume this is because of my poor CSS skills) that I end up putting a div in a div in a div to achieve the look I'm going for; it's not in a table, but I've added presentation logic to my content, and would have saved 30 min just using a table.
What does "pure CSS" page offer in terms of usability and accessibility that a mixed-use table/css page wouldn't?
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.
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.
I'm not sure pure CSS designs offer much in terms of usability and accessibility directly. It does help mobile devices, but I think that's still too small for many sites to matter. Plus with more devices that have full browsers, this will become less important.
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.
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.
Since, in my opinion, the users of a website determine it's success; most of the things you mention seem irrelevant or otherwise disputable. Do you have any proof to back up your claims that DIV based pages are better indexed by search engines or increasingly cashed as compared to table based layouts?
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?
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?
I agree that users don't care how your site's markup looks like, but there's a second important factor when it comes to finances: developer time.
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.
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.
Thank you, I couldn't have said it better myself.
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. :-)
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. :-)
The author seems to think it's either all tables, or no tables.
I don't think he is saying that at all.
I don't think he is saying that at all.
Nope, doesn't sounds like the tone of the article to me. It seems he merely states it makes no sense to rigidly hang on to "being one of the cool guys" and spend hours, if not days, getting your layout done using only DIVs.
A great summary, Jasber. And with far less profanity than mine ;)
Lets call them zealots since they're mostly not really trolls.
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.
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.
Learning CSS and taking the time to do it right has other benefits also: Redesign is faster since there are fewer elements to manipulate; 98% of (newbie) cross-browser issues arise from excessive markup that's ignored by FF and interpreted correctly in IE; fewer elements also means less "mystery meat" when you start seeing IE vs. FF alignment issues.
RE: 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.
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.
What does the design of google back in 1998 have to do with the inline CSS argument?
I have a big hunch that design decisions at 75% of Alexa's top 20 sites aren't really based on CSS idealogical purity, scalability, algorithmic complexity or back-end html generation issues. I think those decisions are based on plain and simple expediency and frustration. Much like my decision to go ahead and use tables.
I think that's what guided Google's decision in 1998, and I still think that's what guides their decisions now.
I think that's what guided Google's decision in 1998, and I still think that's what guides their decisions now.
What guided Google's decision back in '98 was to deliver the most kickass search engine ever, the sooner the better (I guess). From that point to now it's a matter of perfectioning every single aspect of their creature, to ensure a great UX (therfore fidelization).
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.
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.
You're projecting your own personal issues onto large organizations.
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.
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.
[deleted]
I think the author's point was if you analyze the content of the major websites out there, you'll find that because there is obviously "no one methodology", those who are zealous should now be called "trolls". Enough is enough.
A troll is someone who is intentionally baiting a flamewar. I don't really think it makes sense to call people who voice strong opinions trolls.
Article summary in 3 sentences (apply these rules to whatever you want, not just table usage!):
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.
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.
Agreed, but you forgot a 4th sentence to summarize:
"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.
"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.
Tables should be used sparingly, but there's also cost/benefit to using them. Development time is lower and cross-browser compatibility is increased. The only really bad thing that I've seen about using them is that they can increase rendering time.
"Do your own research (and looking at the table counts of Alexa Top 100 sites doesn't fucking count as research, FYI)."
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.
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.
Even if I concede that it's a damn fine start, it is not research sufficient to jump to the conclusion that (a) CSS layouts are overcompensating (based on a "hypothesis" taken out of thin air) and (b) people who believe using tables for layouts is bad are wrong based on said research.
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.
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.
The fact is, some layouts that are brain dead simple with a table are pretty much impossible with css, unless you start using javascript, hooking onresize etc which gets really really ugly fast.
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.
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.
Did you, by any change, invest any money in "semantically correct" web development? Take a chill pill...
Didn't you get them memo? Comments like this were banished.
I don't read memos and I'm not sure what "comments like this" are.
The CSS Problem has been solved. There are a large number of people in the world who can take any arbitrary design and make it work in all browsers using compliant XHTML/CSS.
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
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
Or
3. You just don't care.
which is by far the most common explanation in all situations of this type.
3. You just don't care.
which is by far the most common explanation in all situations of this type.
I fail to see how that is different than #2? Maybe I should have said "don't want to spend $150".
In my mind this leaves only two defenses for not having a website done in (roughly) proper CSS + HTML
Defenses? It's a crime now?
Defenses? It's a crime now?
Of course not! But talk of zealots and trolls seems silly to me when the issue seems mostly resolved.
> 1. You believe that it is better to layout pages in tables.
Or, you wish to lay things out as in a table, and would like to use CSS to do this, ie:
but in practice you must support legacy browsers (IE6/IE7), so you choose to use actual table tags instead.
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.
Dude what you need in your life is something like malo. It allows the simplicity and elegance of the nested tables paradigm but with out the cruft of using tables! http://code.google.com/p/malo/
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.
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.
Thanks for the pointer to Malo. I have looked at 960.gs and Blueprint as well before I decided to use use CSS Reset and then my own layout using the same technique as 960.gs
After going through blueprint and 960.gs, I settled on malo as well. It's dead simple, light, stable, and can be learned in 2 minutes.
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.
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.
Inlining styles can be a good way to boost performance for webpages that tend to be viewed once and left, like Google or Yahoo's home page.
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.
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.
I'm not a CSS purist by any means but I think heavy use of nested tables can be a real hassle for the visually impaired. I think if you find yourself putting a table within a table strictly for layout, you should at least consider other alternatives.
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.
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.
Am I the only person who finds CSS easier to write and easier to wrap your head around? I don't think I could go back to tables without a significant effort in changing the way I do things. CSS has just become natural. Maybe the author just needs more experience or practice.
I'm sorry but I don't see how you can write an article comparing Tables to CSS and not mention Internet Explorer...not even once! In my experience, the only reason I've resorted to tables for layout is when I need to worry about IE compatibility (well, that and when I actually want a table).
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...
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...
I've always been confused by google's use of tables and inline styles in their homepage also. Is it to shrink the file size and send less over the wire? Is it to maintain support for IE 4 or some other archaic browser?
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.
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.
Tables probably for cross-browser support with minimal code size.
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).
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).
That doesn't shrink the file size, but loading a single file is faster than loading one and the second. What does shrink the file size is getting rid of new lines, tabs comments and so forth. Note how a google result page is a lot of text, but actually typically 10 lines.
For the same reason jquery is offered minified and YUI offers a tool to "compress" javascript and CSS: http://developer.yahoo.com/yui/compressor/
For the same reason jquery is offered minified and YUI offers a tool to "compress" javascript and CSS: http://developer.yahoo.com/yui/compressor/
Is there any reason you can't use an unordered list with one of the pre-made jquery tree plugin's to give indentation, collapse and expand?
http://jquery.bassistance.de/treeview/demo/
http://jquery.bassistance.de/treeview/demo/
It would probably work, but then, you're creating a work-around for a CSS shortcoming with javascript.
How so? You'd be effectively solving the problem using both CSS and JavaScript they way they were intended, as opposed to using tables for layout, which has always been a hack around HTML's lack of any other layout support. Seems like if you're going to reject one approach on the grounds that it's too hackish, it'd be the other one.
Really? You use Photobucket and Rapidshare as examples of sites whose design examples you want to follow?
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'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."
He's not saying they have wonderful design. He's saying that most of the top sites liberally use tables, which is interesting given that they probably have some pretty great devs and an infinite budget.
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'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...
He references Google finance. Google finance only uses tables for tabular data, not layout which goes against his own point....
I completely think this is cheer leading for anti-CSS trolls.
I completely think this is cheer leading for anti-CSS trolls.
as long as it works, it doesn't matter if you use CSS or tables. The end users just don't care.
I'm very wary of people who cling to principles as if they're sacred truths that shall never be broken. I think these sorts of things serve better as guiding principles.
[deleted]
Learn the pros and cons and then use whatever fits the job better.
what? i think you are focusing on the wrong problem people.
[deleted](1)
[deleted]
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.