Re: [PageVisibility] Feedback

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? If so, users are completely unaffected by 
this. They won't even know the API exists.

If you mean authors, they will also be 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.

If you mean implementors, then having a REC doesn't help, in fact it's 
actively harmful. Implementors need to have the latest fixes; having a
known-buggy version of the spec is merely confusing. We see this all the 
time, with implementors citing obsolete TR/ documents like DOM Level 3 
Core or versions of HTML5. If we want to bring stability to the Web 
platform, we must have all the implementors implementing the same thing, 
not implementing old, known-obsolete, buggy specs.


> They're going to keep wondering what's stable and what's unstable.

If by "stable" you mean "the least buggy set of implementation 
requirements" (what implementors want) then by definition the RECs on the 
TR/ page are unstable: they are always going to be behind the latest specs 
which have had bug fixes applied. DOM Level 3 Core is a classic example of 
this. Anne and Ms2ger have fixed dozens of bugs in DOM Core's spec in 
their document which are not reflected in DOM Level 3 Core.

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.

The right adjective to describe a REC isn't "stable", it's "atrophied".


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


> > 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. 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. Referencing a dead specification that is no longer maintained is 
actively harmful and is certainly _far_ less helpful than referencing the 
most up to date documentation which is continuously being improved.


> > > HTML5 can afford to link to it since they don't plan to stabilize 
> > > anytime soon, but that's not our case.
> > 
> > HTML is probably more stable than Page Visibility.
> 
> 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. It is 
frankly irresponsible to drop specs in this way. It's what the W3C did 
with HTML and with the DOM, and it has taken us years to fix the mess that 
this caused.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 26 July 2011 19:06:50 UTC