- There was an article that I was referred to last night when I was discussing issues that I was having in getting the CSS to be behave properly. In banniNation IRC, we had our own little amusing discussion regarding the list. I was pretty much dared to come up with a response list of my own. I know I'm not alone with how I feel about CSS and the snobbery involved in its supposed superiority when it is used as the end-all and be-all for webpage design.
(Read More...)
If free links from showcase sites is a motivating factor in using CSS, then why are you even bothering trying to design a site that can't be discovered on its own merits? CSS isn't the only reason a site can look pretty. But if appearance is preferable to function and content...
Right. You don't have to remember DIV classes for each of those attributes? I'm sorry, but <i> wins over #style { font-style: italic; }
This is where Tables wins hand over first over CSS. You still have to close the DIV tags before those font style tags should end. If you're used to sloppy coding, when you close a table... EVERYTHING inside of it closes. No excuse for sloppy coding, but also... not using CSS in this instance also makes it more resistant to the faults of CSS in general. On banniNation, there was an issue where an open HTML tag in one user's comment affected all the text in the rest of the page because the closing </div> in the comments body for that particular user did not close the existing open tags. </table> would have closed it and that would have been the end of that.
Well defined body tags can slim down a page considerably. If you code things in DreamWeaver or Frontpage, yes, you're gonna have every single line have its own opening and closing tags when you really only need two: one at the beginning and one at the end to close it.
A style.css page is yet another file that has to be hit in order to draw the page you're currently looking at. Often it contains additional information that doesn't apply to that page specifically because you can store multiple pages' worth of style settings in ONE document unless... you have a separate style.css for each page layout, which would defeat the purpose of a single, unified stylesheet.
The issues I had with editing down this blog software within CSS took me 2 days and 7 people helping to resolve... exact same issues I had encountered years before when putting Erasure.org through a site redesign.
CSS has to be exact in the way that you order things for floats and space filling to work properly, and that can take hours of experimentation until you find something that works. CSS is also backwards in the sense that you do not draw the areas in which the items appear (as you would with tables), but you have to draw first what everything else wraps around. Case in point: My sidebar needs to be drawn first so that the browser knows how to render the content area... even though based on the design, the content shows up before the sidebar does.
With tables, everything is contained within its own section and everything is rendered in order, top, left to right, bottom. There is no confusion about how you have to code your page out to make it look right.
3 minutes to do a layout table for an entire page versus 2 days of tinkering to figure out how to get CSS to behave. Yeah. Whatever.
There's so many points here (55) and most are duplicates and filler, so I'm just going to skip ahead to the ones that still need to be addressed without repeating myself. There are also strong points made by other people who have commented within the article's page. I'm trying to avoid repeating their points as well.
Only if the browser supports CSS and implements it properly. This is still an issue. Tables is an older standard and has no errors in renders across browsers. Opera and IE render differently than Mozilla when pure CSS is used. Hacks aren't fun to deal with. Tables render exactly as they should, every time.
Comments like these make me wonder if the author is one of those people who likes to think everyone else is expected to have the latest and greatest support for standards. As if nobody is capable of having anything less than the brand new Proprietary Computer!(tm) that the author owns. Face it, people still use Windows 95/98 Pentium systems.
You mean... instead of HTML, I can use CSS, which is a newer standard that still has implementation issues several years after the fact?
Whoever wrote the article repeats this exact same point 4 more times consecutively down the list. Sheesh!
Just like how people believe "Think(ing) Different(ly)" is a perfectly valid reason to buy a Mac, or to be trendy and believing the hype when buying an iPod, iPhone or an iWhatever.
Which contradicts the earlier point about CSS being easier and quicker to implement. Like I said, even if you're completely sloppy about it... </table> closes all open tags within an area while </div> does not. Within tables, mistakes are also contained within that section, whereas a mistake in CSS can continue to bleed into the rest of the page.
This is the perfect reason to point out why CSS is still a nightmare to deal with. A well-written standard... in design, execution and implementation, shouldn't need "hacks" to make things behave properly.
My other project site, The Anti House Series was designed entirely by hand with tables. The only thing that I use CSS for is to define properties within the tables... such as font styles, sizes, color, borders and backgrounds.
Using PHP, I was able to split all duplicate sections into individual files and call them via includes. These sections only exist once even though they're used multiple times throughout several pages. Since I am not using CSS to draw boxes and define areas... I would say I've done a pretty good job using other, more efficient methods, to generate a template.
Even then, I could opt to completely abandon CSS and set all those attributes entirely within the tables... and that would still work because those settings would be contained entirely within one referenced file via a PHP include.
51: Google knows this:
What a load of hogwash. I can play this game, too:
Results 1 - 10 of about 2,120,000 for css sucks. (0.16 seconds)
Results 1 - 10 of about 2,020,000 for tables sucks. (0.13 seconds)
I guess CSS loses by a slim margin, there.
Of course... my point, in the page comments, was submitted before I wrote this entry:
Gotta say, I agree with that one completely. ;)
Stephan Beal in the comments section makes some very strong counter points to the list in that article. Read those. (Though I had to laugh when rupert mentioned there were 88 errors according to validator.w3c.org on that article.)
(Read More...)
1: You can get free links from showcase sites like zengarden, stylegala, cssimport or cssbeauty
If free links from showcase sites is a motivating factor in using CSS, then why are you even bothering trying to design a site that can't be discovered on its own merits? CSS isn't the only reason a site can look pretty. But if appearance is preferable to function and content...
2: You don’t have to spend extra thought and time deciding on styling the mark up of your document (upper- or lowercase, quotes or no quotes on attributes)
Right. You don't have to remember DIV classes for each of those attributes? I'm sorry, but <i> wins over #style { font-style: italic; }
3: You don’t need to spend extra thought on which tags should be closed and which can (or should) be left open
This is where Tables wins hand over first over CSS. You still have to close the DIV tags before those font style tags should end. If you're used to sloppy coding, when you close a table... EVERYTHING inside of it closes. No excuse for sloppy coding, but also... not using CSS in this instance also makes it more resistant to the faults of CSS in general. On banniNation, there was an issue where an open HTML tag in one user's comment affected all the text in the rest of the page because the closing </div> in the comments body for that particular user did not close the existing open tags. </table> would have closed it and that would have been the end of that.
5: You can save in bandwidth costs and visitors will see them faster by making slimmer pages
Well defined body tags can slim down a page considerably. If you code things in DreamWeaver or Frontpage, yes, you're gonna have every single line have its own opening and closing tags when you really only need two: one at the beginning and one at the end to close it.
A style.css page is yet another file that has to be hit in order to draw the page you're currently looking at. Often it contains additional information that doesn't apply to that page specifically because you can store multiple pages' worth of style settings in ONE document unless... you have a separate style.css for each page layout, which would defeat the purpose of a single, unified stylesheet.
7: Once you’ve practised enough, coding pages becomes a whole lot simpler and faster than any table/tr/td tagsoup
The issues I had with editing down this blog software within CSS took me 2 days and 7 people helping to resolve... exact same issues I had encountered years before when putting Erasure.org through a site redesign.
CSS has to be exact in the way that you order things for floats and space filling to work properly, and that can take hours of experimentation until you find something that works. CSS is also backwards in the sense that you do not draw the areas in which the items appear (as you would with tables), but you have to draw first what everything else wraps around. Case in point: My sidebar needs to be drawn first so that the browser knows how to render the content area... even though based on the design, the content shows up before the sidebar does.
With tables, everything is contained within its own section and everything is rendered in order, top, left to right, bottom. There is no confusion about how you have to code your page out to make it look right.
8: When the coding is faster you can spend more time on thinking about the user experience
3 minutes to do a layout table for an entire page versus 2 days of tinkering to figure out how to get CSS to behave. Yeah. Whatever.
There's so many points here (55) and most are duplicates and filler, so I'm just going to skip ahead to the ones that still need to be addressed without repeating myself. There are also strong points made by other people who have commented within the article's page. I'm trying to avoid repeating their points as well.
21: Your sites are automatically accessible to all kinds of browsers
Only if the browser supports CSS and implements it properly. This is still an issue. Tables is an older standard and has no errors in renders across browsers. Opera and IE render differently than Mozilla when pure CSS is used. Hacks aren't fun to deal with. Tables render exactly as they should, every time.
Comments like these make me wonder if the author is one of those people who likes to think everyone else is expected to have the latest and greatest support for standards. As if nobody is capable of having anything less than the brand new Proprietary Computer!(tm) that the author owns. Face it, people still use Windows 95/98 Pentium systems.
22: Promoting web standards will help your work in the future, not having to code differently to each browser
You mean... instead of HTML, I can use CSS, which is a newer standard that still has implementation issues several years after the fact?
Whoever wrote the article repeats this exact same point 4 more times consecutively down the list. Sheesh!
37: You will belong in a “movement”, make good contacts etc.
Just like how people believe "Think(ing) Different(ly)" is a perfectly valid reason to buy a Mac, or to be trendy and believing the hype when buying an iPod, iPhone or an iWhatever.
40: Strict coding makes you learn to see mistakes quicker
Which contradicts the earlier point about CSS being easier and quicker to implement. Like I said, even if you're completely sloppy about it... </table> closes all open tags within an area while </div> does not. Within tables, mistakes are also contained within that section, whereas a mistake in CSS can continue to bleed into the rest of the page.
44: You can use hacks and techniques with cool names like “be nice to Opera”
This is the perfect reason to point out why CSS is still a nightmare to deal with. A well-written standard... in design, execution and implementation, shouldn't need "hacks" to make things behave properly.
49: You can use basically same markup template for many different websites
My other project site, The Anti House Series was designed entirely by hand with tables. The only thing that I use CSS for is to define properties within the tables... such as font styles, sizes, color, borders and backgrounds.
Using PHP, I was able to split all duplicate sections into individual files and call them via includes. These sections only exist once even though they're used multiple times throughout several pages. Since I am not using CSS to draw boxes and define areas... I would say I've done a pretty good job using other, more efficient methods, to generate a template.
Even then, I could opt to completely abandon CSS and set all those attributes entirely within the tables... and that would still work because those settings would be contained entirely within one referenced file via a PHP include.
51: Google knows this:
* 4,380,000 xhtml better than html > 4,370,000 html better than xhtml
* 206 “xhtml is better than html” > 87 “html is better than xhtml”
* 2,130,000 xhtml sucks < 10,300,000 html sucks
What a load of hogwash. I can play this game, too:
Results 1 - 10 of about 2,120,000 for css sucks. (0.16 seconds)
Results 1 - 10 of about 2,020,000 for tables sucks. (0.13 seconds)
I guess CSS loses by a slim margin, there.
Of course... my point, in the page comments, was submitted before I wrote this entry:
56. You get to make egotistical and holier than thou lists like this one.
Gotta say, I agree with that one completely. ;)
Stephan Beal in the comments section makes some very strong counter points to the list in that article. Read those. (Though I had to laugh when rupert mentioned there were 88 errors according to validator.w3c.org on that article.)
