HTML 5 Editor Ian Hickson discusses features, pain points, adoption rate, and more

In this interview, HTML 5 Editor Ian Hickson discusses his favorite features, the features he thinks might be most contentious, the pain points he expects HTML 5 will address, and much more. He also tells what he would change in the original HTML spec if he could go back in time.

——————————————————————————————————————-

In January 2008, I wrote that HTML 5 was headed for a change of course… straight for the iceberg. In response to my highly critical comments, Ian Hickson, the editor of the HTML 5 specification, let me know that I was more than welcome to join the HTML Working Group. In the spirit of trying to be helpful, as well as giving something back to the development community, I decided to join the group.

It has been interesting to be involved in the standards process. While Ian and I have had our disagreements over a few details of the specification, I have come to respect him immensely for the work that he puts into the spec on a daily basis.

Since there was such a large response to my initial post on HTML 5, I thought that TechRepublic members would be interested in getting a sneak peek of what to expect in HTML 5, as well as a look into the history of HTML 5, the standards writing process, and what it is like to be a part of it. I asked Ian if he would be interested in participating in an e-mail Q&A, and he graciously accepted.

Note: This interview is also available as a TechRepublic download.

It’s been nearly 10 years since HTML 4 was published as a spec, about the same amount of time that it took to get to HTML 4. How do you think that this timeline affects HTML 5?

Standards development isn’t like making software — people are implementing HTML5 as we speak, and many parts of HTML5 will likely be widely used long before HTML5 is officially “done.” There are many parts of HTML5, like the canvas element and the postMessage mechanism, that are already implemented in multiple browsers.

Bearing that in mind, timelines for specifications are often a point of contention. Back when the W3C asked for feedback on the HTML working group charter, in November 2006, I suggested the following timeline, taking into account that work on HTML5 started in late 2003:

• First W3C Working Draft in October 2007.
• Last Call Working Draft in October 2009.
• Call for contributions for the test suite in 2011.
• Candidate Recommendation in 2012.
• First draft of test suite in 2012.
• Second draft of test suite in 2015.
• Final version of test suite in 2019.
• Reissued Last Call Working Draft in 2020.
• Proposed Recommendation in 2022.

This may look ridiculous (2003 to 2022 is 19 years!), but it’s worth considering how this compares to HTML4, DOM2 HTML, and XHTML1, the three specifications that HTML5 is intended to update and replace.

Work on HTML4 started in early 1997. The specification itself took about 2 and a half years, and was published in late 1999. Work on XHTML started while this was happening, in 1998, and it was officially completed in 2000.

The HTML DOM specifications were done by a completely separate working group: DOM1 started in 1997 and was published in 1998; work on DOM2 HTML started shortly after in late 1998 and was completed in 2003. So, generously, the spec editing work spanned from 1997 to 2003, a period of 6 years or so, the same amount of time as 2003 to 2009, which is what the timeline above predicts for HTML5 to reach “last call.”

However, HTML4 and DOM2 HTML were very vague specifications, leaving many things completely undefined, in particular error handling. HTML5, in addition to specifying many new features and specifying the rules for many features that were hitherto unspecified (like the Window object or how to parse HTML!), also specifies, in detail, the inner workings of all these features, along with how to handle all possible errors. This is a significantly more comprehensive effort. That’s what the three extra years (from the “last call” in 2009 to the “candidate recommendation” in 2012) are about: We’re expecting a lot of comments beyond the thousands of comments we’ve already received, and it will take time to deal with them.

We’re also fully intending to do something that none of the aforementioned specs really did, which is to have a comprehensive test suite that we will require at least two browsers to completely pass before we call it a day.

If one were to try to write such a test suite for HTML4 and DOM2 HTML, one would find that there isn’t even one browser that fully implements those specifications, let alone two. We want to have such a high bar with HTML5 to avoid falling into the trap of saying “ok the specification is done” before we can actually prove that it is possible to implement HTML5 as written. There are things in HTML4 and DOM2 HTML that simply will never be implemented as written by browsers, for example, because implementing the feature as written would mean not rendering existing Web pages as the authors expected. If we find such problems in HTML5, we’ll change the specification — but to find such problems, we have to write big test suites and that’s going to take a long time. That’s what the last 10 years of the timetable are about.

One of my favorite new items in HTML 5 are the <audio> and <video> tags, since it relieves HTML authors from having to deal with Flash, <object>, <embed>, etc. What other pain points do you expect HTML 5 to address?

I expect the iframe sandboxing feature will be a big boon to developers if it takes off. My own personal favorite feature is probably the Web Sockets API, which allows two-way communication with a server so that you can implement games, chatting, remote controls, and so forth.

A lot of the real pain that HTML5 addresses though is in things that are much harder to point out. For example, we now define exactly how an HTML document must be parsed, whether it is full of errors or not, so forgetting a closing end tag will no longer mean four different browsers do four different things. Similarly, we’re defining exactly how all the little APIs like window.history and location.href and setTimeout() work — APIs that everyone uses without thinking about but which have never been defined before HTML5. By having a strict definition of how these APIs have to work, we’re going to be able to get rid of a lot of weird browser bugs that have plagued authors for years.

What do you think will be the most contentious changes in HTML 5?

HTML5 defines sort-of-new meanings for the b, i, and small elements, which I thought would be really contentious, but really only a few people complained.

The things that ended up being the most contentious were things I didn’t really expect. At one point, I added a paragraph in the spec that said that we were looking for a royalty-free, patent-unencumbered, and low-submarine-patent-risk video codec, and we received a record number of e-mails on the topic overnight, as every news site on the Web seemed to take this as a sign of the apocalypse.

Another topic that’s received a lot of feedback is that we dropped acronym in favor of just using abbr, and a lot of people complained, though few could agree on what exactly the two elements would mean if we kept both.

More recently, there have been two big topics, both on what I consider to be remarkably unimportant parts of HTML, all things considered. The first was with the img element and its alt attribute. HTML4 requires alt but doesn’t give any advice about how to use it. With HTML5, I added a long section that describes how to use it in detail and said that in some cases (e.g., webcams), there might not be any useful replacement text, and so it would be ok in those cases (and only those cases) to omit the attribute. This caused a firestorm of protest from so-called accessibility experts. There were even some people arguing that Flickr (another site that today shows images but doesn’t always have suitable alternative text) should require photographers to always include detailed descriptions of every image they upload.

I tried to mitigate some of these arguments by requiring the alt attribute but allowing a special syntax to be used to say that there was no available replacement text, but that hasn’t proved popular either, and it has its own problems. It’s unclear exactly what we’ll do, but personally, I’m leaning towards going back to the first proposal, which was at least simpler, if not ideal.

The second big controversy in recent history was over extensibility. There have been some requests to allow people to extend HTML without speaking to the committees working on HTML. We’ve provided a number of mechanisms for this (the class and rel attributes, the data-* attributes, the meta element for page-wide metadata, the script element for non-script data blobs, the embed element for plugins), but some people simply want the ability to invent their own elements and tag names. So far, we’ve managed to avoid that, and we’ll have to see if we can continue.

Despite being a spec for nearly 10 years, many Web sites still do not validate against HTML 4, or are still using obsolete tags. Do you think that the adoption rate of HTML 5 will be higher than HTML 4?

Yes and no. I don’t think we’ll see a change in the fraction of pages that are conforming. I did a study using the resources Google provides me with and, in a sample of several billion documents, something like 90% of them had a syntax error of some kind — and that’s not even looking at whether they were nesting the right elements in each other or not. We have made some changes in HTML5 to make the syntax a little easier. For example, we now have allowed the “/>” talisman that XML introduced, and we’ve allowed IDs and class names to contain any character, since those restrictions weren’t really helping anyone. But other than such superficial changes, I don’t think that realistically speaking HTML5 is going to make people write better markup.

As to adoption, assuming we only consider adoption of the truly new features that HTML5 has introduced, then it will depend on where you look.

Blogs will probably use the new elements within a few years, as templates are updated and browsers start supporting the new elements — instead of lots of div elements with classes, people will be able to use elements like article, footer, and so forth. Web applications will also be big users of new HTML5 features — in fact, originally the HTML 5 specification was called “Web Applications 1.0″ because it focused primarily on introducing features for Web Applications like Yahoo! Mail or Google Calendar. An average page that is talking about medieval beekeeping, however, probably won’t have much use for many of the new HTML5 features, and it’ll be hard to say if authors of such pages are really “adopting” HTML5 or not.

To be honest, though, I don’t think it matters. HTML5 has already been enough of a success in bringing browser vendors together and addressing the many problems in HTML4 (like the lack of parsing rules for invalid documents) that whatever happens next, it was worth it so far.

The HTML 5 spec is aimed at a number of different groups: browser vendors, HTML authors, developers of HTML authoring tools, Web developers, developers of non-browser user agents (like search engines), and so on. Each of these groups has different, and sometimes conflicting, needs and opinions. How do you square these with each other in a way that makes sense?

Carefully!

It’s a very difficult balancing act. The users have to come first, with the Web authors a close second, but the problem is that if we ever specify something that the browser vendors disagree with, they will just ignore the specification, and we might as well go home. If we write a specification that is ignored, we’re just fiction writers.

Also, the needs of the users and the authors are often not what they tell you they are. I frequently hear requests from Web authors along the lines of, “We should add a feature to do X,” and when you point out that there is already a feature to do X, they say, “Yes, but the browsers don’t implement it.” Which is silly, of course, because why would they implement the new feature if they didn’t implement the old one? Similarly, authors ask for features to work around bugs in other features, instead of just asking for the bug to be fixed. A big part of my job ends up being reinterpreting what people are asking for into what they really want.

It seems like a good portion of the active members of the groups are on other continents. How do you balance the need to work with people all over the world, often in real time, with the need for a personal life?

I’ve basically ended up splitting my work day into two. I work about four hours in the afternoon, and then about four hours after midnight. This gets me online during most of the times that people are awake around the globe, while leaving my evenings free for my personal life. Luckily, this kind of work is not very time-sensitive, though. Also, a lot of the real communication is done by e-mail, which I check pretty much continuously while I’m awake.

Within the HTML 5 spec, there are changes to improve things like Semantic Web, accessibility, internationalization/localization (I18N, L12N), AJAX (and other Web 2.0 items), and so on. In the greater scheme of things, which of these do you think will have the greatest adoption rate in real-world usage? Which of these do you think will not be used as much as they should be?

I don’t know. If there’s one thing I’ve learnt through the extensive research we’ve done for HTML5, it’s that authors, on the aggregate, act in very surprising ways that don’t really match my intuition.

The features that don’t end up being used will be cut. We’ve already dropped a lot of things over the years, and I’m sure we’ll drop more — many of the forms-related things in the Web Forms 2.0 proposal which we’re about to merge into HTML5 are things that we’ll likely be dropping. For example, the repetition templates proposal is almost certainly going to be dropped.

What are the top five “gotchas,” surprises, and so on for HTML authors in the HTML 5 spec?

I’d love to say there are none and, if we knew of any, we would remove them!

Most of the “gotchas” in HTML5 are things that we’ve inherited from the legacy of the Web. For example, the address element is for contact information, not any address; the br element shouldn’t be used unless you’re writing something that really has a line break like a poem (generally people should be using p instead of br); and be careful when writing URLs, you have to escape the “&” characters by appending “amp;” after each one.

We’ve also introduced some unfortunate features of our own, though. One is that, while we’ve made it legal for the a element (used to define links) to contain entire paragraphs and lists, doing so can cause problems in browsers like Firefox that don’t yet implement the HTML5 parser algorithm. Also, while it can contain what we call “flow content,” it can’t be used to wrap individual list items or table rows.

If you could go back in time to the original HTML spec, what is one thing that you would change in it to make the Web a better place today?

Defining error handling from day one has got to be the most important change that I would ask Tim to make if I could speak to him then. I think we could have avoided a huge amount of the tag soup mess we have now if we had just defined simple error handling from the get-go.

It seems like being the editor of such a major work is a job that involves juggling a lot of differing opinions, trying to work with many software companies that are in fierce competition, and many other thankless tasks. For you, what is the most rewarding part of this?

HTML5 has had a big impact on the Web and the Web standards community.

We’ve raised the bar of what a spec has to do to be taken seriously; we’ve shown that it is entirely possible to develop Web technologies in a radically open manner; we’ve driven innovation and competition in the browser space; and we’ve shown that an open and vendor-neutral technology stack can compete seriously with single-vendor closed technologies. So it’s great to know that I’m a part of that.

I’ve also been really happy with the community that has grown around the WHATWG. Many people have stepped forwards and taken part, not just commenting on the proposals, but also helping with the infrastructure, maintaining the blog, the wiki, the forums, helping new members out, and so forth. It’s just been a lot of fun.

In closing

Thanks again to Ian for taking time out of his incredibly busy schedule for this interview.

As an example of how rapidly things change in this process, the “alt attribute” that Ian said was a contentious item has been changed quite a bit since the interview. You can see in the mailing list archives how the issue was handled.

Are there questions that you wish I would have asked Ian about HTML 5? If so, I’d love to hear them. Please post your proposed questions in the discussion forum.

J.Ja

Disclosure of Justin’s industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.

——————————————————————————————————————-

Get weekly development tips in your inbox
Keep your developer skills sharp by signing up for TechRepublic’s free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!