I used to work reasonably well with designers until CSS came along. Now my writing is supposed to be a soldier in the fight for Web “standards.” Help. My work has to look great in MSIE, and I can’t wait for the other browsers to fix their bugs. So I’m going to use paragraphs and breaks and old unbuggy stuff like that where I need to.
Mark Pilgrim responds:
I used to work reasonably well with Dave Winer until the RSS validator came along. Now my feed is supposed to be a soldier in the fight for “validation” and “standards”. Help. My syndicated feed has to look great in NetNewsWire (according to my site statistics, it has more than 4 times the market share of Radio), and I can’t wait for the other newsreaders to fix their bugs. So I’m going to skip required elements and use invalid XML whenever it suits me, and to hell with the validator, and to hell with these newfangled “standards”.
Jeffrey Zeldman offers some solid arguments against tag soup:
Over the past two years, Mr Winer has repeatedly complained about CSS and structural, semantic markup, and has even asked what is wrong with tag soup. As one who sees the web as a vehicle for writing, Mr Winer should know instinctively what is wrong with tag soup. Tag soup bloats web pages, slowing their delivery for all users and especially penalizing dialup users. Tag soup corrupts data by yoking it to nonstandard formatting instructions. These formatting instructions work in some environments but fail in others. For instance, they get in the way when trying to deliver content to text-oriented devices with small view ports, such as Palm Pilots and web-enabled cell phones. Why should the users of these devices be forced to download 40K of HTML formatting instructions that will not work for them? And then have to download 40K more when they link to a new page? And 40 more on the next?
Those are the key posts. The resulting flame war can mostly be found here (along with trackbacks to pretty much every other bit of blog coverage).
Your site [code] still is signifigantly harder to read, at least for me. I’m constantly cross referencing—HTML to CSS, HTML to CSS, HTML to CSS, HTML to ... When you dissassociate style information, I contend that its really not about the humans editing the file anymore. Its about robots understanding the file. This point is made even clearer by XHTML 2.0, where they remove the style attribute.
This is certainly a problem with CSS layouts—their maintainability can suffer due to the separation of the presentation from the layout (itself the greatest advantage that CSS provides). Tools such as the ViewStyles, ancestors and ShowDivs bookmarklets certainly make this easier but to my knowledge no one has written a bookmarklet that shows the inherited styles for the currently selected element—at least not yet. Pixy’s List Computed Styles comes close, but shows styles for every element in the document all in one big window.
So Dave dislikes CSS because support is buggy, while Sterling sees it as adding extra complexity. Buggy suport is pretty much a solved problem now, at least for most simple layouts—the CSS-Discuss Wiki is accumulating information on how to defeat bugs at a very decent rate and any problems not solved on there are certain to be understood by the friendly inhabitants of the CSS-Discuss mailing list. As for the extra complexity argument, laying out web sites with HTML has always been complicated—take a look at any site that uses nested tables to see what I mean.
In my experience, resistance to CSS seems to come mostly from people who have been creating table based layouts for years. This is unsurprsing—they are being told to throw out everything they have learnt and start with a completely clean slate. I think the real evidence that CSS is a less complex way of laying out pages comes from new developers; I recently taught my girlfriend to design pages (starting from no previous experience) and she took to CSS like a duck to water.