People of HTML5 – Bruce Lawson

HTML5 needs spokespeople to work. There are a lot of people out there who took on this role, and here at Mozilla we thought it is a good idea to introduce some of them to you with a series of interviews and short videos. The format is simple – we send the experts 10 questions to answer and then do a quick video interview to let them introduce themselves and ask for more detail on some of their answers.

Bruce works from home somewhere in the darker and unknown regions of England, and if you haven’t had the chance to see him speak, make sure to catch one of his talks. Also, despite his disturbing fetish for cheesy cam effects, he really knows his stuff and is a very funny man to boot.

Ten questions about HTML5 for Bruce Lawson

1) What, in your view, is HTML5 and what does it mean for web development as a whole?

It’s the language for web applications: it makes writing apps more robust, more interoperable and expands the capabilities of browsers so the web can come closer to native apps.

2) How did you get involved in the HTML5 world? What is your background and even more importantly, what drives you?

My background is in accessibility and writing markup. So getting involved in the development of the new language for the Web was too exciting to pass over, and because Opera (my employer) was so closely associated with the genesis of HTML5, it was easy to persuade my boss to let me have the time!

3) What do you consider the most exciting of the new technologies?

HTML5, of course — and also DAP (“Device APIs and Policy Working Group”). This thrillingly-named set of specifications is further extending the capabilities of the Web by specifying APIs that allow access to device features like camera, contact books and calendar — much like Geolocation gives browsers access to the device’s GPS capabilities. Like HTML5, the DAP are adapting existing proprietary APIs that have been road-tested, and other manufacturers have committed to supporting the specifications.

4) You’ve co-authored “Introducing HTML5” — what was the most frustrating part about writing an HTML5 book? Isn’t HTML5 still a bit of a moving target?

Apart from the freakishly anachronistic processes behind dead-tree publishing (everything to be submitted in Microsoft Word!) the hardest part was the fact that the spec kept moving from under us. The chapter on video had just been proofread and indexed when the webM format was announced and we had to rewrite. But we were pretty sure that most of the stuff that was ready to use was pretty stable — and in a short Introductory book, we weren’t trying to cover the more esoteric areas, anyway.

5) You’ve been advocating using the term “NEWT” instead of talking about HTML5, what does that mean and why not HTML5 as an umbrella term?

Clients and journalists will use “HTML5” to mean CSS 3/video-that-runs-on-iThings/Geo-enabled applications. It’s the new “Web 2.0”. But we practitioners need to get our nomenclature straight. There are no HTML5 image transitions, just as there are no CSS semantics — and to say there are shows that you didn’t get the 2001 memo about separating style and content.

If we need an over-all term to encompass DAP, CSS 3, HTML5, Geolocation, SVG, WebGL, then let’s call it the Open Web Stack. But, because people seem to like easy-to-pronounce acronyms and cute logos, I proposed NEWT as a tongue-in-cheek way to highlight the jargon abuse I see happening.

6) What is in your opinion the biggest obstacle to mainstream HTML5 adoption?

Developer ignorance: “I can’t use it because it’s not finished” and “I can’t use it because I still have to support IE6” are the main stumbling blocks. “It’s not finished” annoys me the most. Perhaps we should stop using the English language because it’s “not finished yet” and move to French, as that was apparently finished in 1799.

Then there’s the IE6 fallacy. The HTML5 Shim allows you to style HTML5 elements in IE6, as long as you have JavaScript. If a visitor is surfing the Web with IE6 and JS turned off, their experience of the whole Web will be pretty dreadful and your site won’t be any worse.

And, of course, it’s not The Law that you must use HTML5; it’s really for Web applications. HTML4 and XHTML 1 will continue to work fine for documents.

7) There are a lot of fixes right now available to make HTML5 degrade gracefully on older browsers and IE6. If you look, for example, at the HTML5 boilerplate, this seems a lot of work and extra code and files. Is this worth it? What is your stance on so called “polyfills”?

All you really need is Remy’s HTML5 Shim so you can style your new HTML5 elements. Depending on your project you choose individual polyfills. is it a lot of work? Perhaps — but is linking to a pre-written polyfill that fakes WebSockets in old browsers harder work than writing that functionality from scratch and making it work in IE6 to 8?

Polyfills come with built-in obsolescence. They’re only needed for old browsers, and by definition, that’s a dwindling number of installs. Newer browsers don’t even know of their existence. It ain’t pretty, but feature detection and polyfilling are better than browser sniffing or locking out users.

8) Is there something in the HTML5 recommendations and specs that ails you? Are they taking a direction you don’t agree with?

I wish that accessibility aspects of canvas had been specified long ago, so that they were in browsers now. People are already abusing canvas to make User Interfaces, and it’s going to be the biggest problem, I think. I also think it’s silly that you can’t use CITE around the name of a person, which is one of the few instances of breaking backwards compatibility with HTML4.

9) If I wanted to learn about HTML5, where would you say is the best place to start?

There’s a wonderful book that introduces HTML5. The title escapes me for a moment… Mark Pilgrim has an online book, too, which is pretty good. I co-curate a site called HTML5 Doctor which has a lot of beginner’s articles in tasty morsels. There are, unfortunately, so-called schools sites with out-of-date information and even published books based on archaic versions of the spec.

10) HTML5 takes a much more lenient approach to markup than HTML4.01 strict or XHTML. You can for example mix upper and lowercase tags and omit the quotes around attributes. Isn’t that a step back in terms of code quality?

Nope. It should be easy for people to move their sites from XHTML 1 or HTML4, and browsers never cared about syntax (when served text/html), so why impose an arbitrary rule forbidding lower case, or upper case, or requiring trailing slashes? Authors should pick a style that works for them and stick to it. Sites like HTML Lint offer the ability to opt-in to “lifestyle” syntactical choices like quoting attributes, lower case, etc. and I expect authoring tools to do the same.

The real test of quality is the DOM that the browser constructs from the code, and when browsers have HTML5 parsers, they’ll construct identical DOMs even from invalid code, which is a fantastic win for the interoperable Web.

Bonus: What’s next? What do you consider the next big issue we need to fix to make the web a better place and easier to build for it?

21 comments

I’m not sure about this argument about HTML5 & the English language. Developers are apprehensive towards building a website to the current spec, handing it to a client, the spec being changed and that websites breaking or just not working as intended.

I said “Perhaps we should stop using the English language because it’s “not finished yet” and move to French, as that was apparently finished in 1799.” due to a completely mis-remembered “fact” that the French Academy codified the French language and declared themselves sole authority thereof in 1799.

Where French history is concerned, I don’t know my derrriere from my coude.

So please read “Perhaps we should stop using the English language because it’s “not finished yet” and move to Volapuk, as that was apparently finished in 1931”

if you use the HTML5 doctype – and nothing else – you still get the glory of calling your site “HTML5”.

On a more practical level, the HTML5 doctype means that ARIA roles and states will validate, allowing you to add accessibility information and have it validated (it’s illegal in HTML4/ XHTML 1). For more info about ARIA, see Gez Lemon’s Introduction to WAI ARIA http://dev.opera.com/articles/view/introduction-to-wai-aria/

Regarding the step backwards from XML validity, this is the one reason I have no interest whatsoever in HTML 5. I’ve been involved with web development since 1995 and have enjoyed seeing all that old tag-soup nonsense put behind us with the migration to XHTML and other XML-related standards and seeing it discarded in favor of a new flavor of tag soup all in the name of the almighty “canvas” is incredibly disappointing. Professionally, I’ve left the HTML5-gobbling web-client world for the far richer, more interesting world of XML and won’t be looking back.

I’ve taken the idea to heart of using HTML5 for applications development
and have been working on some serious projects centered around it.

My current project is The “AsterClick AMI tool set” aimed at
supporting the creation of HTML5 based applications for controlling
the Asterisk PBX using webSockets.

One of the components in the tool set even allows HTML5
applications to be deployed as stand alone desktop executables.

I’ve just about finished the first application that leverages that tool set
which is something called a “HUD” that allows one to drag-n-drop phone calls, transfer calls, manage phone queues , teleconferences and the like

So I really do see HTML5 having an important role in developing
real commercial quality applications both on and off the web.

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.

For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.

And web authors have almost never written to the specs. All the hacks and reverse engineering that WhatWG claims to be relegating to the past are because authors write to display in certain user agents. And now that the spec creates a situation where user agents are required to have a consistent, reproducible, and workable DOM regardless if the HTML is valid or not, there is absolutely no reason document authors will bother with producing valid HTML.

You don’t have to be a supergenius to see if something requires more work and there is no penalty for not performing that extra work, that extra work will almost never get performed. Remove the stick and provide no carrots and guess what happens to behaviour. In other words, HTML5 will increase malformed authored code, because it eliminates all existing (minimal) downsides to authoring erroneous HTML4 without providing any extra benefits for authoring valid HTML5.

And there is the tag soup of HTML5 introducing a whole slew of semantically dubious tags like section and aside and the complete NIH of the microdata proposal.

Although I agree that HTML5 syntax is not strict and that’s okay I think consistency of code style is important for clean code – and editors and IDE’s tend to prefer well structured code and proper closing tags to enable code folding etc.

Lets not make the Internet’s new code base look like the disastrously sloppy code samples that live on MSDN and other legacy code samples that wreak of 1995.