When Cascading Style Sheets become inappropriate

Perspective — Various urban legends used to warn web designers against the evils of HTML frames, tables and CSS. Things have changed since, for the best and the worst.

10 years ago, CSS-1 was a new W3C recommendation. We were in the heat of the browser wars, Netscape was loosing ground fast, the more IT-savvy programmers would test their web sites with Lynx, and the anybrowser campaign was at its climax. In the business world, web developers were about to migrate their HTML-3.2 compatible web sites to HTML-4 transitional. And the internet bubble was steadily inflating.

At the time, you would readily find web design tutorials meant to help you sort out which technologies you wanted to leverage on your web site. Interestingly, some of the discussions survived 10 years.

Frames, in particular, were universally frowned upon. And still are. More often than not, however, they received bad press for the very same reason tables once received bad press: Some browsers/search engines didn't understand them. Which is of course an absurd reason to discard them: Browsers and search engines will adapt. More rarely, you would bump into the true reason frames suck, most of the time: Frames split the page in parts, and thus break the entirety of the page, whereas this entirety is the very idea behind the world wide web.

Cascading Style Sheets enjoyed quick adoption, despite problems. One of these is of course that browsers don't render CSS in a like manner, especially when it comes to inheriting properties (e.g. font-size 200%). But I would term this as a mostly irrelevant drawback. And arguably, there are several effective uses for CSS. Yet, I've always had a few concerns with CSS.

My main problem with CSS is in fact that most users don't understand what styles sheets are in the first place. The very idea that you can separate the structure and the visual layout of a document is out of reach for most users — just consider how most people use MS-Word.

Less users still understand the notion of cascading style sheets. Programmer wise, it is extremely interesting to attach a style based on context. It great to code:

<div id="main">
  <p>blah</p>
</div>

<div id="sidebar">
  <p>blah</p>
</div>

and use a style sheet to define:

#main p
{
  color: darkmagenta;
}
#sidebar p
{
  color: firebrick;
}

But then, how many developers actually do this, let alone understand what they can leverage from cascading style sheets? And how many of them see when they shouldn't use them?

For instance, I usually agree with web developers that recommend to use CSS for web page layout. Until they mention using CSS for grid layouts. Never use CSS for grids involved in web page layouts.

CSS initially was designed to render documents, as opposed to interfaces. CSS lets you change the way elements look. Moreover, its box model and its visual formatting model let you position this and that to the top, the bottom, the right or the left of the main document area.

When you are designing a web page with a few navigational elements (e.g. header, sidebar, footer), however, you are embedding a document in an interface. CSS was not designed with this in mind. Never mind that Cascading Style Sheets now have grid-rendering features! They are meant to let you skin XML documents. Using CSS to render grid layouts in an HTML page will only contribute to its unmaintainability. Consider:

<table>
<tr>
  <td>
    <p>blah</p>
  </td>
</tr>
</table>

<div class="table">
<div class="row">
  <div class="cell">
    <p>blah</p>
  </div>
</div>
</div>

The two may of course be equivalent in the end, but the first is arguably more maintainable.

Another issue I would raise is CSS' lack of features in some areas. Specifically, it is less powerful than XSLT in many respects when it comes to rendering an XML document. Moreover, there are things CSS — and XSLT — will simply not let you do in any easy manner:

• Apply a style to all elements except…, using a negative query, e.g.:
  p !b a { }
• Apply a style to elements using a regular expression-like syntax, e.g.:
  p (b|i)+ a { }

You can of course work around the first by defining two styles. But by doing so, you might end up inappropriately redefining a default style at an inappropriate level. Example:

/* override default setting: */
p a { color: darkblue; }

/* except... */
p b a { color: blue; }
/* but who said blue was default? */

I've yet to find a workaround for the second, save for enumerating as many cases as necessary.

Note that this regexp problem is more interesting that you might think at first. CSS' syntax is an interesting way to skin an XML interface with behaviors using HTCs or a like component-driven model:

#panel1 textbox
{
  behavior: url('b1.htc');
}
#panel1 #subpanel1 textbox
{
  behavior: url('b1_1.htc');
}
#panel2 textbox
{
  behavior: url('b2.htc');
}

Imho, this is a lot more powerful than class heritages and polymorphisms. Especially if you are dealing with things such as neural networks. Or rather, especially if a neural network replaces the CSS syntax. But that is for other columns.