Gotta keep 'em separated

A little while back, Derek Featherstone started a discussion about what he called browser elitism. There were some interesting and very revealing comments.

Derek realised that the issue needed some clarification and he posted a follow-up. His basic question is this:

If you are adding a usability enhancement to a site, is it ever okay to deliberately exclude a specific browser from receiving those enhancements?

The issue is somewhat clouded by the fact that "a specific browser" is usually Internet Explorer. There’s no love lost between standardistas and Microsoft.

Derek gives some specific examples:

"A form field receives focus and is "highlighted" as the active field using the :focus pseudo-class."

"When hovering over a checkbox or radio button and its label, you add in a background-color to the pair so that their association is more closely understood."

And so on. All of the examples have a common theme. They all use CSS2 pseudo-classes. This reminds me of something I’ve mentioned before:

Why is it acceptable to use CSS (which handles presentation) to add behaviour to a document? Surely that is the domain of DOM scripting?

Pseudo-classes like :focus and :hover are basically event handlers… event handlers with really patchy browser support.

The idea of separating structure and presentation is deeply entrenched in CSS based design. Separating structure and behaviour with unobtrusive JavaScript is also widely regarded A Good Thing. Yet the very developers that are flying the flag of web standards have no qualms about mixing up presentation and behaviour.

Is there some kind of double-think at work here?

I think there might be a simpler explanation.

CSS is more widely used and understood than JavaScript and the DOM. There is a general feeling that things can be accomplished quickly and easily in CSS that would take longer to do with DOM scripting.

I think this belief isn’t based on the reality of developing with the DOM. Rather, it’s part of the FUD surrounding JavaScript in general. It is still considered by many to be a nasty, inaccessible technology.

This view is outdated and fundamentally flawed but it does explain why developers so readily destroy the separation of behaviour and presentation with pseudo-classes. The CSS route is perceived to be quicker and easier.

There are two problems with this conclusion. The first is that just because something appears to be easier, doesn’t make it the right tool for the job. In fact, there was probably similar excitement when the <font> tag was introduced to HTML: a quick and easy way to control presentation.

When we evangelise CSS based design, we often hear a refrain from old-school designers who claim, "but it’s easier to use tables!". As it turns out, using CSS is, in many ways, easier than using nested tables and spacer .gifs. The problem is a fear of a new technology and a misplaced belief that it will be more time-consuming.

I’m seeing exactly the same attitude now being expressed by CSS designers who don’t want to learn DOM scripting: it’s too difficult, it will take too long.

The second problem with using pseudo-classes as event handlers is more practical and relates directly to Derek’s question. CSS2 is not supported evenly across browsers. Some browsers have much better support than others.

The DOM, on the other hand, has pretty great support across the board, certainly for the core methods and properties.

In light of this, Derek’s question takes on another dimension:

Knowing that the supposedly easier solution will exclude more browsers than the correct one, is it okay to exclude those browsers?

There are three fundamental points here:

1) DOM scripting, not CSS, is the correct tool for making behavioural usability enhancements.

2) Amongst browsers, the DOM is more widely-supported than CSS2.

3) Amongst developers, CSS is more widely-supported than DOM scripting.

To me, it’s clear that the problem lies with the third point. Lots of developers use the hammer of CSS so everything looks like a nail to them.

If you’re a web developer and there’s a usability enhancement you could potentially add to a site you’re building, think about the options. The most popular option is to try to use CSS because it’s what you know. You might claim that it’s financially impractical to attempt to accomplish the task with DOM scripting: it would take longer and therefore cost the client more.

That’s the problem right there. There is a gap in your skill set that needs to be filled. It’s time to expand your toolbox.

It’s about time we stopped blaming poor CSS support in browsers when the real issue is poor DOM scripting support in developers.

As I said, this issue is somewhat clouded by the specific browsers involved. As Derek says in a corollary to his question:

"What if input:focus and tr:hover worked in IE, but not Firefox? Would you use DOM Scripting to add support for them in Firefox?"

In theory, the specific browsers shouldn’t matter. Wasn’t that the whole point of web standards? No more coding for browsers. Now we code to the specs instead.

Well, the W3C DOM is a spec. It’s a web standard, just like CSS and XHTML.

This isn’t about browsers. It’s about web standards. It’s about using the right tool for the job.

Have you published a response to this? :

Previously on this day

18 years ago I wrote Look, Ma; no wires!

I’ve been trying to get my hands on some airport cards for my Macs for quite some time now. I kept going into the local Apple supplier and pestering them.