Re: [PageVisibility] Feedback

On Wed, 2011-08-03 at 22:53 +0000, Ian Hickson wrote:
> 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.

Not everyone can afford to figure out what the new browsers are doing
every 6 weeks. Authors are busy and won't read a document every single
day. A document that can change its minds about it's doing isn't helpful
for them either since a large portion of users don't upgrade their
browsers on a regular basis (or simply cannot upgrade their browsers at
all, especially on the mobile platform). If it's not stable, I'd argue
that it should be put in the final spec but pushed into a .next for
example.

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

Except that DOMCore doesn't match reality either. It's trying to define
the future DOM Core API. It's useful to move forward but won't help the
present reality. Imho, for DOM Core, it would be better to work on two
parallel documents:
- one that tries to match current reality and get published as a REC by
the beginning of 2012
- one that contains the first document + all additions Anne and ms2ger
are adding. Consider publishing the stable features of that draft into a
REC on a regular basis.

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

Because the Working Group wants to push the document to REC sooner
rather than later. (Note that I'm only speaking for myself here and not
on behalf of the Group. At the end, I won't be the one deciding which
reference to put in it.)

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

There are plenty of things one can rely on in HTML4. For example,
compare the following two sections:
 http://www.w3.org/TR/html4/struct/global.html#edef-H1
and
 http://www.w3.org/TR/html5/sections.html#the-h1-h2-h3-h4-h5-and-h6-elements

At best, the HTML5 specification is adding on top of HTML4, but that
doesn't make the definition of "HTML4 H1" unstable or inaccurate.

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

It's interesting for them from the point of staying on top of the
technology but they still need the bedrock, and the more we can put into
the bedrock, the better.
 
> > 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.

No, DOM Level 3 Core didn't fail to do this. Instead, the DOM Working
Group failed to maintain the specification.

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

(Going on a tangent a bit) I'm curious to know why DOMCore is not
intended to document the current interoperable bits. I might be missing
some background on DOMCore here. Do you mean that DOMCore is not a
complete set of interoperable features or do you mean something else?

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

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

Fine for a superficial approach, but it's doing a poor job at
representing the features of HTML5. Take the video page for example:
 http://caniuse.com/video
It doesn't say which API function is implemented or not. It doesn't say
if I can use the track element. It tells me that video is supported in
firefox 3.5 and firefox 4.0 but fails to point out the differences
between the two implementations (the video API was changed between the
two).

> 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. Put the
stable features in the REC, and keep working on improvements or new
ideas as well. I remember starting the work on DOM Level 3 when DOM
Level 2 became a Candidate Recommendation. We shipped CSS 2.1 two months
after painfully obtaining two implementations of all the features of
that spec (and dropping one or two on the way). But the CSS Working
Group has been working for years on CSS3.

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

No, this is stability. Until we get reasonable implementations of the
track element, its definition can change widely. That's not the case for
H1.

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

I think this view was abandonned by W3C around 2000, when we started to
ask for test suites along the specifications and demonstrate
interoperable implementations in order to move to Recommendations. There
was no point in recommending features without some confidence that they
could be implemented.

> 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. (again, keep in
mind that this is only my opinion, not the one from the Group at this
point). I'm happy to point to the ongoing work on DOMCore as well. I'm
sure the Group will be more than happy to revise the specification on an
ongoing basis.

> Well it's certainly nice to hear the W3C has changed its mind on this 
> matter.

As I always say, nothing is set in stone. :)

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

I'd like W3C to publish a new Recommendation for DOMCore sooner rather
later, so that we don't have to point to DOM Level 3 Core. I've seen too
many groups making the mistake of setting the bar for their Rec too high
so that it takes years to ship it. Not everything has to be solved when
publishing a Recommendation, you can still work on solving things in a
new version.

Philippe

Received on Friday, 5 August 2011 18:02:11 UTC