- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 06 Dec 2009 11:00:27 +0100
- To: Ian Hickson <ian@hixie.ch>
- CC: Shelley Powers <shelley.just@gmail.com>, public-html <public-html@w3.org>
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