Re: [PageVisibility] Feedback

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

None of the documents we're talking about track what the browsers are 
doing every six weeks either, so that's a non-sequitur.

Note that Web authors these days _can_ afford to figure out what the new 
browsers are doing every six weeks. They don't have a choice, since that's 
how often new browsers are released.


> Authors are busy and won't read a document every single day.

Nobody is saying that they should, are they?


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

That's a non-sequitur as well. Nobody is proposing a document that 
arbitrarily changes its mind.


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

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.


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

Both would need continuous maintenance.

I agree that that would be fine. DOM Level 3 Core is neither of these. Of 
the drafts that actually exist, DOM Core is a far better reference since 
it more closely matches reality.


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

The reference need not have any bearing on what is published. There's no 
physical law preventing a document from being published with DOM Core as 
the referenced document, nor is there any legislative requirement thereto. 
It's entirely a W3C-invented constraint. It can be changed trivially.

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!


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

Section 7.5.5 in HTML4 is completely useless. It doesn't contain a single 
realistic normative conformance criteria, and contains no useful 
definitions. In fact the only conformance criteria it seems to contain are 
related to parsing, one of the most chimerical aspects of HTML4.


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

I don't really see how this impacts the discussion of what reference to 
use. It's not like DOM Core or the contemporary HTML spec don't have the 
bedrock you speak of.


> > > 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 result is the same.


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

DOM Core does what all our specifications do: it tries to define where 
browsers should be converging.

Take a hypothetical API that returns two numbers. If browsers A, B, and C 
all return 1 for the first number, but A returns 2 for the second number 
while B and C return 3, then a document that describes what is 
interoperable would describe the API as returning two numbers, and would 
say the first number is 1. A specification describing what convergence we 
are aiming for would require that the API return two numbers, and that 
they be 1 and 3 respectively.

An obsolete specification, like DOM Level 3 Core, would instead insist 
that there are two APIs and they both return one number, or something like 
that. Not useful at all anymore.


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


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

I don't think anyone would object to you documenting it in more detail if 
you wanted to. But we don't have such a document currently. Certainly 
referencing obsolete old RECs isn't going to help with this.



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


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

If by "stability" you mean "interoperably implemented", then RECs do not 
currently represent stability. For example, the "media" attribute on 
<link> in HTML is implemented as described by the contemporary HTML 
standard, not according to the HTML4 standard.


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

This would be more convincing if the W3C didn't keep publishing RECs 
without going through the process. (SVG being a classic example.)


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

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

Received on Wednesday, 10 August 2011 21:54:58 UTC