Articles, blogs, and forum posts by CSS proponents are full of complaints about (A) browser suppliers, especially Microsoft, and (B) web developers who haven't dropped the TABLE-based layout method in favor of a pure CSS solution. Most of the browser supplier complaints are related to CSS layout problems and so the two topics are closely related.
I think the complainers are barking up the wrong tree.
I agree with some of the complaints, but there is a better target for their—and my—dissatisfaction. I spent some time thinking about this recently and two questions came to mind that lead me to a different villain.
1. Why are there so many bugs?
The number and severity of the issues varies widely, but all browsers have bugs that negatively affect pure CSS layouts. Browsers are complex applications and so it's understandable that there are bugs. Many old browsers are in need of a mercy killing or a significant update, and that explains a lot of the bugs that lead to hair-loss for CSS coders. But even new and recently updated browsers have significant layout-related bugs or issues. The cross-browser problems related to layout-related features in CSS1 and CSS2 lead me to conclude that those features are disproportionally hard to implement properly compared to the other browser features and capabilities.
I think I know why it's hard, but let's cover the other question first.
2. Why are TABLE-based layouts so common?
Why have so many web developers and publishers chosen to stick with the TABLE-based approach? The TABLE-based approach has some significant problems and limitations, and it fails to deliver the separation of layout and content that everyone acknowledges is an important implementation goal. But if you use the "View Source" command on these sites—some of the more popular on the web—you'll see TABLE-based layouts and/or heavy table use: Amazon, Google, Yahoo, Excite, eBay, and the list goes on.
In addition to the big staff and budget that accompanies publishing one of the world's most popular sites, it's hard to change direction on those big ships and so it may be momentum that prevents them from changing to a pure CSS layout. Still, it stands to reason that if pure CSS layouts are such a good thing, more of those sites would use them.
Despite having about ten years of web development experience, I've been struggling for a few weeks to implement a relatively simple layout. I've read article after article, and I've spent long hours experimenting and testing, but I have been unable to achieve the elusive goal of getting acceptable results across multiple browsers. I rejected some solutions because they didn't produce predictable results as content varied from page to page. I rejected other solutions because they were too complex. In the end, the TABLE-based solution is a better choice for me.
Given my own experience, and the evidence provided by my View Source command, my conclusion is that TABLE-based layouts are common because pure CSS layouts are too hard to implement. In a lessor of two evils situation, most web developers have concluded that the problems of TABLE-based solutions are less daunting that the problems of pure CSS layouts.
To be fair, many sites are implemented using pure CSS layouts. Some of them are impressive and the layout structures are not overly complex. Zen Garden is a great example. The ability to change from Organica Creativa to 45 RPM is awesome.
Who's the Villain?
I think CSS is the villain. It's the reason why browsers are buggy and it's the reason why web developers choose TABLE-based solution over pure CSS.
Let's look at the issue from the point of view of the designer.
The layout features in CSS2 are fine for certain structures. For example, it's easy to float text around an image. Most developers trip over the issue of a floated element extending beyond the bottom of the containing element, but there is a reason for that behavior. It's unfortunate that it isn't easier to make the containing element expand to enclose the entire floated element.
The problem is overall page structure. Most sites subdivide page content into areas such as headers, footers, left and right sidebars, etc. Implementing those structures in CSS2 is unnecessarily difficult. The overall structure of the page is not explicitly defined: it's implicit in the way specific sub-elements are defined. The page designer has to set properties for half a dozen or more rules. The page structure is lost among those rules, and often further obscured by non-structural attribute values. As presently defined, the HTML is also sub-optimal as the designer has to nest div elements until the eyes glaze over. To my eye, the content-meaningless div statements are just as bad as using table, tr, and td elements.
The table, tr, and td elements have a big advantage over the div elements. The structure is more explicit, and the browsers do a better job of rendering the result.
Similarly, the dreaded frameset structures in HTML are much better at representing the overall structure of a page than the CSS2 method. There are lots of good reasons to avoid using frames—they introduce more problems than they solve—but in terms of representing overall page structure they are simpler and more effective.
Not surprisingly, the CSS2 shortcoming described above makes life difficult for browser implementers as well as page designers. The browser isn't told explicitly what the designer wants. It has been given a set of rules that dictate how it should respond to CSS attribute values, and some rules and guidance about how elements interact, but those only address near-relationships. Unfortunately, unrolling the near relationships into the broader definition of the page layout is a very fuzzy process.
If anyone reads this, and that's not assured, I am likely to get flamed for dissing CSS. That's fine. Read on.
What Does the Future Hold?
I am not the only one who thinks something is not right. They probably have a whole set of different opinions and motivations, but the CSS3 standards team is addressing this issue. See the CSS3 Advanced Layout Module. In my opinion, it validates my broad point that CSS is the villain. Whether or not it validates my conclusion isn't important—as long as they fix it.
I have read the 2005-12-15 version of the working draft and I had a mixed reaction. It's great that solutions are being discussed, but the declarative nature of the CSS language appears to be an obstacle to a clear, simple solution.
Keep your fingers crossed.
Of course, once a CSS3 solution is defined, it will take a long time for browsers to implement the new standard. And it will take even longer for people to stop using CSS2 browsers. <sigh>
No comments:
Post a Comment