Shared publicly  - 
+Gerrit Imsieke, I'm a bit puzzled by

Why do you see +Aryeh Gregor's decision to write a spec outside the W3C as "thumbing his nose"? It's hard to imagine a more commendable behavior than spending months and months reverse engineering and spec'ing previously unchartered territory and to then release it under a license that allows anyone to reuse it, including the W3C. I'm not sure what you mean, but to expect that all spec development happen within the W3C would clearly be a "my way or the highway attitude".

(Concerning the last part, RDFa was never in WHATWG HTML, nor in W3C HTML. What's being considered currently is dropping the RDF (no a) conversion of microdata, which is quite a different matter.)
Jeni Tennison's profile photoPhilip Jägenstedt's profile photoGerrit Imsieke's profile photoIan Hickson's profile photo
Concerning the last part: when I read it this morning, I realized that what I wrote on dropping/including RDFa was wrong. As I said, I didn’t proof-read it prior to posting. If I had done so, I would probably have phrased it like “leave RDFa outside HTML but don’t make the renderers break when someone is using RDFa in HTML”. And that should be the final point: regard HTML (including a stable set of Markup, APIs, and the XML parser) as the platform technology on which to implement any of the existing or future semantic markup approaches. Or maybe have microdata as the preferred format while allowing RDFa. In return, I’d like to get back “traditional distributed extensibility” and no folding of the element names to lower case for the XHTML serialization / XML parser. (I’m writing this while hurrying from one meeting to another, so bear with me if I’m still not making myself clear).

The first part: it is always difficult to argue about people’s true motivations because only they know (if at all). Maybe others, such as +Julian Reschke or +Shelley Powers, who were very concerned about this fork, can further elaborate on their concerns. Maybe our critical view of +Aryeh Gregor’s publication, the timing, and the indifference about whether this should find its way into W3C HTML5 was only sign of a unwarranted mistrust. Maybe the truth is in the middle.

My main concern is that, no matter whether intended as a provocation or as augmenting a living spec, these things are going to happen. I was sketching a possible solution: not to aim at mirroring or “snapshotting” the detailed WHATWG spec at the W3C but define stable rule sets that authors, publishers and procurement agencies can rely on and that serve as fixed points for WHATWG’s detailed specs for the implementors.

Uniform standards for semantic data, basic document structure / semantics and APIs are desirable but in my view unachievable.
+Gerrit Imsieke My concern mainly is that we have a spec in LC, and people are "fixing" it somewhere else, instead of trying to do it inside the spec. It might be a symptom of the HTML5 spec being harder to maintain by multiple authors than it should be.
+Gerrit Imsieke, I didn't read any mistrust into +Aryeh Gregor's email. Just bureaucracy avoidance.

Also, if you use an XML parser, no case folding occurs. Case folding happens in text/html. If you use text/html, you by definition aren't using the XHTML serialization.
+Henri Sivonen I was thinking of mistrust the other way round: mistrust of the fixed HTML5 advocates against +Aryeh Gregor’s true intentions. In the sense that we don’t trust his aims of improving HTML to be sincere but suspect a well-timed “I told you so” assault: forking HTML5 even before it’s fixed, with the intention to show the world that W3C’s HTML5 is a paper tiger.
+Gerrit Imsieke Maybe +Aryeh Gregor simply didn't want to face W3C? Not representing an employer makes dealing with W3C odd. You cannot know the "true intentions", and therefore cannot exclude that he was being honest when he wrote to the mailing-list.
Sure, possible. If he feels like, +Aryeh Gregor may elaborate on his true intentions here. As per Google’s “real intentions” policy, everything we write here must reflect our true intentions. Otherwise we may be blocked. ;)
+Henri Sivonen if you replace "the W3C Process" by "the W3C Process as applied to the HTML5 spec" (which seems to make it impossible to add editors), then I might agree
I think it's safe to say that publicly questioning the intentions of people's hard work isn't going to help improve the (quite real) disconnect that exists. As a wise man once said, "they don’t write specs for the sheer joy of it" and they certainly don't do it out of spite.

As for improving the W3C process, I'd appreciate if people would discuss that elsewhere, where it has a chance of making a difference, such as

(That's enough peacemaking for me. I certainly don't have a perfect track record myself, so it's rather silly for me to preach.)
Congratulations, +Aryeh Gregor, on getting this substantial piece of work -- not only specification but also test implementation -- to a state where it's ready for review.
Clearly this highlights the issues that we've been discussing about numbered versions of HTML; it's good to have a real case to talk about rather than something abstract. I can see the problem with having the text included in the HTML5 specification: it's not at the same maturity level as some (I hope the majority!) of the rest of the specification, so if it's included then it would slow down the process of getting HTML5 to Recommendation. And if you consider that there's always something new round the corner, I can see how this could degenerate into never ending W3C Process cycle hell.

The question for me is what should/can/will happen with the part of the HTML5 specification that it supersedes [1]. Thinking about our previous conversation about numbered versions being useful for authors and tools/websites making conformance claims, I guess it boils down to: is what you've written backwards compatible with that section, such that a conformant implementation of your work will be conformant with it, or not? If it's not, shouldn't that section just be dropped from the HTML5 specification, and your document become (eventually, somewhere) a separate specification for Editing APIs?

My other question, more generally, is whether this general issue is something that it would be useful to raise at the TAG level? I think the answer is probably "NO!!! There is nothing you idiots could do except make things worse!!!" but it is part of our remit in the TAG to anticipate fundamental interoperability problems. It seems that this situation falls under that general umbrella and might be one where arguments coming from the TAG might carry weight. Anyway, it's something I'd be happy to raise if it would be helpful but quite understand if it really wouldn't be :)

For what it's worth, even though I don't agree with her, I think it's bad form to block Shelly Powers from participating in this thread. If you're confident in your own viewpoint you should welcoming dissenting opinions, unless they're being abusive which I've not seen evidence of her being.

With regards to this particular controversy, I don't understand why some people involved in the HTML5 effort at W3C seem to be shocked or upset. If you want versioned specs, you have to accept a cut-off, and you have to expect that the spec will therefore be superceded. I don't understand why anyone, particularly those working in the software industry, could require a concrete example to understand such an obvious point.
(For the record, the block was in effect since before this post. Blocking is global, not per thread. It's not something you do just because of civil disagreement, I would welcome that very much.)
+Aryeh Gregor I do appreciate you taking time to discuss this. None of the time I spend on anything web-standards related is paid, and I know how frustrating it is to spend loads of time talking about something when you'd really like to be just getting on and doing.

I can absolutely see the advantages for you in creating specifications within WHATWG rather than within W3C. I guess what I'm really after is trying to find a way whereby you can carry on doing that while still satisfying some of the requirements from the other portions of the web community, and in particular authors and non-browser tool implementers, who want something stable to work from. Not that I can necessarily do anything about changing how the W3C operates, but at least if I can understand your concerns then I can explain them to others.

So, I think that we have crossed wires somewhere about what we mean by 'author'. I was meaning "authors of documents and scripts that use the features defined in [HTML]" as opposed to "implementors of tools that operate on pages that use the features defined in [HTML]". [1] So things like DOM APIs that authors used within their scripts would count as something that an author would need to know about and rely upon being there and working as specified, and should therefore be in a stable spec for authors. The Editing APIs section in the HTML5 Edition for Web Authors [2] contains some interfaces that I'd like to be able to know whether I can use in a script that I don't want to have to revisit within the next 5 years, or not.

So what I've been arguing for is a series of versioned editions for web authors containing only the bits of HTML that browsers have actually implemented and moreover agreed that they will continue to support for the foreseeable future (eg 5-10 years rather than 1 year) so that authors know what they can actually use (both in terms of markup and scripting) in their pages.

Do you see any worth in that and if not, what are the issues?

The specifications that we're writing don't document what browsers implement today. They document what browsers are supposed to be trying to implement today and tomorrow. There is no documentation anywhere that accurately describes what browsers do today, because of browser bugs, etc.

Versions don't really make sense in this space either, because what browsers supports changes every few weeks, each time a new browser comes out; it's unrelated to the specification release cycle.

Nothing the W3C has ever published addresses the needs you are describing. Nobody is doing the work of writing a document that would.
+Ian Hickson I think Jeni wouldn’t contest that specs are about what systems should implement, rather than describing existing systems. But I’m not the one to guess anyone’s intentions, hehe ;)

So I’ll try to rephrase her idea as I perceive it.

Have a spec (or a set thereof) A that describes in detail HTML’s markup, APIs, rendering expectations, etc. Parts and details of this spec are considered as being more or less stable than others. Changes & clarifications may occur any time.

Have a spec (or set of specs) B that
– is aimed at document authors and application programmers
– exposes the markup and interfaces of spec A that are considered “reasonably” stable for a 5-year timeframe
– identifies the parts of spec A that are considered “moving targets”, outlining the most probable approach, summarizing alternatives, giving a target date for a stable & detailed part of the spec
– masks the bits that are considered “under the hood”

This spec B may be generated from spec A, using the current annotation markup as mentioned by +Philip Jägenstedt and additional markup that is deemed appropriate.

The W3C may attach version numbers to distinct renderings, such as 5.0.1, 5.0.2, or HTML5 (Third Edition). Especially the latter naming scheme worked extremely well for the more or less compatible versions of XML 1.0 ;)

Some guiding principles for both the editors of spec A and the denominators of spec B should be:
When diffing the latest fixed version against a “HEAD” rendering, the changes may consist of
– fixed typos,
– stability attribute promotion (towards more stable),
– uncontested clarifications,
– uncontested deprecations of formerly acceptable alternatives (e.g., some semantic markup approach) in a part of the spec that wasn’t declared stable,
– accepted (by W3C committee) material changes such as completely removing an alternative in an unstable part
– …
Other significant changes (especially in terrain formerly considered as stable) must also be accepted by W3C committee and typically necessitate a version number increment. Such an increment shouldn’t happen more frequently than once a year.
Technically, there will be parts that have been altered in set A but will come into effect in set B on a later date. So until that date, the previous version of that part has to be rendered for B. (People who are experienced in publishing legislation documents will know how to mark up, store and render these versions.)

Set A may be edited by the current team, and the review board for set B will be the kind of committee that you like so much. Note that the committee is not designed as a “design by committee” committee, just as a review board numbering entity and providing patent policy protection for the released numbered standards. (I’m just thinking that it’ll be tough for WHATWG alone to get patent policy arrangements for its living standard because the other parties will always fear that some hotspur editor will make unexpected changes that break the deal.)

But there have to be some basic principles upon which the “A-Team” and the B committee operate. The bylaws so to say. They’ll contain both operating and design principles, as well as some nonnegotiable constituents, e.g., “content authors should be able to declare content as editable at least on a block element level, using attributes or other declarative markup such as CSS” (I’m making this up). Or “there shall be an XHTML serialization format, an XML parser, and a non-normative grammar in XSD 1.1 or RelaxNG+ISO Schematron,” “It’s the sole responsibility of the A-Team to elect an editor & appoint new A-Team members,” “A-Team, initially consisting of Persons x, y, and z, will be commissioned for 3 years with yearly renewals.” Yes, I think it may be a contractual thing between W3C and a group of individuals or another organization.
There should be an independent arbitrator whose verdict both parties (Team B: W3C, Team A: WHATWG) commit to respecting.

That gives WHATWG relative freedom to get things done while giving the authors relatively stable specs. Finding the right balance between declaring things stable (authors’ interest) and keeping them unstable (avoiding version number increments) will be delicately tough.

Just my € 0.02
As far as I can tell, the spec I work on is basically both A and B simultaneously. We only ever more towards "more stable", and every section has annotations talking about how "stable" the section is. We also have a variant on B that only includes stuff relevant to authors, at

I'm considering changing the current way we do the specs at the WHATWG so that instead of the complete.html and HTML specs we just have one spec, which would present an opportunity to make a more explicit "B" version. If you're interested in being involved in figuring out how that should work, drop me a line at— it would really help me to know how the current spec differs from what you want from this "stable" spec.
Add a comment...