- From: Philippe Le Hegaret <plh@w3.org>
- Date: Thu, 11 Aug 2011 09:12:49 -0400
- To: Ian Hickson <ian@hixie.ch>
- Cc: Anne van Kesteren <annevk@opera.com>, public-web-perf <public-web-perf@w3.org>
On Wed, 2011-08-10 at 21:54 +0000, Ian Hickson wrote: > > If it's not stable, I'd argue that it should be put in the final spec > > but pushed into a .next for example. > > I don't understand what you mean by "stable" in this context. > > If you are proposing that for each specification we have two parallel > tracks, one describing what we want browsers to converge on and one > containing all the bits that browsers have already converged on, then I > think that would be fine. But specifications would still reference the > "what we want browsers to converge on" spec, not the "what they have > converged on" spec. I would rather reference "what they have converged on". > If you are (or anyone else is) interested in helping maintain such a > document, by the way, let me know. I think it could be quite helpful, and > it is not something we (the standards community) have done so far. That's not correct. The DOM Working Group was working in that mode more than 10 years. The CSS Working Group work in that mode nowadays as well. They're about to publish a recommendation for CSS3 Selectors and a first public working draft for css 4 selectors. > > > Then why does it matter _what_ is referenced? > > > > Because the Working Group wants to push the document to REC sooner > > rather than later. > > It's the W3C's job to be doing the best it can for the Web. If its > policies are counter this effect, then it's the W3C's responsibility to > fix the problem. It's certainly not your job to get in the way! It's my job to make sure we recommend technologies sooner rather later. That's exactly what we're trying to do in the Web Performance Working Group. > > > It also makes no sense for a specification to reference a document > > > that describes what _is_ implemented. Specifications should reference > > > the documentation of what they rely on to be implemented, what > > > _should_ be implemented. That's DOM Core, not DOM Level 3 Core. > > > > I would argue that it makes sense for a specification to reference > > stable specifications that document features they're relying on. Page > > Visibility only relies on a "Document" interface and this name hasn't > > changed since DOM Level 1. I'm more than happy to point out, along the > > DOM Level 3 reference, that there is ongoing work on DOMCore. > > Why reference any DOM Core specification at all, if all that it needs is a > Document interface name? Better to just say that the specification can be > used with any specification that defines a Document object, no? That's a possibility indeed and I have nothing against such approach if any of the editors want to step in and do the change. > > > However, that's not what we do in the spec world currently. It would > > > be great if the W3C would do that -- lots of people publicly ask us to > > > write such documentation -- but it's not what we're doing. > > > > Well, that's what we're trying to do with the Recommendation. > > Recommendations do not even come close to doing this currently, and the > process seems all but set up to prevent it. > > If that really was the goal, we'd be publishing specs as RECs every few > months. I've been suggesting that few the past year without anyone at the > W3C being in the slightest bit interested in doing it. I have suggested several times to Working Groups that they should publish recommendations more often. I'd more than happy if the Web Performance Working Group would publish new sets of Recommendations every year (few months is too aggressive imho). That's why I'm trying to push documents like Page Visibility forward. I wish we had a Recommendation for Navigation Timing already but it is stuck due to dependency issues, like HTML5 or Web IDL. > > > To this extent, however, DOM Level 3 Core and the contemporary DOM > > > Core specification have little difference. If anything, DOM Core is > > > closer to what is implemented. So again, asking to reference DOM Level > > > 3 Core doesn't make any sense given the arguments you are putting > > > forward. > > > > My only argument to reference DOM Level 3 Core is to get Page Visibility > > shipped as a Recommendation sooner rather than later. > > I thought your argument had something to do with stability? > > If your argument is just that the W3C process arbitrarily requires a > particular obsolete reference, then fix the process, don't force the spec > to reference obsolete material. I'd rather spend my limited time for the Web Performance Working Group on other things than arguing about the Process but if the Chairs of the Group believe otherwise, they should let me know. If my argument is an issue for you, I suggest that you bring your Process concerns to the Advisory Board (process-issues@w3.org and copy www-archive@w3.org). They're the one in charge of the Process. In the meantime, I suggested the following change to Page Visibility: [[ [DOM Level 3 Core] Document Object Model Level 3 Core Specification, A. Le Hors, et al., Editors. World Wide Web Consortium, 7 April 2004. This version of the Document Object Model Level 3 Core Recommendation is http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407. The latest version of DOM Core is available at http://www.w3.org/TR/domcore/. ]] If you're not satisfy (or anyone else) with this change, please say so. As I said earlier, dropping the entire reference in favor of mentioning Document objects in general is also fine by me but I'd rather have the editors of the document agreeing with that. Philippe
Received on Thursday, 11 August 2011 13:13:05 UTC