In this interview, HTML 5 Editor Ian Hickson talks about the spec's timeline, his favorite part of HTML 5, what functionality he wishes would make it in the final spec, and more.
My interview with HTML 5 editor Ian Hickson in August 2008 remains one of the most linked to and talked about posts in TechRepublic's Programming and Development blog. So I decided to check in with Ian to find out where things stand with HTML 5, and to learn the status of some of the hot topics from our previous interview. (Note: I am member of the HTML Working Group.)In our previous interview, I think you were very clear in explaining what you meant by the "2022" date for HTML 5 to become a "Proposed Recommendation." All the same, nearly every item on the Web that cites that interview is quoting that number, and in a way that clearly misunderstands what you meant. It seems like people are interpreting "2022" as the year that you will stop typing and say "it's done!" Why do you think that so many people have misinterpreted "2022?"
The standards process is complicated, and most Web specifications don't really do a proper job of following it through, so people aren't familiar with it, I think. A lot of people think that standards are written in closed rooms, brought out carved in stone tablets, and then handed down to the software engineers to turn into software, which of course is the furthest thing from how standards should be done and how HTML is being developed. A specification is really just like software, it has to be continuously maintained. When you stop maintaining a spec, just like when you stop maintaining software, it's dead.On the topic of HTML 5's progress, where does the specification currently stand, particularly in relationship to the timeline that you established for it?
We're pretty much on track, dealing primarily with feedback on mistakes in the spec and fixing bugs, but generally not adding new features. There has been some work in the WHATWG looking at some possible new APIs in HTML, for example for video conferencing, but that's not part of HTML5.A few years ago, it seemed like accessibility issues were the #1 largest contention point on the HTML 5 mailing list. Then that seemed to have shifted to Microdata and RDFa and other extensibility mechanisms. What do you see as potentially divisive topics in HTML 5 that have not been really talked about much?
The vast majority of the "divisive topics" are inside-baseball standards minutiae. To give you a taste, our two oldest controversial open issues are on HTML's versioning model (or rather, whether it should have one), and on the registration procedure for the values of the "rel" attribute of the "link" element. Over the years, the debates have usually been over areas like this, where there is a culture clash between groups who live "in the trenches" dealing with the "real world" of Web pages on a day-to-day basis and groups who live more in research or academia circles and have been working on standards for many years. Indeed, that clash was one of the factors that triggered HTML5's development in the first place.The status of the video tag has many people quite confused. Could you shed some light onto where video stands and how developers can use it and ensure that it will work across browsers? From people I have talked to, video is one of the most anticipated features in HTML 5.
There's not really any light to shed at the moment. Browser vendors disagree on which codec to use. Nothing has changed since then.Accessibility was such a hot button topic for HTML 5. What is the current accessibility story? How can developers use HTML 5 to produce accessible applications, particularly with regards to the new RIA functionality?
Accessibility is like internationalization, security, performance, and so forth: it's architecture, designed in from the beginning. With most of HTML's new features, just like with most of HTML's previous features, using them as specified in the specification is all that is needed to create fully accessible documents and applications.Along the same lines, what is happening with extensibility and technologies like Microdata and RDFa?
Microdata and RDFa are continuing to be developed.Has this been definitively settled and can developers start preparing to use extensibility?
I'm not sure what you mean by "use extensibility". Could you elaborate?By "use extensibility" I mean, "is the status of RDFa and Microdata settled enough where developers can start using them in their applications and not be concerned that the spec will change significantly?"
I can't speak for RDFa (from my perspective it seems to still have some pretty serious problems), but Microdata is pretty stable. It's still a draft though, so who knows.Also, which (or both) of these technologies will end up as being the sanctioned mechanism for this kind of work?
Which ends up sanctioned doesn't much matter; what matters is which ends up used. That's up to the authors. Maybe neither will be used enough to really matter!With the end of work on XHTML 2, many people have been concerned that HTML 5 will promote syntactic laxity.
HTML5 actually defines far stricter syntax and semantic rules than the latest XHTML2 proposals did, if I'm not mistaken. In fact HTML5 is the first version of HTML to strictly define the syntax down to the bytes — previous versions have always either been vague about this or relied on other specifications to fully define it.What is the relationship between HTML 5 and XML, XHTML, etc.?
The HTML specification defines two serializations, one using XML (known as XHTML) and one using the text/html syntax (known just as HTML). They are both strict, though the XML syntax is a bit more verbose.What functionality will not make it into the final spec that you wish could be in HTML 5, and why won't it get in there?
I wish we had had the time to finish the "datagrid" element. It ended up being more work than we could comfortably fit into the timetable, so we had to drop it. I'm sure we'll revisit it in the future though.How much change do you expect HTML 5 to undergo at this point? Can developers base work on the current draft and have relatively few changes to make, or should they treat it as simply an "item of interest" at this point?
The specification isn't really the deciding factor there; it's the implementations that decide when something is stable: once something is implemented and shipped, we can't change it any more! So I would say, if it works in browsers, then it's safe to use. Then again, if it doesn't work in browsers, there's not much point using it anyway!What's your favorite part of HTML 5, and why?
Before HTML5, it was normal for Web specs to be developed mostly behind closed doors, and it was normal for specs to not be very specific about what should happen, especially in the case of errors. The WHATWG has really helped change both of these attitudes.
J.JaDisclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.
———————————————————————————————————————————-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!