Problems with CSS layouts: bugs and anomalies

In this article from O'Reilly is condensed a good approach to problems with CSS layouts:

To fully understand CSS layout, you must not only be aware of it's benefits, but you must also be ready for some problems it presents. Most of these problems stem out from CSS's immaturity. Yes, the recommendation itself has been around for a while, but CSS layouts are only recently possible, and even more recently taken seriously by developers. Expect this immaturity to result in problems, such as:

  1. Layout limitations: The fact is that CSS layout will not currently allow you to do everything you can do with tables. This can be a real frustration, and has stopped many people from exploring what CSS can do. (I'll show you in this article that CSS can do quite a bit.)
  2. Slight differences in browser display: CSS is difficult for browser makers to implement, and the W3C recommendations can be vague and confusing. So you can expect even the most recent browsers to behave differently when dealing with some aspects of CSS layout. Keep your layout simple enough and you will likely get a nearly identical display in Opera 5+, NS6, and IE5+. But as your layout increases in complexity, the odds that different browsers will render pages differently also increases.
  3. Difficulty in switching from tables to CSS: For designers and developers accustomed to wrangling tables, using CSS for layout can be a confusing change. There is a "table mentality" that we developers have taken on over the years, and we are in large part unaware that it exists. Some take offense when this is pointed out, complaining instead that CSS is just difficult and non-intuitive. But if you were accustomed to driving a car with a steering wheel and you were then asked to head out on the freeway in a car steered with foot pedals, you certainly wouldn't be offended at the suggestion you had a "steering wheel mentality." The fact is, we are generally comfortable with tables. CSS layout is different, but we must not confuse differences with increased complexity.

So then, with all these problems, why use CSS? You'll have to make this decision yourself. Many people I know use CSS layouts for personal web projects, but still resort to tables when working on commercial sites. The time is coming when CSS will be suitable and preferred for all site layout, but many reasonably argue that the time has not yet arrived.

I use CSS because I believe in the fundamental principle of the separation of structure and presentation, and I am willing to put up with the problems CSS presents as I look forward to a time when CSS is as robust and simple to implement as tables are today. That time will come, and the web will be a better place for it.

Problems usually fall into two categories: bug and anomalies. Bugs are explicit violations of the CSS specifications. For example, all the rendering inconsistencies of IE 6 and 7 due to the hasLayout property are clearly bugs. On the other hand, anomalies are just different interpretations of the specifications. Different interpretations occur either when CSS specifications are not clear on a topic or when they don't say anything at all. For example, table rendering is a perfect example of the former case, whereas form elements is a good example of the latter.

You should always read carefully the CSS specifications to make clear to yourself when you're dealing with a bug or an anomaly. For example, negative text indentation works correctly in all browsers except that it fails in IE 6 and 7. Basically, if the affected text overflows the box boundaries (e.g. in the case of hanging text), IE will crop the exceeding text while other browsers will show it as expected. CSS specifications state that the text-indent property can accepts negative values, but they didn't say how browsers should handle this particular case.

In short, when there's a dubious case, browsers can either choose not to implement something or to implement it with some kind of limitations. If you bear this in mind, you will most probably spare much time in testing and debugging.

Leave a Reply

Note: Only a member of this blog may post a comment.