Jeremy Keith Interview: Web Standards and Design Principles

Jeremy Keith gave a great talk at An Event Apart about design principles. In the talk, he shows how everything should start with your goals, which then lead to principles that reflect those goals, and finally result in design patterns to implement them.

Jeremy has been an active contributor to the web standards movement for many years. He’s a member of the Web Standards Project and is a frequent conference speaker. He blogs at Adactio.com, his personal site.

By day, he is the technical director at Clearleft, a prominent user experience firm in Brighton, England. And in his spare time, he built Huffduffer, an elegant free service that lets you aggregate links to audio from around the web into your own composite podcast.

I spent a few minutes with Jeremy after his talk and recorded this interview about the state of web standards and the use of design principles, such as the all-important “ignore anything you don’t recognize”:

Jeremy’s most recent book was the first book ever from A Book Apart, HTML5 for Web Designers. It cuts quickly to the heart of the matter and is a surprisingly easy read for a technical book, explaining what’s immediately useful about HTML5 and offering insight into how the standards process works.

His previous books include DOM Scripting, one of the first books to show designers how to use JavaScript to enhance their pages, and its sequel, Bulletproof Ajax.

In addition to the upcoming An Event Apart conferences, you can catch Jeremy later this year at Mobilism in Amsterdam, and at the DIBI Conference in Gateshead, England.

Transcript of the Interview

Michael: Hi, I am Michael Slater from Webvanta and I am here interviewing some of the speakers from An Event Apart. I’m pleased to be speaking with Jeremy Keith from Clearleft in the UK, who just gave a great talk on design principles. Jeremy, can you introduce yourself and tell us a little bit about what you were talking about?

Jeremy: I’m Jeremy Keith and I was talking about design principles, which are essentially the reason why you do something and how you go about doing it right. You’ve got design goals and design principles, and they result in the design patterns. I was making the point that these principles are everywhere, whether you are aware of them or not.

The web itself is based on a set of principles. Every content management system should have a set of design principles behind it. And those design principles are driven by the goal that the content management system is trying to solve. Basically, I’m just hammering home the importance of design principles and showing examples, like the design principles of HTML, the design principles of CSS, and so on.

Michael: It’s remarkable really how far reaching the design principle of ignore things you don’t recognize has been. Was that really conscious or was that fortuitous?

Jeremy: No, that was absolutely conscious. The web at the start was a messy place. There was a lot of evolution and rapidly throwing stuff at the wall; throwing new elements into the browser and seeing if people would use it or not. It was kind of Darwinian, seeing if it would survive.

It was really a bad time for web developers in the 90’s because all of this proprietary stuff was being thrown in. But in and amongst all this proprietary crap being thrown in, there’s really useful stuff. And that useful stuff would end up being in a spec because it turned out to be simple.

Essentially, browsers, because they have to deal with who knows what coming at them, had to be able to handle all sorts of rubbish markup. Stuff we would look at and think, that is badly nested or that element doesn’t exist—why are they using that? A browser doesn’t break when you throw this stuff at them. It’s going to ignore stuff it doesn’t understand.

It turns out that that is really, really useful for adding to HTML. Same for CSS. If a browser doesn’t understand the CSS rule, it doesn’t break. It doesn’t stop processing the document. It just ignores that rule and processes the next one. That is sort of a fault tolerance, I guess you would call it.

It’s the same with product design. You want to make sure that one small error doesn’t cost someone their life, right? You want to have fault tolerance built in. You absolutely want to have it built in to web browsers, and it’s definitely by design.

Michael: Is there anything going on today in the HTML and CSS standards world that concerns you?

Jeremy: I actually do think it’s on a good track. In the CSS world, I think one of the useful innovations is the rise of vendor prefixes. If they go to far, it’s going to be awful. If everything is getting vendor prefixes, -webkit, -moz, -o, that’s not good. But there’s been just enough use of it to push the boundaries and figure out we really want to have gradients. We really want to have these transitions and transforms to see which directions the specs should take. See what authors start using; if they start using this stuff, it’s useful, let’s put it in the spec.

In the HTML world, people think things might not be going that well but I think things are actually going great. People look at the bizarre kind of process in place now with the W3C & the WHATWG and it just looks like a mess, but actually I think they balance each other really really well. Yes, they have a very different approach, but they balance each other out very well.

Michael: Are we going to get to HTML6 at some point?

Jeremy: Oh yeah. This is a common misconception that a standard body will work on one version and once thats done they can move onto the next version. HTML5 will probably hit last call this year, in a couple months. From that point, W3C could be working on HTML6, even though there will still be lots of work done in browsers implementing this stuff. This stuff can be asynchronous, right? Work goes on.

You can work on CSS 2.1 while still working on specs for CSS3. It’ not wait until everything is done and dusted, then move onto the next number. This stuff can happen in parallel. So yeah, there will be an HTML6, HTML7, and HTML8 from the W3C. Over at the WHATWG they’re just saying it’s HTML, and that they are just having this living document, this living standard that will evolve as the browsers add these features.

If that were the only living spec I would be a bit concerned, but the fact that we also have the W3C nailing down the specific versions (HTML5, HTML6, HTML7) again they balance each other out really well. They make a good interplay.

Michael: Great, thank you for taking a few minutes to talk to us.

Jeremy: Thanks Michael.