W3C home > Mailing lists > Public > public-web-perf@w3.org > August 2011

Re: [PageVisibility] Feedback

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>
Message-ID: <1313068369.2470.96.camel@chacal>
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

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

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.

Received on Thursday, 11 August 2011 13:13:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:09 UTC