Re: Renamed topic: focus and length of HTML5

On Sun, 6 Dec 2009, Julian Reschke wrote:
> Ian Hickson wrote:
> > > > I'm not sure to what you are referring here. I would have thought 
> > > > the milestone of "zero open issues" was a pretty uncontroversial 
> > > > milestone definition -- it's the same one we're using in this 
> > > > working group, no?
> > >
> > > I simply don't think "no open WHATWG issues" is a significant 
> > > milestone, when we have several other bug trackers containing open 
> > > issues.
> > 
> > Do you think the W3C HTML WG should hold up progress if the WHATWG 
> > claimed to have unresolved issues, even if those same issues had been 
> > resolved in the W3C HTML WG?
> 
> Where's the WHAT WG issue tracker

http://www.whatwg.org/issues/


> and the process related to it? 

http://www.whatwg.org/charter


Do you think the W3C HTML WG should hold up progress if the WHATWG claimed 
to have unresolved issues, even if those same issues had been resolved in 
the W3C HTML WG?


> > > > That the specs exist is not a point in support of modularisation 
> > > > or a point against it. In fact there is also a spec that exists 
> > > > that has many of those specs in one document. By your logic that 
> > > > would support the point that modularity is bad, which is a 
> > > > contradiction (since both exist).
> > >
> > > The existence of a document that combines the contents from a set of 
> > > smaller documents doesn't prove anything.
> > 
> > I agree. That's my point. The existence of a set of documents that 
> > split the contents from a bigger document doesn't prove anything 
> > either, counter to your claim above (where you said "this seems to 
> > support the point that modularity is good").
> 
> It proves that it's possible to do, and that the benefits are as 
> advertised; for instance, that the LC process for XHR can be separate 
> from HTML5.

Actually, XHR and HTML5 have two-way dependencies that have made progress 
of both drafts dependent on each other.

So XHR is not evidence that modularity is good, and that's with topics 
that are almost as independant as is possible on the Web platform. I think 
your original point, that it would be beneficial to split HTML into 
several documents (of which one would be Microdata), is seriously flawed, 
as I have demonstrated over the past few e-mails.

(I do think that splitting XHR out of HTML5 was a reasonable thing to do, 
for various reasons that don't apply to microdata and that I therefore 
won't go into here, but efficiency was not one of those reasons.)


> > > > I wasn't implying that I would edit them. From the point of view 
> > > > of editing _any_ specification, having more smaller specifications 
> > > > that interact with it would make the editing take longer. For 
> > > > instance, it is easier for me to write specifications that 
> > > > interact with CSS2.1 than CSS3 modules.
> > >
> > > And that's why? In addition to the fact that you need a longer table 
> > > of document references?
> > 
> > I'm not sure why. I'm just reporting my experience here. My experience 
> > seems relevant if I'm to edit some of the specs in question; at least 
> > as relevant as Shelley's opinion and your opinion on the matter.
> 
> Well, I'd like to understand the *reason*; maybe the problem is related 
> to tooling and could be fixed.

I don't think it's the tooling; the same has been true with every spec 
effort I've worked on. Working on CSS3 modules (with one editor each) was 
less efficient than working on CSS2.1 (with multiple editors). Working on 
Web Applications 1.0 (with one editor) was more efficient than working on 
the thirteen or so specs that exist now (with the same editor). Working on 
HTML5+XHR (with one editor) was more efficient than Anne and I working on 
HTML and XHR separately (with one editor each). The only common threads I 
can see are me, and that more monolithic efforts were more efficient than 
more "modular" efforts.

My point is that the rationale that splitting out Microdata would help it 
progress faster because modularity leads to faster spec development is 
mistaken, at least in my experience -- and since I'm most likely to end 
up editing this, my experience does, for once, seem relevant.


> > > If we didn't have consensus for <section>, then yes, the best thing 
> > > would be to remove it and develop a spec separately.
> > 
> > If we didn't have consensus for <section>, then we shouldn't have it 
> > at all. Similarly with microdata -- if the working group doesn't think 
> > we should be working on it, then we shouldn't be working on it -- 
> > which document something is in has nothing to do with whether we agree 
> > with it or not.
> 
> Yes, it does. Because we are currently approaching LC for the document 
> called "HTML5", so we need to find consensus on its content right now.

The technical merit of Microdata isn't affected by which spec it's in. If 
it is not an acceptable technology, then let's drop it altogether. If it 
is acceptable, then it should be in HTML5.

What is being proposed here is _not_ to drop the feature altogether, but 
merely to put it in a separate deliverable -- one that most likely would 
progress _faster_ to LC than the rest of the spec (since it is basically 
ready and there are few outstanding issues on that part of the spec). So 
if we don't have consensus on this part of the spec going to LC, splitting 
it out to make it go to LC faster doesn't seem like a rational way to go.

(It wouldn't progress further than LC faster than the rest of HTML5, of 
course, since it is an integral part of the language and depends on all 
the stuff in HTML5. And indeed the whole thing is already in LC at the 
WHATWG, so it wouldn't be especially useful to fast-track just that 
section to LC here without the rest of the language.)


> > > <img> is in wide use and uncontroversial, so I don't see the 
> > > connection.
> > 
> > Microdata is significantly less controversial today than <img> was 
> > when it was introduced.
> 
> Introduced into the spec, or implemented by UAs?
> 
> (That being said I'm not sure how this is relevant).

The arguments that you and others are putting forward against Microdata 
are very similar to the arguments that were put forward against <img> when 
it was first proposed. Yet now you think <img> is not controversial, but 
still think Microdata is controversial -- even though <img> hasn't 
particularly changed since those proposals.

(alt="" was added, actually, but that wasn't the source of controversy, so 
for the purposes of this discussion it doesn't seem relevant.)

The relevance is that just like <img> should indeed have been in HTML from 
the time it was proposed, despite the controversy, Microdata should be in 
HTML, despite the (significantly lesser) controversy.


> > > microdata has no significant deployment
> > 
> > It's only just reached LC at the WHATWG, and isn't even in LC at the 
> > W3C, surely it wouldn't be appropriate per W3C process for it to have 
> > any deployment at all.
> 
> Ahem? So what about the current deployment of <canvas> or <video>? Do 
> you consider those inappropriate as well? Please elaborate.

Per W3C process, yes, the implementations of those features are 
inappropriately early.


> > > is controversial
> > 
> > That doesn't seem particularly relevant. Lots of things are 
> > controversial, that doesn't mean we shouldn't address their use cases.
> 
> The discussion is about "how", not "whether".

Lots of things are controversial, but it doesn't appear the working group 
is considering fragmenting the HTML spec for those. What is special about 
Microdata? Or do you think we should split the HTML spec into a different 
subspec for each controversial component?


> > > and competes with another W3C technology, so the situation simply is 
> > > different.
> > 
> > Technologies competing is not a problem.
> 
> They are if they are the work product of the same WG, and the WG doesn't 
> treat them the same way.

I think RDFa should be part of HTML5 just like Microdata, assuming that 
RDFa is kept at all. I completely agree that it is inappropriate for us to 
be treating them differently.


> > > > (Other factors would; e.g. whether or not implementations exist.)
> > >
> > > So a much less controversial way to do this would be to develop a 
> > > feature like this as a separate spec, and then *potentially* 
> > > consider integration once it has succeeded in practice.
> > 
> > That line of reasoning would have us split the HTML5 spec into dozens 
> > or maybe even hundreds of subspecs. I don't think that's a sensible 
> > approach to spec development.
> 
> So far I see requests for a few splits, not hundreds.

Indeed -- the line of reasoning you put forward is clearly not being 
followed consistently.


> > > The only reason why Microdata is in the spec right now is because 
> > > you made that choice, and had the editorial power to do so.
> > 
> > We're not arguing about whether the spec is in the spec now, but 
> > whether it _should_ be in the spec now. If it wasn't in the spec now, 
> > we'd still be having this argument.
> 
> No, we wouldn't.

So you're saying that if we had split the section out a few months ago, 
you wouldn't be arguing against me when I put forward a change proposal to 
put it back in?

If that is the case, why are you arguing against us keeping it in now?


On Sun, 6 Dec 2009, Shelley Powers wrote:
> On Sat, Dec 5, 2009 at 11:14 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Sat, 5 Dec 2009, Shelley Powers wrote:
> >> >>
> >> >> Now is exactly the time to consider removing it.
> >> >
> >> > Now is a time to consider removing it entirely (it's always that 
> >> > time, for that matter), but it doesn't make sense to put it in a 
> >> > separate spec.
> >>
> >> Ah, OK. You have a good point here.
> >
> > Great, I'm glad you agree.
> >
> > Does that mean you no longer support Manu's proposal?
> 
> No, I do support it.

So you agree that it doesn't make sense to put it in another spec, but you 
support the proposal to put it in another spec?


> Once Maciej explained that splitting Microdata off from the spec is 
> equivalent to just dropping it altogether--that those of us wanting it 
> split out aren't encumbered with having to create and maintain the 
> separate spec--I felt that his answer addressed your concern of a 
> separate Microdata specification.

I think you misunderstood Maciej's response.

The net effect of Manu's change proposal would be a spec for Microdata 
being proposed for FPWD and LC.


> You don't like Microdata, you don't agree with having it at all, so if 
> the original author doesn't like Microdata, and the support from others 
> is lukewarm, at best, because I don't see any folk volunteering to 
> maintain a separate draft of it if it is split, then it's time to pull 
> it out of HTML5.

I would edit a split-out draft.


> >> Individual modules edited by multiple people would most likely take 
> >> no longer, and in fact, would take a shorter period of time then if 
> >> one person was editing.
> >
> > This is academic, since we don't have more editors. There are 
> > literally dozens of specs that are just lingering with no editors 
> > right now. If we had editors, there are far more important and more 
> > useful things they could do than edit documents that already have 
> > editors.
> 
> I'm not quite sure what question you're answering here, or what comment 
> you're responding to. My point is that multiple specifications with 
> multiple editors won't take longer than having one editor do it all.

My point is that talking about multiple specifications with multiple 
editors is irrelevant since that's not what it being proposed. Splitting 
out microdata would not help HTML5 or Microdata go faster as you 
suggested; that rationale is not a valid rationale for spltting out 
Microdata from HTML5.


> >> Even as a writer, I'm part of a team. There are individuals that 
> >> determine whether there is a market for a book. I have a lead editor 
> >> who helps ensure my Table of Contents and outline touches all of the 
> >> important points of the topic. There are tech reviewers who ensure 
> >> that the material is correct (or as correct as possible), and then 
> >> copy editors who help me find all my typos. Then there's the 
> >> production staff.
> >
> > It sounds quite similar to HTML5's development. HTML5 had been 
> > developed by literally hundreds of people -- just see the 
> > acknowledgements.
> 
> No, that is not the same thing.

While you might not appreciate the volume of help provided by the hundreds 
of people who have commented on HTML5, I do. This is most definitely not a 
solo effort.


> >> So, no, I completely disagree that it would take longer to have more 
> >> editors.
> >
> > I didn't say it would take longer to have more editors. I said it 
> > would take longer -- does take longer, today, in practice -- when 
> > specs are divided into small modules instead of having a one document 
> > per focus area. One document for the language layer 
> > (HTML/SVG/MathML/DOM), one document for the network layer (HTTP), one 
> > document for the styling layer (CSS/CSSOM/XBL), etc. We'll never get 
> > to the level I'd like, but we can get close, e.g. by splitting the 
> > language layer into four documents giving the vocabulary and APIs for 
> > HTML, SVG, MathML, and one for the common syntax (XML). Similarly, CSS 
> > and XBL can be split. But I think it would be a terrible mistake to 
> > further subdivide -- splitting HTML into smaller bits would cause 
> > problems just like splitting CSS into smaller bits has caused 
> > problems. It _does_ take longer when the specs are split up. This 
> > isn't theoretical, it's going on right now.
> 
> That makes no sense. You're arguing for a practice that has demonstrated 
> itself to be grossly ineffective in our distant past. In fact you're 
> arguing against current established practices in technology. We have 
> learned that it's better to create focused deliverables than create 
> monolithic works that attempt to solve everything.

You keep saying this, but it directly contradicts my experience at the 
W3C. It might be true in other realms, but it is simply not true here, at 
least from the point of view of efficient use of editing time, which was 
the rationale put forward.


> >> More importantly, more editors ensures an essential 
> >> comprehensiveness.
> >
> > Actually in my experience it's the other way around -- editors tend to 
> > silo themselves, leading to gaps between specs. For example, 
> > separating HTML4, DOM2 HTML, and XHTML1 led to huge gaps in the specs 
> > that we spent significant effort fixing in HTML5. Avoiding this has 
> > been one of the important features of work with Adam, Anne, Lachlan, 
> > and Larry (who have edited specifications spun out of HTML5), and it 
> > has not been easy. Ask Anne, for example, about handling the event 
> > loop mechanism. Ask Adam or Larry about ensuring that we keep a 
> > coherent interface between their specs and HTML5. It's easy to see how 
> > having more editors can quickly result in a _loss_ of 
> > comprehensiveness -- quite the opposite of ensuring it, as you assert 
> > above.
> 
> Huge gaps?

To take one example from thousands, where do HTML4-era specifications say 
what should happen when a script in an HTML page changes the value of a 
"type" attribute of an <input> element from "text" to "checkbox"?


> Yes, there will always need to be work between groups to ensure that the 
> specifications work consistently with each other. But you're talking 
> about an event loop mechanism: what does that have to do with HTML, a 
> markup?

Given the following HTML snippet:

   <form>
    <input name=x onchange="x.value = '1'">
    <input name=y onfocus="x.value = 'A'">
   </form>

...what should the value of the first text field be when you tab to the 
second text field?

Where do HTML4-era specificatiosn define this?

Which spec do _you_ think should define this?


> Absorbing everything into HTML5 with one editor, yourself, may give you 
> the level of control you feel comfortable with, or believe is necessary, 
> but that doesn't mean that the end result is better. Or that the work 
> will be less.
> 
> What multiple editors and specs require is a level of cooperation. It 
> also means not necessarily having complete control.

Control has nothing to do with this -- for example, the above examples are 
fixed by what implementations do, not by anyone's opinion, and what the 
specs end up requiring will be the same regardless of who edits it.


> > My opinion is irrelevant to this discussion, though (as is yours) -- 
> > the chairs have indicated that we are to provide rationales, not argue 
> > based on our opinions.
> 
> Opinions do matter -- what do you think rationales are based on?

Facts, logic, research?


> And debate can be healthy. Sometimes compromises occur from debates.

Debate based on facts, logic, and research, sure.


> >> As for being defined in the same spec, because Microdata is based in 
> >> HTML, why? There are probably hundreds of thousands of examples of 
> >> libraries and extensions and modules that are based on a "language" 
> >> but are not part of the core. Why would HTML be different? HTML is a 
> >> markup language--nothing more, nothing less.
> >
> > What should be part of HTML is what affects the conformance criteria 
> > for HTML conformance classes. Microdata does. I guess a parallel with 
> > software development would be that code that implements the interface 
> > for a library should be in that library.
> 
> Oh, no, there's nothing about Microdata that impacts conformance of 
> HTML.

...? What _does_ it impact, then? Surely the microdata features do nothing 
_but_ impact the conformance criteria for HTML conformance classes.


> And it is most definitely not equivalent to an interface for a library.

I couldn't agree more. You suggested it was.


> It is a separate section. It could be pulled cleanly, with no impact at 
> all to HTML, the markup language. Or the DOM. or the XHTML 
> serialization.

We could just as easily remove title="", class="", id="", <p>, <img>, 
onclick="", or any number of other features that are all just as much part 
of HTML as microdata.


> > (Also, HTML is far more than just a markup language. It's also a 
> > vocabulary and a set of APIs, and is part of an application platform.)
> 
> No, it is NOT an application platform. HTML is a markup language.

That may have been true in 1992. It stopped being true years ago. Forms 
and event handler attributes are features that have been in HTML for over 
a decade, and they are application platform features. HTML5 goes orders of 
magnitude further down this road -- if you believe HTML is not an 
application platform, then you should argue for the removal of <canvas>, 
<progress>, manifest="", all the new form features, all of the APIs, the 
support for document.write() in the parser, several of the <meta> and 
<link> features, <script>, <noscript>, <menu>, <details>, <command>, the 
command mechanism, hidden="", contenteditable="", draggable="" and the 
drag and drop model, and all the script states in the parser.

Claiming HTML is not an application platform is trying to push the genie 
back into a bottle that was lost years ago.


> In the past, we had separate specs for the DOM, since that has, 
> typically, a different audience than the markup. And we had a separate 
> spec for the XML serialization of XHTML. I think the spec should be 
> split down into these three, because to be blunt, past specifications 
> are sure a lot more consistent and readable than the monolithic effort 
> of this group.

I've already mentioned that this is false in this very thread. The 
HTML4-era triad of specifications suffered dramatically from the silo 
effect of splitting efforts like this. See the questions earlier in this 
e-mail about scripting form controls.

There are also things in HTML5 that wouldn't fall into those three specs. 
Consider <iframe>. Where would you define that setting its src="" 
attribute to about:blank should synchronously navigate the element's 
nested browsing context while setting it to another URL should not? Where 
would you define how history.go() interacts with the <iframe>'s nested 
browsing context's session history?


> However, leaving aside those three core functionalities, this group is 
> not chartered to create a specification that's only for browsers, and 
> primarily focused only at users with specific needs, such as Ajax 
> developers, or companies developing applications, like the Chrome OS.

HTML5 isn't even remotely limited to those conformance classes.


> However, we have a change proposal in place that hopefully will allow us 
> to tame this unmanageable beast, and still provide the specifications 
> that meet the Ajax developers and the company that's creating the Chrome 
> OS. But not by sacrificing clarity, succinctness, and every other user 
> agent and user that are dependent on HTML.

HTML5 is not "sacrificing clarity, succinctness, and every other user 
agent and user that are dependent on HTML". That is a completely unfounded 
criticism. The whole spectrum of conformance classes are addressed in 
HTML5 with the same level of detail.

Furthermore, to claim that the Microdata chapter is contributing to making 
the specification an "unmanageable beast" is simply ludicrous rhetoric. 
The chapter is reasonably self-contained and readers would find their 
understanding of other parts of the spec completely unaffected by the 
existence of this section.


> > This seems to be a complete non-sequitur. HTML makes use of a gread 
> > deal of other technologies. We're not reinventing everything from 
> > scratch. That has nothing to do with what we're talking about.
> 
> But you're trying to absorb unrelated technologies into the HTML 
> specification, seemingly because you want to control how all of it is 
> created.

I would greatly appreciate it if you would not make such wild accusations 
or assert hostile motivations. No "unrelated technologies" are being 
absorbed into HTML5; that's hyperbole. The spec set out to achieve certain 
goals and those goals have not changed over a period of over half a 
decade. The specifications that HTML5 sets out to replace are explicitly 
listed in the Status of this Document section as required by W3C 
publication rules, and the list has not changed since that section was 
first written several years ago.


> >> I could go on, but you're a tech, you know what the rules of good 
> >> application development are. The rules for developing the 
> >> specification should be no less.
> >
> > The "rules" you speak of do not suggest randomly fragmenting a 
> > specification or application along arbitrary lines based on the 
> > preferences of members of the team. Applications separate logically 
> > separate components. Using your analogy, what you and Manu are 
> > proposing is akin to taking an application and putting some functions 
> > in another file despite them being part of the same component. What 
> > you are proposing is emphatically _not_ equivalent to separating 
> > unrelated code into different modules with minimum interaction.
> 
> Oh, no, there is no random fragmentation in my recent bugs.

If there is a pattern to the suggestions, I haven't yet been able to 
determine what it is, maybe because you haven't filed all your requests 
yet. If there is a coherent set of principles that you are using to decide 
along what lines the spec is to be split, I would recommend filing a 
single bug asking for that split and stating the overall rationale. 
Ideally such a rationale would be something objective that any reasonable 
person could apply to the spec to reach the same conclusions regarding how 
the spec should be split.


> Every bug I file I also plan on following up with a detailed change 
> proposal.

Even if I address the bug as you request?


> > You seem to have done a complete 180 in your argument here. First you 
> > were arguing that it IS easier to add a feature later than remove it, 
> > and now you are implying that it SHOULD be easier! What _should_ be 
> > easier or harder is not at issue here, the point is that if you think 
> > we need to ensure it is easy to remove microdata later, that we make 
> > sure that it is -- and indeed we have, as I have explained.
> 
> There is less impact to adding to the specification later, than there is 
> removing sections later.

On the contrary. If we're removing a section, it's precisely because 
there's no impact. On the other hand, _adding_ a section would at a 
minimum require is to go back to LC. Therefore I would argue that your 
assertion is exactly backwards -- there's far less impact to removing a 
feature later than to adding it. In fact, the W3C process specifically 
allows for removing features after LC (the "at risk" label) precisely in 
order to make the impact of removing features less than adding features.


> So, yes, it is easier, or perhaps I should say, less disruptive, to add 
> than remove at a later time in the creation process.

As I have already explained, your assertion is disproved both by the very 
development process you are trying to apply it to, and by the development 
processes of other specifications that I have been involved with in the 
past ten years at the W3C. Please don't just ignore what I've written and 
reassert your points as if they have not received a reply. If you disagree 
with my points, explain why.

The arguments in question were:

| > What's another thing we know from application development? It's easier 
| > to add at a later time, then it is to remove.
| 
| This indicates a lack of familiarity with HTML5's development over the 
| past few years. We have dropped numerous sections with far less effort 
| than they took to be written. Repetition templates, <datagrid>, form 
| prefilling, space-separate form="", peer-to-peer TCPConnection, the 
| <eventsource> element, <datatemplate>, <font>, the entire "out of scope" 
| section, several introduction sections... Not to mention the numerous 
| sections that were split into other specs, such as XMLHttpRequest, Web 
| Storage, Web Database, Web Workers, Web Sockets API, Web Sockets protocol, 
| the Server-sent Events API, Content-Type sniffing, and URL parsing.
| 
| No, if there's one thing we _do_ know about HTML5, it's that we've had no 
| trouble dropping features. In fact the _only_ exceptions I know about are 
| the ones that you mentioned, and the only reason we've had trouble 
| dropping them is that you and others have objected to dropping them 
| (summary="", for example). I presume that wouldn't apply here, since you 
| are specifically _asking_ that we drop them.
 -- http://lists.w3.org/Archives/Public/public-html/2009Dec/0139.html

| > One difference is that these were removed *before* LC.
|
| IMHO this is not a relevant difference. I have been editor of several 
| specifications that have gotten to LC or even CR and still had huge 
| sections removed. I've also been part of several efforts (including HTML5 
| itself) that have dropped entire sections after those sections have 
| reached REC. I do not think that the status of the document in the W3C 
| process would have any effect on our ability to drop the sections.
| 
| (Other factors would; e.g. whether or not implementations exist.)
 -- http://lists.w3.org/Archives/Public/public-html/2009Dec/0173.html


> >> > Are you saying that the W3C HTML WG should wait for WHATWG process 
> >> > issues to be addressed, if the situation was reversed?
> >>
> >> I'm saying that knowing there were bugs and issues still open in a 
> >> database you partnered with. When we're ready to go to LC here, I 
> >> would hope that if there are bugs in the WhatWG database, that 
> >> someone has copied said bugs into the W3C bug database, so everything 
> >> is tracked in one place.
> >
> > But what if the bugs were then resolved in the W3C bug database, but 
> > not the WHATWG one? Would you suggest that the W3C should continue 
> > waiting for a resolution on the WHATWG side before publishing, even if 
> > there was no timetable for doing so?
> 
> I would most likely go to the WhatWG database, and if the bugs are 
> specific to what's in the W3C version of HTML5, copy them over to the 
> W3C bug database.

And if the W3C resolved one of these bugs before the WHATWG, what would 
you suggest the W3C do? Would you suggest that the W3C should continue 
waiting for a resolution on the WHATWG side before publishing, even if 
there was no timetable for doing so? Or are you saying that you'd keep 
reopening the issue on the W3C side so long as it wasn't open on the 
WHATWG side?


> > That's the equivalent of what happened here -- the W3C issues have all 
> > been given full consideration in the WHATWG, the WHATWG just came to 
> > conclusions faster.
> 
> No: as far as I know. there is no change proposal in place at the 
> WhatWG.

Removing microdata was considered months ago, and rejected.


> No offense, but you are more or less supreme ruler in the WhatWG.

This shows a rather serious misunderstanding of the WHATWG process, but 
explaining the WHATWG process is off-topic for this group.


> And there are many people involved with HTML in this group that are not 
> in the WhatWG.

Over 700 people have sent e-mails to the WHATWG list. The W3C HTML WG 
doesn't even have that many subscribers. So I wouldn't persue this line of 
argumentation to suggest that the W3C HTML WG is somehow more important.


> After all, there are only a handful of allowed members in the WhatWG. It 
> is by invitation only, after all.

The WHATWG is completely open, the invitation-only component is equivalent 
to the chairs of the HTMLWG (which are similarly by invitation only).


> >> Regardless, the announcement caused confusion. We should do 
> >> everything in our power not to cause confusion.
> >
> > I haven't seen any confusion. Do you have any pointers?
> 
> Oh geez, yes. Just search on the terms "html5 last call".

Could you be more specific? I don't see anyone confused on the results 
page for that query, but maybe the results I get from Google are different 
than the results you get; or maybe we are using different search engines.


> >> A web page is made up of many parts, each of which is defined in a 
> >> different specification. CSS, HTML, ECMAScript, even the protocols -- 
> >> all working together to create a whole that works, and is displayed 
> >> as the web page.
> >>
> >> All these specs don't have to be in the same document. The same as 
> >> applications don't have to consist of one single file.
> >
> > I agree entirely. The separate parts should be in separate documents. 
> > CSS, HTML, ECMAScript, and HTTP are separate parts. Microdata, 
> > however, is part of the HTML part, just like title="", class="", 
> > id="", onclick="", <img>, and so on.
> 
> Ian, I don't want to get chastised for this, but I think your response 
> is a little disingenuous. I do believe you know what I was saying here. 
> The same as I believe you know there's a difference between one element, 
> and the entire Microdata section.

No, I really don't understand what you are proposing. If we put the 
class="" and id="" attributes into their own section, would they be as 
independent as microdata? If we put all the event handler attributes in 
their own section, would they be as independent as microdata? Are all the 
<table>/<tr>/<td>/etc elements independent, since they are in their own 
section already? Should that be split out also?

What is the criteria for deciding what is independent?

If you could give an objective criteria that I could apply to determine 
what you think should be in the spec and what you think should not, then I 
would be much more able to understand your position. Currently, from my 
point of view, all I have is a list (an incomplete list, by your own 
admission) of sections that should be split out, which have nothing in 
common as far as I can tell other than you disliking them.


> >> > "focused" means "concentrating interest or activity on something", 
> >> > which we have done successfully for many years on HTML5 (the 
> >> > "something" being improving the state of the Web technology stack 
> >> > for the purposes of writing Web Applications).
> >>
> >> HTML5 is HTML, an XML serialization, and the DOM. We should be 
> >> focused on HTML. This is not the Web Applications group. I wonder if 
> >> perhaps you're not happy being the editor of just HTML. Would you be 
> >> happier working more closely with the Web Apps group, and we could 
> >> work on finding new editors who are happy working on just HTML for 
> >> this group's efforts?
> >
> > My happiness really has nothing to do with this discussion.
> 
> But if you're frustrated about working on "just" HTML that will impact 
> on the specification. So I was less concerned about making you happy, 
> and more concerned that the HTML5 editors are content with the subject 
> matter, and only the subject matter. This ensures that the spec remains 
> focused.

I think HTML5 _is_ focused on "just" HTML. I just have a different vision 
for what HTML is than you do. I think of it as the markup language, APIs, 
and syntax of a media- and device-independent application platform. I 
think we should keep a very tight focus on this, and only this, for HTML5; 
leaving such concerns as media-specific presentations, the network 
protocols, etc, as orthogonal concerns wherever possible. I believe this 
view is pretty much in line with the group's charter, which says:

# There is a single specification deliverable for the HTML Working Group, 
# the HTML specification, a platform-neutral and device-independent design 
# with the following items in scope:
# 
# * A language evolved from HTML4 for describing the semantics of 
#   documents and applications on the World Wide Web. This will be a 
#   complete specification, not a delta specification.
# * An extensible, serialized form of such a language, using XML.
# * A serialized form of such a language using a defined, non-XML syntax 
#   compatible with the 'classic HTML' parsers of existing Web browsers.
# * Document Object Model (DOM) interfaces providing APIs for such a 
#   language.
# * Forms and common UI widgets such as progress bars, datagrids, menus, 
#   and other controls.
# * APIs for the manipulation of linked media.
# * Editing APIs and user-driven WYSIWYG editing features.
 -- http://www.w3.org/2007/03/HTML-WG-charter.html#deliverables

(Note the words "single specification".)

You seem to have a different view.


> >> I'm saying that a good specification, like a good library, can be 
> >> created in such a way as to encourage innovation, rather than 
> >> strangle it.
> >
> > Splitting Microdata into its own specification would strangle 
> > innovation.
> 
> Nope. Disagree. There's nothing about Microdata being a separate 
> specification that would strangle innovation. Nope, must disagree.

Indeed. It's a completely ridiculous statement.


> > (Well, if you're allowed to make completely non-sequitur 
> > soundbite-like arguments without evidence to back up your position, I 
> > figure I am too.)
> 
> I'm responding to your comments you've addressed to me. I'm involved in 
> a debate. I'm not sure why you've decided to respond with an ad hominen 
> response (non-sequitur sound-bite like arguments).

You're arguing (quoted above) that keeping microdata in HTML5 is akin to a 
practice that discourages ("strangles") innovation. Calling this out for 
what it is -- a non-sequitur, sound-bite like argument without evidence -- 
is not an ad hominem attack. (An ad hominem attack would be insult you in 
some way.)

Saying that having microdata in HTML5 strangles innovation is not a 
response to a comment I've made, and it's certainly not a debate, it's an 
attempt to derail the conversation.


> >> >> >> Just the same as applications are cleaner, and better when 
> >> >> >> they're based on modularization.
> >> >> >
> >> >> > I do not think this statement is a truism.
> >> >
> >> > If you meant that they should be focused on small topics, rather 
> >> > than large topics, then my argument above still holds. 
> >> > Specifications focused on small topics taken as part of a group of 
> >> > specifications that cover a larger topic have historically in the 
> >> > W3C been significantly less successful than "monolithic" 
> >> > specifications focused on the larger topic as a whole. CSS3 vs 
> >> > CSS2, and the XHTML Modularisation specifications vs XHTML1.0, are 
> >> > good examples of this. I'm not aware of any examples where the 
> >> > opposite is true (where a specification focused on a small topic 
> >> > that is part of a group of specifications that cover a larger topic 
> >> > has been more successful than its monolithic counterpart).
> >>
> >> Wow, I think you're extrapolating a lot. For one, I don't think CSS3 
> >> is a failure. Seems to me, there's a lot of CSS3 in many of the new 
> >> browsers. As for XHTML 2.0, I don't believe the topic size was the 
> >> primarily problem with that effort.
> >
> > I didn't say CSS3 was a failure, I said CSS3 was less successful than 
> > CSS2. If you do not think this is the case, maybe you haven't been 
> > involved with the CSS working group enough.
> 
> I imagine they've had starts and stops, and acrimonious debate. I have 
> followed along with other W3C email lists, I understand what can happen.
> 
> But I'm seeing some great stuff come out of the CSS3 efforts, so to me, 
> CSS3 is a success.

Once again, I didn't say CSS3 was not a success. I said CSS3 was less 
successful than CSS2. That this is the case is not controversial within 
the CSS community -- CSS2 had a straight-forward scope, executed 
effectively within that scope, and was subsequently revised to take into 
account implementation experience. The post-modularisation CSS work, 
meanwhile, has balooned in scope, has made significantly slower progress, 
and has had several modules reverted basically to First Draft status even 
after having reached CR. Yes, interesting progress has been made with CSS3 
(I've even been editor of some of the drafts that form that progress), but 
compared to CSS2, it was not as successful.



> > I didn't mention XHTML 2.0 at all. I talked about XHTML 
> > Modularisation, which was a 1.x-series set of specifications. That you 
> > haven't apparently heard of it, or that you confused it with XHTML2, 
> > may in fact demonstrate my point perfectly.
> 
> Sorry, my misreading. When I see references to XHTML and lack of 
> success, I tend to 'see' XHTML 2.0. That is the only "failed" XHTML that 
> I know of.
> 
> Yes, I have heard of XHTML Modularization. I believe XHTML 
> Modularization 1.1 is a recommendation, is it not? That's farther than 
> we've managed in this group, so, no, I don't see the effort as a 
> failure.

If your only measure of success is the status of the document, then I 
would argue your priorities are drastically misaligned. You may instead 
wish to consider XHTML Modularisation's adoption within its target 
audience, the level to which it addressed outstanding issues (such as the 
syntax of usemap=""), and its mindshare penetration amongst the larger Web 
developer community.


> >> >> To me, the fact that HTML was separate from the DOM was separate 
> >> >> from the CSS and SVG and so on, meant that these specifications 
> >> >> could progress at their own rate, but there is a good degree of 
> >> >> integration between the specs.
> >> >
> >> > The fact that SVG and CSS were separate from each other led to a 
> >> > long set of problems that we are _still_ dealing with. Similarly, 
> >> > separating HTML and the DOM and CSS and the DOM led to such a 
> >> > complicated set of issues that we are still now, more than a decade 
> >> > later, trying to fix the mess. Separating SVG and HTML led to the 
> >> > pain felt in this very working group earlier this year and last 
> >> > year in trying to reintegrate them, and will lead to decades of 
> >> > ripple effects as the resulting integration affects every HTML 
> >> > parser from here on out, and every Web author that tries to use SVG 
> >> > and HTML in the same page.
> >>
> >> There will always be decisions that were made that shouldn't have 
> >> been made, and bumps and hiccups along the way. We learn, and we work 
> >> to do better.
> >
> > Apparently we _don't_ learn. You are, after all, arguing in favour of 
> > the kinds of mistaken decisions that led to the exact situation I 
> > described. If we were learning, we would avoid making those mistakes 
> > again.
> 
> No, I'm saying that bumps and hiccups, and problems happen when you're 
> creating specifications. It is a natural process. I don't think we need 
> to eliminate the process, we learn from the specifics of past mistakes.

The past mistakes have included trying to split a language into multiple 
specifications. Yes, bumps and hiccups happen when writing specifications. 
They happen _more_ when writing more specifications with a narrower scope 
than when writing larger specifications with a wider scope.


> So, you think then that the only [way] to remove errors is monolithic 
> documents, created by one author?

No, not at all. There are many ways to reduce the number of errors in a 
specification, hopefully all of which we are using in HTML5's development: 
using objective research instead of opinions, being drastically open and 
transparent in the process, actively seeking out reviewers and comments 
outside of the working group, ensuring that the specification matches 
implementations even when this results in a less attractive specification, 
listening to the needs of implementors, and so on.

One of these many ways is to make sure the scope of the specification is 
about as wide as the typical delineation of modules in the relevant 
software products. For example, most browsers would split their code into 
a "Content" section, a "Layout" section, and a "Network" section, so this 
argues for one spec for HTML and MathML, one for CSS and XBL, and one for 
URIs and HTTP. In practice one is typically forced to go one level further 
in the spec subdivision, leading to those six subjects getting a 
specification each. Going further (the way that CSS, URIs, and HTTP are, 
or are being, subdivided) leads to more errors.


> >> >> I don't see broad implementation of HTML5 in user agents or the 
> >> >> community.
> >> >
> >> > Then, with all due respect, you're not looking.
> >> >
> >> >   http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers
> >> >   http://a.deveria.com/caniuse/#agents=All&eras=All&cats=HTML5&statuses=rec,cr,wd,ietf
> >> >   http://html5gallery.com/
> >>
> >> I repeat, I do not see broad implementations of HTML in user agents, 
> >> or in the community.
> >
> > I repeat, with all due respect, that can only mean that you aren't 
> > looking. I provided links above demonstrating my point. If you would 
> > like to disagree, I would request that you at least quantify your 
> > argument or provide some sort of backing for it. I'm sure hat simply 
> > asserting positions that point-blank contradict provided evidence is 
> > not what the chairs had in mind when they suggested the use of 
> > rationales to support our arguments.
> 
> I don't see many aspects of HTML5 in all user agents. There are the new 
> controls, such as details, and Microdata, and its API that it has 
> created, and changes in the Canvas element, and some of cross document 
> messaging, and a host of HTML5 components that don't have broad 
> implementation.

Until you got to "that don't have broad implementation" I actually thought 
you were listing the only things that had wide implementations, and I was 
about to comment saying that if you thought that list was short, I would 
have to disagree!

The new form controls (though currently not <details>, since we're still 
debating how it should be designed) are implemented to some extent or 
another in Opera, WebKit, and Chrome. Microdata and its API are very new 
(a mere two months or so since the spec stablised) but I'm aware of three 
independent experimental efforts to implement it, not counting the demos 
by Philip` and James. The canvas element is the most widely implemented 
new feature bar one, and that one is the cross-document messaging feature, 
which is even implemented in IE8.

Sure, it's not perfectly implemented everywhere -- and indeed, I have been 
on the record as predicting that we won't have two complete and bug-free 
implementatons for another twelve years. But then, HTML4 and CSS2 don't 
have two complete and bug-free implementations either, but I'm sure you'd 
agree that _they_ are broadly implemented.

Given that we're not even at LC, I think HTML5 has had far more 
implementation than we could ever hope for at this stage.


> There are fragments of adoption across some user agents, like browsers, 
> but little in HTML editors, and practically none in other HTML user 
> agents, such as web bots, or content management systems such as 
> Wordpress or Drupal. I don't believe that Google has changed its web bot 
> activity based on HTML5, though it may have. I don't think Bing has.

I can't speak for Bing, and I will not give specifics regarding Google's 
indexing efforts, but I would caution against making such assumptions.


> None of the screen readers have adopted the new elements, as far as I 
> know.

The screen readers still haven't implemented many of the features of 
HTML4, so I am in no way surprised of this.


> More importantly, there are only scattered sparse web pages using HTML5 
> for their web page layout.

http://google.com/ is hardly "scattered", though I guess it is "sparse".

I wouldn't expect to find _any_ pages using HTML5 for their layout, since 
HTML5 is not a layout language.

There are many high-profile uses of HTML5 features. Google Wave is famous 
for using HTML5 heavily; GMail's mobile front end similarly makes use of 
features such as the manifest="" attribute (the application cache 
feature). High-profile use of <canvas> include Yahoo! Pipes, but its use 
also extends to other less well-known pages like Dreamhost's status pages. 
Apple uses <video> now on their site; YouTube has a demo <video> page.

The site http://html5gallery.com/ that I listed earlier list well over a 
hundred sites that make very heavy use of HTML5, including sites that 
really have nothing to do with Web standards at all, like The American 
Sport Art Museum and Archives website (http://asama.org/) or OK COOL, a 
German fashion blog (http://www.okcool.de/).

The list goes on and on, and the only thing stopping significantly greater 
usage is the still-high installed base of IE6 and IE7 and the level of 
support from browser vendors (we are, after all, not yet at the "call for 
implementations" stage, despite all this).


> So no, there hasn't been "broad" adoption of HTML5. There shouldn't
> have been, it's only a draft. And a heavily volatile one at that.

Shouldn't, maybe. Hasn't, however, is wishful thinking.


Going back to your original statement:

| When you open the door to everything under the sun, the spec will never 
| be finished. More than that, it will always have problems getting 
| accepted by the wider community
 -- http://lists.w3.org/Archives/Public/public-html/2009Dec/0135.html

...I think I've clearly demonstrated that HTML5's progress is not harmed 
by its current scope, and that its scope is not causing any trouble with 
HTML5 getting accepted (indeed, adopted!) by the wider community, both in 
terms of implementors (of many conformance classes, not just Web browsers) 
and in terms of authors.

Therefore, I argue, that line of reasoning is not a valid rationale for 
splitting the microdata chapter into its own spec.


> >> I think we need to stop trying to control everything.
> >
> > That has absolutely nothing to do with the subject at hand. We're 
> > talking about whether or not a particular feature of HTML5 should be 
> > in the same document as the rest of HTML5. That doesn't affect control 
> > in any way.
> 
> Actually this really is a question of control. If pieces are split off 
> from the HTML5 document, they could end up in their own working groups, 
> and with their own editors. That means this group, and you, would have 
> little control over the spec, if this were to happen.

We've had things split off into other working groups (indeed, other 
standards organisations) where I've remained editor, and things where I 
haven't. Personally, I really don't care either way, so long as the specs 
address the use cases, and are written based on research and logic rather 
than on people's opinions.

If the group thinks it should control microdata, however, and there is a 
risk that moving microdata out of HTML5 would mean the group loses control 
over microdata, then that is a relevant concern. I'll suggest to Tab that 
this be added to his change proposal.


> >> >> The size in pages has little to do with anything. Well, other than 
> >> >> some of the HTML5 related publications cause browsers to fail.
> >> >
> >> > I disagree with the premise that there are parts of HTML5 remaining 
> >> > that have nothing to do with HTML, its serialisations, and its DOM 
> >> > APIs. Certainly, the microdata section is an integral part of the 
> >> > HTML language and its APIs, and so the argument above at a minimum 
> >> > doesn't apply to this thread, even if it turns out there are parts 
> >> > to which it does apply.
> >>
> >> We have to disagree then. Material specific to only a subset of user 
> >> agents does not belong in the HTML 5 specification. And there are 
> >> other aspects, as I've written up in bugs.
> >
> > Is there _any_ content in HTML5 that is _not_ specific to only a 
> > subset of user agents? If that is your criteria for keeping something 
> > in the spec, what would you suggest we should _keep_?
> 
> HTML is specific to HTML, so HTML elements and attributes, and rules 
> regarding the syntax belong in the spec

I'm glad you agree. Microdata consists of HTML attributes (and formerly an 
HTML element, but that has since been removed).


> but the Browser Object Model has little or nothing to do with HTML, per 
> se, and everything to do with a specific set of user agents -- browsers.

What is the Browser Object Model?


> >> Speaking of which, how are you doing with handing all of the bugs? Do 
> >> we need to consider adding another editor to help you with all the 
> >> bugs?
> >
> > I have been working on other things these past few weeks (including a 
> > vacation), and will likely not return to dealing with bugs until 
> > January. Right now we have fewer than 200 bugs; the most we've ever 
> > had was 210, and that took less than a month to deal with. Since we 
> > currently have 32 issues to deal with, and those take in the region of 
> > a month each to deal with, it is my understanding that I am not the 
> > bottleneck at the moment. However, I am in regular contact with the 
> > chairs and will ensure that bugs are dealt with at a suitable pace.
> 
> Some of those bugs are major. Very major. And marking bugs as WONTFIX 
> will most likely trigger issues from this point. More importantly, you, 
> as the sole author of HTML5 at this time, are also a key component in 
> most of the issues, too.

Since you insist, I shall make dealing with HTML working group feedback a 
higher priority than I have since TPAC.


> I would say, from what you just said, that it's time for this group to 
> bring in more editors.

If anyone would like to edit anything, I'm more than happy to help getting 
people up to speed. There are literally dozens of critical specs in the 
Web standards space that desperately need more editors. So yes, please, if 
you can bring in more editors, do so.


> You're obviously overwhelmed with work.

I work on the number of specs that is necessary to make good progress on 
all of the specs that I work on. This is why, for instance, I stay on 
schedule -- back in 2006 (before the W3C started work on HTML5), I 
predicted that we would reach zero open issues in the WHATWG in October 
2009, and that is exactly what happened. Meanwhile, the W3C HTML WG was 
formed with the charter stating that Last Call (zero issues) would be 
reached in June 2008 -- at which point the HTMLWG's issue tracker was 
still more than a year from reaching its peak of open issues. So the 
numbers don't suggest that I'm overwhelmed with work, they suggest the 
HTML WG is overwhelmed with work.

As I have already mentioned, we barely have fewer than 200 bugs in our bug 
database, a number that I can easily deal with in less than a month if 
necessary. I just checked with one of the chairs, and I am indeed not a 
bottleneck. Your concern for my welfare is touching, but unnecessary.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'