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

Re: [PageVisibility] Feedback

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 3 Aug 2011 22:53:58 +0000 (UTC)
To: Philippe Le Hegaret <plh@w3.org>
Cc: Anne van Kesteren <annevk@opera.com>, public-web-perf@w3.org
Message-ID: <Pine.LNX.4.64.1108032238390.14637@ps20323.dreamhostps.com>
On Wed, 3 Aug 2011, Philippe Le Hegaret wrote:
> On Tue, 2011-07-26 at 19:06 +0000, Ian Hickson wrote:
> > On Tue, 26 Jul 2011, Philippe Le Hegaret wrote:
> > > 
> > > And how is it going to help users if we do that?
> > 
> > Do you actually mean users?
> 
> I mean people trying to rely on the technology.

Then you presumably mean authors. Authors are unaffected: they use what's 
implemented, not what's specced. What authors need is an up to date guide 
to what is implemented. This changes as new browsers ship, and doesn't 
track the W3C's REC cycle at all. They need a document that is 
continuously updated as browsers are fixed or as browsers change their 
minds about what is implemented.

Referencing an obsolete specification that doesn't match reality harms 
people trying to rely on the technology.


> > If by "stable" you mean "what is implemented" (what authors want) then 
> > again the TR/ page is unhelpful. Browsers don't implement DOM Level 3 
> > Core, they implement the DOM Core spec -- specifically because Anne 
> > and Ms2ger are making the spec match reality, and nobody is fixing DOM 
> > Level 3 Core anymore.
> 
> And that's certainly a good thing that Anne and ms2ger are doing so. No 
> doubt about it. DOM Level 3 Core has been very helpful but is too old 
> indeed. From the point of PageVisibility, it doesn't matter what the 
> Document interface contains. We don't rely on any of the functionalities 
> of the Document interface besides the fact that it exists.

Then why does it matter _what_ is referenced?

You can't simultaneously argue that the reference is irrelevant and that 
the reference must be a particular reference because anything else would 
"be unstable" or some such. That's an incoherent position.


> > > A technical standard is an established set of requirements about a 
> > > technical system. Unless we stabilize the specification and ship it, 
> > > nothing gets established.
> > 
> > This is true for things like screw threads. It is simply an archaic 
> > mindset for technology that evolves as fast as Web tech. Look at HTML: 
> > it is quite well established, yet it is continuously improving. Same 
> > with DOM Core, and indeed numerous other specifications.
> 
> Correct, but there is a set of stable functionalities in HTML, things 
> that one can rely on.

Those are things described in the contemporary HTML specification, by the 
way, not the 13-year-old HTML4 document.


> That's the part which is the most interesting from the point of users

What do you mean by "users"?

If you actually mean end-users, then no, it's not. End-users aren't going 
to read the spec at all, none of it is interesting to them.

If you mean the people relying on on the technology, i.e. the authors, 
then again no, it's not. The most interesting thing for Web authors these 
days is the new stuff that lets them create fancy effects. Just look at 
your typical Web author discussion forum. They're all asking how to use 
<canvas>, how to use WebSockets, how to use <section>. The stuff that is 
broadly implemented is not interesting, it's boring. It's the bedrock of 
what they do.

The things one can rely on also happen to be what is specified in the 
contemporary DOM Core specification and by and large _not_ what is 
specified in the DOM Level 3 Core specification. So again, if that is your 
definition then you are asking for the wrong reference.

 
> and they need to know which are those parts. By documenting and 
> maintaining those parts, we help them.

We do. DOM Level 3 Core utterly fails to do this. The contemporary DOM 
Core specification does a better job, though still not a particularly 
great one, since that's not its goal. Neither specification was intended 
to document specifically the extend of what is interoperably implemented.

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.


> > > > You should be trying to make the Web better. It doesn't make the 
> > > > Web better to be referencing obsolete specifications.
> > > 
> > > I'm trying to make the Web a better for users. Referencing a 
> > > specification that keeps changing doesn't help them either.
> > 
> > It doesn't "keep changing". It keeps improving.
> 
> But there is no way to know which parts are improvements or new ideas.

Sure there is -- lots of sites document that. For example 
http://caniuse.com/ does a good job of doing so.

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.

And again, DOM Level 3 Core is a _less_ accurate guide to that than DOM 
Core is.


> You can't rely the same on the h1 element and the track element for 
> example. Those two elements have different levels of stability.

That's not stability. That's just how well implemented thing are.


> > It's not like the specs get changed arbitrarily from day to day. Every 
> > change is specifically made to address issues, to fix problems, to 
> > bring the document closer to reality.
> 
> No, the document contains also new ideas that have no reality grounding. 
> While this is acceptable for a work in progress, this should not go into 
> a standard.

This is a rather esoteric view as to what a standard is, and certainly 
not one that I share. Standards describe what should be implemented so as 
to obtain convergence on a single interoperable feature set.

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.


> > > If that's case, then you shouldn't worry about this, since we'll 
> > > have plenty of time to change the references, but our goal is to 
> > > finish the first version of Page Visibility by January 2012, that's 
> > > before the current established timeline of HTML5.
> > 
> > Specifications are never finished, unless they are abandoned.
> 
> Technologies keep improving but specifications get to be maintained.

Well it's certainly nice to hear the W3C has changed its mind on this 
matter. It also makes it even clearer that we should reference the new 
specifications and not the old, no-longer-maintained, inaccurate ones 
like DOM Level 3 Core.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 3 August 2011 22:54:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:31 UTC