Re: Renamed topic: focus and length of HTML5

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, and the process related to it? 
Pointer please. (Yes, I'm aware of the mailing list, but I don't 
consider that a proper issue tracking process)

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

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

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

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

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

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

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

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

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

 > ...

Best regards, Julian

Received on Sunday, 6 December 2009 10:01:07 UTC