Archive: April 21st, 2005

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.

I took some time out yesterday to attend a little literary event. The authors Rupert Thomson and Andrew Miller were speaking and reading at The Old Market, which is right at the end of my street.

I know Andy and I’ve read his Booker-nominated Oxygen. I wasn’t familiar with Rupert Thomson’s work. I intend to become more familiar with it. I bought his new book, Divided Kingdom, after hearing him read the first few pages.

The reading was enjoyable but it was the speaking that really held my interest. The two authors chatted about their respective writing processes.

Both writers said they did very little planning or outlining for their books. They did plenty of research but they certainly didn’t wireframe the plot or the characters. Rupert Thomson likened to process to sculpture, carving away at a block until something emerges.

With a process like that, there can be plenty of dead ends. There were nine very different drafts of Divided Kingdom before the final novel emerged.

During the question and answer session, I asked what seemed to me to be the most pertinent question:

"How do you know when you’re done?"

There’s no quantifiable answer, of course. The secret is knowing when to stop. If you go too far with a sculpture, you might chip away until nothing is left.

It was quite gratifying to get an insight into the creative process from a discipline other than web design. At heart, the disciplines aren’t all that different. Both of them exhibit a 99 percentile in the perspiration to inspiration ratio.

I wish I could just design something great straight off the bat. It never seems to work that way. Instead, I have to pay my dues by investigating and discarding countless design directions. It’s usually right at the point when I’m ready to give up that something clicks and I suddenly "get it". It’s then I know that I’ve found the right design (strange that I would call it "finding" the right design… as if I didn’t create the design myself).

My design process isn’t the fastest. I usually end up with a folder full of discarded Photoshop files. But I know that, without those dead ends, I never would have arrived at the final destination.

This process had never been a problem until recently. I was working for a client on an hourly basis. The client questioned the hours listed on the invoice that I claimed to have worked. Looking at the final design I had produced, he couldn’t see where the time had been invested. I offered to show him my folder of discarded designs but he didn’t seem interested.

I think my process might be similar to what Jeff Veen calls blinking out design:

"The problem, of course, is doing this commercially - doing it on cue. How do you write a proposal that suggests that I’m going to "do a tremendous amount of homework, then just wait for the answer. Oh, and it’s going to be really, really painful as we wait. Really painful. Sorry.""

Listening to the two writers describing their craft, I realised that my process wasn’t anomalous.