Re: Renamed topic: focus and length of HTML5

Ian Hickson wrote:
>>>> 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/

You chose to truncate my email at the point where I said:

"(Yes, I'm aware of the mailing list, but I don't consider that a proper 
issue tracking process)"

So no, I don't consider a view on unprocessed email messages a proper 
tracker.

>> and the process related to it? 
> 
> http://www.whatwg.org/charter

I also don't see much of a process here; except that it gives the WHATWG 
members some influence, but as membership of the WHATWG is "invite 
only", I'm not impressed.

> 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?

It would depend on the issue. I would hope that if it's about an 
outright bug, then the W3C issue tracker should contain it as well. If 
it's about design philosophy or scope, I would expect the W3C not to 
consider it.

>> 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.

That has already been reported as a problem of XHR that should be fixed.

> 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.

Well, we continue to disagree on this.

> ...
>>> 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.

Your experience is different from my experience then. I've been involved 
in several IETF specification efforts that used or use modularity with 
quite some success. So it's definitively possible.

> 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.

Actually, I'd like to split out Microdata so that it can process more 
*slowly*.

 > ...
>> 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.
> ...

I don't think the WG agrees that this is the right approach.

> ...
>>>> <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.

The fact that the situation was similar doesn't prove that the outcome 
is going to be similar as well.

> ...
>> 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.
> ...

So, out of curiosity, did you ask the Chrome team not to support these 
yet? Or are you disagreeing with the W3C process? Please elaborate.

>>>> 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?

If the WG fails to come to consensus about that particular feature, and 
it's truly optional (as microdata, or canvas, or @ping), then yes, it 
should either be moved into a separate spec (for later consideration), 
or dropped.

> ...
>> 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.
> ... 

Noted, and thanks for the clarification.

> ...
>>>> 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?
> ...

I would be opposed to it, but it would be the reverse argument then.

> ...

Best regards, Julian

Received on Monday, 7 December 2009 16:13:01 UTC