Home > WSG interviews

Ten questions for Jeremy Keith

20-October-05

Jeremy Keith is a web developer living and working in Brighton, England. He works hard (with Clearleft) and he plays hard (with Salter Cane). Jeremy is a member of the Web Standards Project where he serves as joint leader of the DOM Scripting Task Force.

His online home is adactio.com where he writes about web standards, accessibility and whatever the hell else he feels like writing about (although not usually in the third person).

[1] Russ: What the hell is the DOM?

Jeremy: I could give you the very unhelpful answer that it's an API, but I would just be exchanging one acronym for another.

Basically, the Document Object Model is a way of looking at a document. In that sense, it isn't all that different to CSS, which uses another kind of mental model. CSS uses the idea of selectors to interact with a document. The DOM, on the other hand, views a document as a tree of nodes: element nodes, attribute nodes and text nodes. The DOM provides a vocabulary for targeting and manipulating those nodes.

If a programming language supports the DOM then you can use that same vocabulary to address any kind of markup document.

[2] Russ: OK, then what is Javascript and how does it work with the DOM?

Jeremy: JavaScript is just one of many programming languages with DOM support. What makes the combination of JavaScript and the DOM so exciting is the environment where they are used. Whereas most programming languages do all their work on the server side, putting together pages to be sent to the browser, JavaScript runs in the browser.

That means you can use JavaScript to manipulate the contents of a web page (the components of its node tree, to use the DOM terminology), even after the page has been sent from the server. JavaScript also introduces the idea of event handlers. These are triggers that can be used to associate JavaScript actions with specific events. So when the user clicks on a certain link, you can execute a certain function.

That's what JavaScript handles best: behaviour. In the same way that CSS can be used to add a presentation layer on top of an existing (X)HTML structure, DOM Scripting adds a behaviour layer.

[3] Russ: What about this Ecmascript stuff? Is it just a daggy version of Javascript?

Jeremy: It's more like the other way around: JavaScript is a (not so daggy) version of ECMAScript.

You have to remember that, technically, JavaScript only refers to the language in Netscape/Mozilla browsers. Officially, Microsoft use something called JScript. Netscape wisely decided to submit the JavaScript specification to ECMA so that the language could be standardised. That helped prevent the language mirving into a host of competing technologies.

JavaScript isn't the only version of ECMAScript either. Actionscript, familiar to Flash programmers, is another flavour of ECMAScript.

If we were going to be really pedantic then whenever we talk about cross-browser JavaScript, we should really be talking about ECMAScript. But even I'm not that much of a pedant.

[4] Russ: Why does Javascript have such a bad reputation. Has it been sleeping around too much?

Jeremy: Oh, that's your attitude, is it? "Look at that language with its easy syntax and powerful capabilities: it's clearly asking for it."

It's true that JavaScript has been abused but that's no reason to blame the victim. Remember, JavaScript doesn't kill websites: people with JavaScript kill websites. JavaScript is like any other powerful technology: in the right hands, it can bring enormous benefits. In the wrong hands, it can wreak terrible damage.

It reminds me of Flash in some ways. There's nothing inherently bad about Flash at all. But after years of being abused to create bloated intro pages, the technology itself garnered a reputation for being nasty.

In fact, the problem doesn't lie with the technology at all, be it Flash or JavaScript. It's really a PR problem caused by developers using a technology in a haphazard slapdash way, without thinking through all of the consequences.

The most prevelant example of this is the ubiquitous use of <a href="javascript:…"> or <a href="#">. It breaks the most fundamental idea of the Web: documents joined together with hyperlinks. No thought has been given to what happens when JavaScript isn't available. Even if you're okay with the thought of turning away human beings without JavaScript, do really want to send searchbots packing when they show up at your site?

Thankfully, with a little forethought, the behaviour layer can be added in such a way that it degrades gracefully.

[5] Russ: Can Javascript be used for good instead of evil? If so, could you give me some examples?

Jeremy: See, that's such a loaded question! The implication is that most uses of JavaScript are evil. Actually, thinking about it, many uses of JavaScript are evil (see above).

But anyway, the point is: you wouldn't ask, "Can CSS be used for good instead of evil?" You would expect that the default usage of CSS would be to make sites look good, not bad. That's partly because most developers don't use CSS to make ten foot tall green text on a red background but it's mostly because there are sites like the CSS Zen Garden as well as high-profile commercial sites using CSS for good, not evil.

There may not be a DOM Scripting Zen Garden (yet) but there's no shortage of high-profile sites using JavaScript. Google Maps uses JavaScript for its dragging interface. When you add notes to photos in Flickr, that's JavaScript too.

But, to be honest, my favourite uses of JavaScript are the little things. Like when you click inside an input field that contains some default text and, through the magic of JavaScript, that text disappears. Or there's Aaron Gustafson's clever little bit of DOM Scripting that displays links for printing. It's the cumulative effect of all these little usability enhancements that really showcase JavaScript as a power for good.

[6] Russ: For someone like me who knows nothing about Javascript and wants to learn more, where would you suggest starting?

Jeremy: Well, it must be said, it's pretty slim pickings compared to the wealth of CSS resources. Any developer just starting out with CSS can Google a phrase and find an embarrassment of riches. If you try that with JavaScript, you're likely to end up with a list of outdated resources, some of which give out advice that's downright dangerous.

The WaSP's DOM Scripting Task Force has been set up to redress this balance. Part of our plan is to provide resources for developers looking to learn about JavaScript. To that end, we will be publishing articles on best practices as well as blogging about cool JavaScript techniques wherever we come across them.

But really, there's only so much that one group of people can do. In order to create a landscape of useful DOM Scripting resources, the developers themselves will need to share what they learn on blogs and mailing lists. That's what happened with CSS: there wasn't one central authority coming up with all the best practices and techniques. Instead, it was an ad-hoc peer-to-peer network of enthusiastic web developers eager to share their knowledge. I'd really like to see the same thing happen for DOM Scripting. I'm hoping that the task force will help create the right kind of atmosphere for that kind of activity.

In the meantime, there are some great books out there promoting a standards-based approach to JavaScript. Stuart Langridge's DHTML Utopia is well worth a read if you've already got a good solid grounding in JavaScript. Your fellow Aussie Cameron Adams is joining forces with James Edwards to produce a cookbook of practical DOM Scripting examples. That's bound to be a winner.

[7] Russ: I hear rumours about you and a book called DOM Scripting. Is this true, or just another tabloid beat-up?

Jeremy: Yes, it's true. I've written a book. It was modesty, not shame, that prevented me from mentioning it sooner.

[8] Russ: What sort of issues do you address in your book and is it suitable for a range of skill levels?

Jeremy: There are three cornerstones in the book:

1. Unobtrusive JavaScript
2. Progressive enhancement
3. Graceful degradation

Those ideas permeate all the examples shown in the book. The examples themselves are quite straightforward although they do increase in complexity as the book progresses. At the end, there's a finished website showcasing a lot of the techniques.

It's aimed very much at designers rather than programmers. Specifically, it's aimed at designers who are already appreciating the value of web standards like CSS and semantic markup. The book isn't really intended for advanced programmers. It would probably bore them to tears.

[9] Russ: Now, your friends tell me you obsessed with liquid layouts. Have you built real sites using liquid layouts and how have you addressed IE and its uncanny ability to drop floating columns?

Jeremy: Oh, my <airquotes>friends</airquotes> told you that, did you? I'll have to have a talk with those "friends".

You know what my problem is? I can't help rooting for the underdog. Five years ago, everyone was using tables to layout their websites. I started using CSS partly because I saw a worthy cause that needed to be championed. It's a similar situation now with DOM Scripting. I can see the enormous benefits that this technology can offer if it's just used correctly and I want to spread the word.

Liquid layouts are the underdog of the design world. Designers will come up with all sorts of spurious excuses as to why they won't use them but in most cases, they are simply scared. Firstly, liquid layouts are difficult. That makes them scary enough. Mostly though, designers are scared of giving up control. This fear is the last bastion of the Web 1.0 mentality of control and it's one I hope will loosen its grip soon.

Yes, I've built real sites using liquid layouts. For most information-based sites, it's the clear choice. Really, designers should have to come up with reasons not to use flexible layouts when they'e designing for a flexible medium like the World Wide Web.

So, you want me to name names, huh? There's my personal site, Adactio. There are a whole bunch of different themes on offer. All but one of them are liquid. My portfolio is up there too so you can peruse that for more examples of liquid layouts. Just recently, for the Clearleft website, I created a liquid environment for Andy's design and Richard's words.

To be honest, I've never had that many problems with IE's decision to rearrange floated columns from side-by-side to one on top of the other. The problem is usually caused by large fixed-width content, like images. Either I've used background images or set the width of the images in percentages (as is the case with the Clearleft site).

Maybe I'm being unduly optimistic but I have a feeling that liquid layouts might be having something of a resurgence. Dan Cederholm devoted a whole chapter of his new book to the topic, someone has a started a liquid layout showcase site and then there was your excellent presentation at Web Essentials. Personally, I think every web designer on the planet should read John Allsop's A Dao Of Web Design — it's five years old but it's never been more relevant.

Well, I bet you're regretting that you ever raised the subject now. Maybe I am slightly obsessed. I'll shut up now. Thanks for giving me the chance to vent.

[10] Russ: So, now you are a celebrated author... what's next?

Jeremy: A scandalous lifestyle filled with debauchery and drugs would be my preferred next step. Failing that, I guess I'll just continue to make websites and drone on incessently about JavaScript, pausing only to have the occasional rant about liquid layouts.

What I really want to do is take the DOM Scripting show on the road. After speaking at Skillswap, @media and South by SouthWest, I really got a taste for speaking to a captive audience. I plan to do more of that. I've been giving day-long DOM Scripting training courses, which I've enjoyed immensely. I'll also be speaking again at SxSW again next year.

But my real ambition is to speak at a certain conference held in Sydney (hint, hint).

Russ: Thanks for the interview, Jeremy!

Jeremy: My pleasure, Russ.