Jump to main navigation, main content

Archived entry | Matt Wilcox .net

The fundamental problem with CSS is it's reliance on the DOM

I’ve already argued that CSS needs to borrow from programming languages, and I wonder if the arguments designers and developers are getting into over the future of CSS have a more fundamental cause than the one’s debated so far (which boils down to the Cascade being inadequate on it’s own). To my mind the crux of the issues is this: CSS currently operates on top of the Document Object Model - a base that is ill suited for the job CSS is asked to perform, namely, the visual presentation of a webpage. We need to stop using the DOM as the sole basis for visual tasks. That sounds odd, but please hear me out.

What problems are we facing with CSS?

As CSS has aged, the progress of the specification has slowed, and the capabilities of CSS have not kept pace with the requirements of designers. There are a number of reasons for this, as have been explored at length in a number of articles1 from many influential designers and developers over the past few months.

Baring the odd problem, such as the bad attitude toward CSS (and CSS authors) some of the CSS WG hold2, the main issue is one of technology implementations that make good visual design incompatible with good development practice.

We’re all good developers and designers now, and we have stopped using tables for layout and stopped thinking of HTML as a presentation language. We know that HTML is the semantics of the document. We also know that the DOM is the programmatic skeleton of that HTML document. The trouble with HTML defining only semantic data is that the DOM itself represents only the semantic elements within a document. Because CSS can only be applied to elements within the DOM, that in turn means that CSS can only be applied to elements that have distinct semantic properties within the document. The trouble is that designers don’t want to style the semantic elements alone, we want to style all sorts of bits and bobs that have no semantic anchor and therefore no representation in the HTML/DOM.

This isn’t a new realisation, and people have been cluttering mark-up with semantically redundant tags and properties simply to ‘have something there to style’ ever since CSS trundled out of the W3C (divitus and spanitus, take a bow). Modern best practice has shunted this task of junk-markup-generation to the JavaScript layer, which can be used to find chunks of DOM to decorate with superfluous HTML that CSS can then work with. But this results in a situation where the HTML/DOM sent to the browser bears almost no resemblance to the DOM which is actually being run in the browser. In essence, JavaScript is being used to create a pseudo Visual Object Model, which CSS can then be applied to.

Quite aside from the fact that this is an abuse of JavaScript from a purist standpoint (it’s the behaviour layer, it governs interaction behaviour - not behaviour independent of user action), it’s also a blatant indication that in order to visually present a webpage how we want, we currently have to insert garbage HTML into the document at some point, however that’s achieved. As Rich Internet Applications become more complex we are hitting a stage where the DOM of the HTML sent to the browser and the DOM in the browser render engine are miles apart. And yet they are supposedly one and the same thing. It’s a situation which will only get worse.

People at the W3C seem quite adamant that CSS’s job is to style elements within a document. And while the web was happy to have nicely coloured hyperlinks, and slightly better typography, that was fine, because those visual changes mapped perfectly to actual mark-up. But time and big business has changed what users want from the websites they visit - things have to be pretty these days. Not functionally pretty, but artistically pretty. And making things pretty is often an exercise in graphic manipulation independent of the available HTML content anchors. Sometimes we want to shove a pretty graphic somewhere on a page where there isn’t any content to attach it to. CSS has already changed objective from it’s initial conception - it’s not about styling the semantic content of a document, it’s about the visual presentation of a webpage. Those are two very different things; visual presentation of a page is quite independent of the semantic content. So the way in which CSS works - mapping visual effects to DOM elements - is itself a problem, because that doesn’t always map to what designers actually want to do.

Possible solutions?

There’s one major part of a solution out there already, but it doesn’t work the way it should, and needs an overhaul. CSS Generated Content. A method of adding purely visual elements to a page that doesn’t rely on adding non-semantic HTML (either by hand or by JS). But at the moment generated content is almost totally inadequate. It can not be positioned, which means it can’t be moved anywhere other than wherever it happens to sit in document flow. And it can’t wrap elements, only become appended (or prepended) to them. If Generated Content acted just like normal content (eg, if it behaved as though the generated content was in fact just a span that got inserted into the DOM) then we could wave goodbye to the DOM getting cluttered with crap right now. Wave goodbye to a discrepancy between the DOM sent to the browser and the DOM running in memory. Wave goodbye to a dependency on JavaScript to achieve purely visual effects.

Footnotes

Arguments about the progress of CSS and the way forward with the specification

Back to the reference point

Bert Bos’s attitude

It’s hard to understand why, but after 14yrs of designers repeatedly voicing their need for a more powerful CSS, Bert Bos still manages to argue that designers demands for CSS variables are wrong. If we’re still asking the same thing 14yrs later, that’s evidence itself that CSS isn’t delivering what we need, and that we know what we need. Alex Russel has a very good rebuttal of Bert’s article; CSS variables are the future.

Back to the reference point

Comments

skip to comment form
  1. Matt Wilcox posted 20 days, 0hrs, 14mins after the entry and said:

    Brief clarification; CSS2.1 does allow for Generated Content to be positioned, however Firefox 3 doesn't support that ability yet.

From the archives

Other enteries filed under:

My Two Cents

Web Development

Site information

Built with valid XHTML and CSS, designed with web standards and accessibility in mind. Best viewed in a modern browser [Firefox, Safari, Opera]

This domain and all content is a copy of my old website, for historical purposes only.