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.

Comments on When Cascading Style Sheets become inappropriate

  1. blah

    blah

    That is complete nonsense there.. that’s not how you would use CSS. Using that as an example just means you haven’t fully looked over how style sheets are used.

    Example table code for something where you just want 2 elements, one right aligned, the other left:

    Element 1 Element 2

    VS

    Element 2
    Element1

    The first word in CSS is Cascading, its very important. CSS does *NOT* mean use DIV’s for everything.

    So you’re code, making CSS look like complete nonsense by specifying a DIV for every item, is complete nonsense.

  2. Yes, you can float: right, and even float: left. I’m quite proficient with CSS, really. And best I know is that the float behavior is somewhat inconsistent from a browser to another. What more, it lets you do a 2 or 3 col layout maximum without going through half a day of debugging. More often than not, you’re better off using width, height, top, left, right, bottom, and margins for more control when you do so.

    But then again, this is inappropriate use of margins: they weren’t designed to with this kind of overlapping in mind.

    As for the example, it was just an example. If you prefer a more complex one:

    <table>
    <tr>
    <td colspan=”4″></td>
    <td rowspan=”5″></td>
    </tr>
    <tr>
    <td rowspan=”2″></td>
    <td></td>
    <td></td>
    <td rowspan=”3″></td>
    </tr>
    <tr>
    <td></td>
    <td></td>
    </tr>
    <tr>
    <td colspan=”3″></td>
    </tr>
    </table>

    Yes! Of course! You _are_ right. I’m aware you _can_ do something similar to this easy yet untypical layout in CSS. There’s _always_ a way to do things with CSS.

    Nonetheless, the purpose of a table, or grid, is to display data in a tabular, well aligned way. Tables align things without hassle by default. Using pure CSS when a simple table could do is like programming in Fuckfuck. ;)

    Moreover, and quite frankly, users really don’t care a damn if it’s tables or CSS. Just as long as it works.

  3. It’s not the users opinion that matters :)

    Tables aren’t designed for “Grids” they’re designed for “Data”. There’s a huge difference between the two. And using XHTML is kind of a basis saying “I know how HTML elements work” which is why I’m bringing this up.

    There’s a reason you use a list (`

      `) rather then using
      for each element, even if it isnt styled to look like a list.

      There’s also a reason we use css designs over tables, and it has nothing to do with the users perspective. It’s designed for bandwidth optimization as well as search engine optimization.

      I took a table based design, and cut its size by 75%. This website is ranked ~2500 in Alexa. Take for example: They average lets just say 100,000 unique hits a day. We’re going to say each unique hit doesnt have a cached version of the website yet. Say the main page is 35k with tables, and 10k without tables. 35kb * 100,000… per day. You add it up and CSS saves you a good chunk of money over time, for the small cost it takes to implement it.

  4. HTML is essentially a language designed to describe a document’s formatting. XML is the language to use to describe structure. Learn XML. And XSLT. That way, you’ll save even more bandwidth. :)

  5. Why not? Server-side works well too, you know. The next major version of my CMS tiles will all be XML/XSLT based with built-in caching. I expect most devs will find this neat. :)

  6. I tend to agree with the author. After a certain point CSS just becomes annoying.

    I construct sites using a combination of server side templating and CSS to separate content from formatting: all navigation and extraneous page content goes into the template, in whatever method is cleanest and easiest (most often in tables and CSS), and actual page content goes in clean, table free. I think this is a healthy compromise, until CSS display options become a little more user friendly.