TwoIans

Ian Jacobs (IanJ) and Ian Hickson (IanH or maybe Hixie) plan to discuss W3C, HTML, and standards processes.

IanJ: First things first. I used to google "Ian" and my name would appear in the first page of search results. Now your name comes up first. I realize you work at google, so maybe you can help me out and put me back ahead of you. Now that that's out of the way...

IanH: You come up first for me when I search for "Ian"... Google personalises the results based on what it thinks you want, so clearly that just means you want to know about me and I want to know about you! You can click the up arrow next to the result you want first if you want to change the results though!

IanJ: I'm looking forward to this discussion. Here are some initial thoughts for what I'd like to get out of the discussion:

There are something like 47 billion messages on the HTML mailing lists (WhatWG and W3C). I don't follow the discussion closely, but I still want to understand the main issues that cause all that ink to flow (and all those passions to flare). Because you are the lead editor, I bet that you have a strong grasp of the constellation of arguments and perspectives around each thorny issue. If you are willing to explain them to me (including views you disagree with) I'd be much obliged.
I would like to learn how you edit specs (an activity I happen to like). The community that uses HTML has grown and therefore you and the Working Group have to manage a large set of expectations and input. Can you shed light on your editing process?
Because of the unique role of HTML to the Web, I understand that a number of other W3C groups (and possibly groups outside W3C) are very interested in ensuring that the language and APIs support their technology or community. Given the volume of mail and the size of the community, do you have suggestions for how groups (or individuals for that matter) can best be heard within the group? What role do stories, use cases, and test cases play?
I'd like to talk about W3C Process and hear your thoughts on strengths and weaknesses. I would hope that this piece of the discussion would lead to clarifications of various views on process, as well as to some suggested changes. I can convey suggestions to the W3C Advisory Board, who manage the Process Document.

IanJ: I hope that TwoIans can produce something useful. I'll count on you to provide the technical substance and I'll tell a few jokes from time to time and say "Hmm, that's fascinating. How many lines of code?"

IanH: Sounds great! Let's get started!

Technical Topics

IanJ: I'm not sure where to start (but have looked through Sam Ruby's HTML 5 evolution).

IanH: Note that Sam's document there is missing a lot of key events; for example it omits one of the most important events in HTML5's development, the W3C Workshop in 2004 at which the W3C originally rejected the proposal to extend HTML. A much more complete and balanced overview of the evolution of HTML5 is Mike Smith's "HTML History" document: http://esw.w3.org/topic/HTML/history

IanJ: HTML extensibility is clearly a hot topic; I don't see extensibility mentioned in the HTML Design Principles (although maybe it is part of 2.5. Evolution Not Revolution. Seems I should read this HTML Reunification post by Sam Ruby and the thread that follows before asking any questions about HTML Extensibility. It would be convenient to work on a short description of the issues and proposals. If such a thing exists, do you have a pointer?

IanH: I don't think HTML extensibility is really a hot topic. There are maybe half a dozen people who raise the issue a lot. I don't know of a summary of the issues and proposals of the few people who do raise this issue a lot; in fact they haven't (as far as I'm aware) filed any bugs or raised any outstanding issues with any technical feedback. This makes it difficult to know what they want!

IanJ: I see in a WASP Interview from 13 May that you wrote "...We considered RDFa long and hard (in fact this is an issue that’s a hot topic right now),...". That sounds like the hot topic I'm talking about. The HTML Working Group's issue ISSUE-41 Decentralized Extensibility (still open) seems to be about this topic as well.

IanJ: Regarding use cases (some are documented in RDFa Use Cases), I found this lengthy 15 May email from you that appears to look closely at them. I have not yet read the whole email; I still have a lot to learn. It does seem, however, that there's been some evolution in the spec (and discussion) since then. I found this message about rdfa and html5 and it appears that there's some dialog about RDFa use cases and some concerns raised by the first draft of properties introduced to address the use cases.

IanH: In practice very few people are unhappy with the dozen or so extension mechanisms HTML5 has now. The WHATWG FAQ — a good source of information about HTML5 in general, actually — lists these extension mechanisms as follows:

Authors can use the class attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.
Authors can include data for scripts to process using the data-*="" attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.
Authors can use the <meta name="" content=""> mechanism to include page-wide metadata. Names should be registered on the wiki's MetaExtensions page.
Authors can use the rel="" mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's RelExtensions page.
Authors can embed raw data using the <script type=""> mechanism with a custom type, for further handling by a script.
Authors can create plugins and invoke them using the <embed> element. This is how Flash works.
Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.
Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)

There is currently no mechanism for including non-visible proprietary metadata intended for use by user agents in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.

Of course, anyone using XHTML can leverage XML Namespaces to introduce whatever extension elements or attributes they want.

IanJ: Your comment on XHTML suggests that people may be able to leverage xml namespace extensibility if they want, but the Dom Consistency entry in the HTML Design Principles says: "The two serializations should be designed in such a way that the DOM trees produced by the respective parsers appear as consistently as feasible to scripts and other program code operating on the document trees." Does this mean that I can create some DOM trees using the XML serialization that I can't create using the HTML serialization? I have not read HTML 5 (which I suspect I'm going to have to do as part of this exercise) so feel free to ask me to read a particular section.

Community Interaction

IanJ: I mentioned above that I am interested in understanding how the community (including other groups at W3C) can get involved in the development of HTML 5. In the WASP interview, you pointed to some advice for providing input. You said about new features: "It’s often tempting to make something that is theoretically neat, but which doesn’t fit in with the rest of the language, too. After all, that’s where all this came from—we don’t want to create a new XForms, a really well-designed technology that doesn’t fit into the way people write pages." I would love to read a document "How People Write HTML Pages." That might help people understand the model you have in mind and that is the model you expect others to fit into. You might say to me "HTML 5 is that document!" Yes, I realize that one way to interpret "the way people write pages" is "what the bulk of HTML looks like out there." That would motivate having a detailed discussion of parser and error handling. Understanding how a parser views the Web won't help people design new features. I believe you've got a bunch of data (presumably via google) about tags that people seem to want (presumably via frequently encountered class names). That is an interesting way to build a proposed set of new features. What can you share about "how people write Web pages" that will help people understand the spec and also understand how to make the case more effectively for new features?

On Editing

IanJ: I've been an editor in different groups, and my "editorial activism" has varied. When working on Architecture of the World Wide Web with the TAG, I mostly tried to synthesize the viewpoints I heard until people were satisfied. In the User Agent Accessibility Guidelines I felt the situation was largely reversed; I was writing a lot of proposals and getting feedback from the group, which I then integrated. Editors are given the responsibility of incorporating ideas from a number of places. In the WASP interview, you refer to the editorial judgement that is required of you: "So I have to make judgements about what is worth adding [to HTML5] and what isn’t, and that’s hard." Do you consider that you are the ultimate arbiter of what will go in the HTML 5 specification? Is there an HTML Working Group decision process that would cause you to make changes that you may not agree with? I realize that if there were too many things you disagreed with you might work on the spec elsewhere. I'm curious how much elasticity there is before you "snap." :)