W3C vs WHATWG specs WAS: [blink-dev] Fullscreen & Pointer Lock (status)

[Ojan Vafai]

Changing the subject so that the original thread can stay focused on the fullscreen/pointerlock questions.

Elliott's statement isn't as definitive as the situation is in practice. In all the cases I know of where we're implementing a spec, if there's a WHATWG spec and the W3C has a fork, we look exclusively at the WHATWG version of the spec. As far as I know, there is consensus on this among Blink developers.

The primary reason for this is that the WHATWG specs are kept up to date and unversioned.

The only case that needs linking to both the W3C version and the WHATWG version is when there's something in the W3C version that's not in the WHATWG version. In which case, the history of how that came to be needs to be explained.

As Domenic said on the original thread, maybe we should document this somewhere. I'm not really sure where would be useful.

On Tue, Apr 15, 2014 at 10:30 AM, Glenn Adams <gl...@skynav.com> wrote:

On Tue, Apr 15, 2014 at 10:53 AM, Elliott Sprehn <esp...@chromium.org> wrote:

On Tue, Apr 15, 2014 at 11:51 AM, Glenn Adams <gl...@skynav.com> wrote:

[...]

On 15 April 2014 15:45, Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Apr 15, 2014 at 3:35 PM, Si Robertson <retrom...@gmail.com> wrote:
> Some of the docs are, but at least in this case the W3 docs show how stable
> the API is considering nothing has changed since mid 2012 :-)

Right, and that is false. The W3C copying work of others causes
nothing but such confusion.

There is not a consensus on this point. Those of us who have been involved in the W3C and other SDOs (Standards Development Organizations) for a long time tend to recognize only W3C documents; others who don't have that history tend to prefer the WHATWG.

There is no correct answer. Only opinions.

 

Note that blink does favor living standards as they have many advantages over the versioned spec and last call process.

It is worth noting that the WHATWG documents suffer from problems as well:

• their IPR status is indeterminate
• they do not follow a consensus process
• they do not have a wide spread industry commitment
• they are not recognized by most other SDOs
• being "living" there is no fixed version to test against

IMO, due diligence would suggest consideration be given to both W3C and WHATWG versions of the "same|similar" technical specifications, and a judgment will have to be rendered when there are differences.

For citation purposes, it would be useful to cite both and call out any significant technical differences.

[Glenn Adams]

On Tue, Apr 15, 2014 at 1:24 PM, Ojan Vafai <oj...@chromium.org> wrote:

Changing the subject so that the original thread can stay focused on the fullscreen/pointerlock questions.

Elliott's statement isn't as definitive as the situation is in practice. In all the cases I know of where we're implementing a spec, if there's a WHATWG spec and the W3C has a fork, we look exclusively at the WHATWG version of the spec. As far as I know, there is consensus on this among Blink developers.

Not unanimous consensus.

[Tab Atkins Jr.]

On Tue, Apr 15, 2014 at 12:24 PM, Ojan Vafai <oj...@chromium.org> wrote:
> On Tue, Apr 15, 2014 at 10:30 AM, Glenn Adams <gl...@skynav.com> wrote:
>> It is worth noting that the WHATWG documents suffer from problems as well:
>>

>> * their IPR status is indeterminate

This is indeed still a problem.

>> * they do not follow a consensus process

This is not a problem.

>> * they do not have a wide spread industry commitment

I have no idea what this means. WHATWG specs are followed by most
browsers. IE engineers aren't officially allowed to participate in
the WHATWG standards process, but in practice they follow the WHATWG
spec as well, because that's what the other browsers do, and
gratuitous incompatibility is bad for them.

>> * they are not recognized by most other SDOs

(SDO being "standards development organization".) This is false. In
particular, the most relevent standards bodies for our purposes (W3C
and TC39) recognize the WHATWG.

>> * being "living" there is no fixed version to test against

This is false. All WHATWG specs are produced in version-control
systems, meaning it is possible to link against a particular version
of the spec at any time.

>> IMO, due diligence would suggest consideration be given to both W3C and
>> WHATWG versions of the "same|similar" technical specifications, and a
>> judgment will have to be rendered when there are differences.
>>
>> For citation purposes, it would be useful to cite both and call out any
>> significant technical differences.

Every instance of a WHATWG spec forked by the W3C is much worse. It's
often vastly outdated and contains bugs that were long-fixed in the
WHATWG upstream. No engineer on Blink should ever implement off of
the W3C fork of a WHATWG spec, because the W3C is a bad actor in those
cases, and we've had several instances of bugs being written into our
code by engineers accidentally looking at the (outdated) W3C version,
when the bug had already been fixed in the WHATWG version.

(Nothing wrong with the W3C in general, of course - I'm a long-time
contributor to it.)

~TJ

[Adam Barth]

I think it's also fair to say that if there's a disagreement between a W3C spec and a WHATWG spec, that's something worth understanding.  The most common cause is just that the W3C spec is out-of-date, but sometimes there's an underlying argument between two groups of people, and in those cases it's worth at least understanding the arguments from each side.

Adam

[Rik Cabanier]

On Tue, Apr 15, 2014 at 12:24 PM, Ojan Vafai <oj...@chromium.org> wrote:

Changing the subject so that the original thread can stay focused on the fullscreen/pointerlock questions.

Elliott's statement isn't as definitive as the situation is in practice. In all the cases I know of where we're implementing a spec, if there's a WHATWG spec and the W3C has a fork, we look exclusively at the WHATWG version of the spec. As far as I know, there is consensus on this among Blink developers.

The primary reason for this is that the WHATWG specs are kept up to date and unversioned.

Isn't this a problem?

How can we be sure that the spec hasn't changed by the time a feature actually ships? It is "living" after all so it might change from underneath us.

Since Anne made changes to the fullScreen API, how do we know that the existing implementations still follow what the spec says? Is there supposed to be another conversation with mozilla, webkit and IE to figure this out?

It would be great if there was a snapshot so implementors could refer to that. (Bug fixes would still be allowed) 

I don't really care where this version would be kept or who produces it.

 

The only case that needs linking to both the W3C version and the WHATWG version is when there's something in the W3C version that's not in the WHATWG version. In which case, the history of how that came to be needs to be explained.

As Domenic said on the original thread, maybe we should document this somewhere. I'm not really sure where would be useful.

I'm unsure how you could since the situation is such as mess.

Take the canvas spec for instance, it contains a bunch of APIs that are either obsolete (canvas workers), have no consensus (unbacked hit regions) or are not implementable (the new Path2D constructors).

As an implementor, how would you be able to know this apart from scanning the mailing lists and talking to the right people?

For instance, see this codereview from today: https://codereview.chromium.org/238863002/ 

How was the engineer supposed to know that that API was broken?

 

On Tue, Apr 15, 2014 at 10:30 AM, Glenn Adams <gl...@skynav.com> wrote:

On Tue, Apr 15, 2014 at 10:53 AM, Elliott Sprehn <esp...@chromium.org> wrote:

On Tue, Apr 15, 2014 at 11:51 AM, Glenn Adams <gl...@skynav.com> wrote:

[...]

On 15 April 2014 15:45, Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Apr 15, 2014 at 3:35 PM, Si Robertson <retrom...@gmail.com> wrote:
> Some of the docs are, but at least in this case the W3 docs show how stable
> the API is considering nothing has changed since mid 2012 :-)

Right, and that is false. The W3C copying work of others causes
nothing but such confusion.

There is not a consensus on this point. Those of us who have been involved in the W3C and other SDOs (Standards Development Organizations) for a long time tend to recognize only W3C documents; others who don't have that history tend to prefer the WHATWG.

There is no correct answer. Only opinions.

 

Note that blink does favor living standards as they have many advantages over the versioned spec and last call process.

It is worth noting that the WHATWG documents suffer from problems as well:

• their IPR status is indeterminate
• they do not follow a consensus process
• they do not have a wide spread industry commitment
• they are not recognized by most other SDOs
• being "living" there is no fixed version to test against

IMO, due diligence would suggest consideration be given to both W3C and WHATWG versions of the "same|similar" technical specifications, and a judgment will have to be rendered when there are differences.

For citation purposes, it would be useful to cite both and call out any significant technical differences.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Si Robertson]

I have a question regarding this.

If the W3C and WHATWG ever encounter a situation where neither party can agree on an API specification, and both versions (W3C/WHATWG) of that specification remain inconsistent, which specification should be regarded as "the" standard one for developers to follow?

[Rik Cabanier]

On Tue, Apr 15, 2014 at 1:35 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:

On Tue, Apr 15, 2014 at 12:24 PM, Ojan Vafai <oj...@chromium.org> wrote:
> On Tue, Apr 15, 2014 at 10:30 AM, Glenn Adams <gl...@skynav.com> wrote:

>> It is worth noting that the WHATWG documents suffer from problems as well:
>>

>> * their IPR status is indeterminate

This is indeed still a problem.

>> * they do not follow a consensus process

This is not a problem.

>> * they do not have a wide spread industry commitment

I have no idea what this means.  WHATWG specs are followed by most
browsers.  IE engineers aren't officially allowed to participate in
the WHATWG standards process, but in practice they follow the WHATWG
spec as well, because that's what the other browsers do, and
gratuitous incompatibility is bad for them.

>> * they are not recognized by most other SDOs

(SDO being "standards development organization".)  This is false.  In
particular, the most relevent standards bodies for our purposes (W3C
and TC39) recognize the WHATWG.

>> * being "living" there is no fixed version to test against

This is false.  All WHATWG specs are produced in version-control
systems, meaning it is possible to link against a particular version
of the spec at any time.

What if you need a bug fix against that version? Would the WhatWG system have to create a branch?

Most (if not all) of Anne's code changes seem to fall into that category, but I'm sure that he'll want to change functionality at some point (ie move the events to promises)

It would really be nice if there was such a thing as a dated snapshot that contains the APIs that are slated to be implemented. The little status flags on the left margin are not always up to date.

Maybe this is just a problem with the HTML and Canvas specs...

 

>> IMO, due diligence would suggest consideration be given to both W3C and
>> WHATWG versions of the "same|similar" technical specifications, and a
>> judgment will have to be rendered when there are differences.
>>
>> For citation purposes, it would be useful to cite both and call out any
>> significant technical differences.

Every instance of a WHATWG spec forked by the W3C is much worse. It's
often vastly outdated and contains bugs that were long-fixed in the
WHATWG upstream.  No engineer on Blink should ever implement off of
the W3C fork of a WHATWG spec, because the W3C is a bad actor in those
cases, and we've had several instances of bugs being written into our
code by engineers accidentally looking at the (outdated) W3C version,
when the bug had already been fixed in the WHATWG version.

(Nothing wrong with the W3C in general, of course - I'm a long-time
contributor to it.)

~TJ

[Glenn Adams]

Obviously we disagree on some of these matters. I find it rather ironic that you continue to participate in the W3C while simultaneously claiming that the "W3C is a bad actor".

 

~TJ

[Tab Atkins Jr.]

You are *literally* reading only the parts of that quoted paragraph
that suit you.

> the W3C is a bad actor **in those cases**

> (**Nothing wrong with the W3C in general, of course** - I'm a long-time
> contributor to it.

~TJ

[Tab Atkins Jr.]

On Tue, Apr 15, 2014 at 1:52 PM, Rik Cabanier <caba...@gmail.com> wrote:
> On Tue, Apr 15, 2014 at 1:35 PM, Tab Atkins Jr. <jacka...@gmail.com>
> wrote:
>> >> * being "living" there is no fixed version to test against
>>
>> This is false. All WHATWG specs are produced in version-control
>> systems, meaning it is possible to link against a particular version
>> of the spec at any time.
>
> What if you need a bug fix against that version? Would the WhatWG system
> have to create a branch?
> Most (if not all) of Anne's code changes seem to fall into that category,
> but I'm sure that he'll want to change functionality at some point (ie move
> the events to promises)

If you're bugfixing, you should be looking at head. There's no reason
to ever bugfix a past version; it's useful as a historical curiosity,
and as a source of guaranteed-stable IDs to ref into the document.

> It would really be nice if there was such a thing as a dated snapshot that
> contains the APIs that are slated to be implemented. The little status flags
> on the left margin are not always up to date.
> Maybe this is just a problem with the HTML and Canvas specs...

You can fix that yourself, you know. Those status flags are user-modifiable.

~TJ

[Tab Atkins Jr.]

On Tue, Apr 15, 2014 at 1:51 PM, Si Robertson <retrom...@gmail.com> wrote:
> I have a question regarding this.
>
> If the W3C and WHATWG ever encounter a situation where neither party can
> agree on an API specification, and both versions (W3C/WHATWG) of that
> specification remain inconsistent, which specification should be regarded as
> "the" standard one for developers to follow?

As Ojan said, Blink follows the WHATWG version of specs when they
exist in both places.

~TJ

[Tab Atkins Jr.]

On Tue, Apr 15, 2014 at 1:46 PM, Rik Cabanier <caba...@gmail.com> wrote:
> On Tue, Apr 15, 2014 at 12:24 PM, Ojan Vafai <oj...@chromium.org> wrote:
>> Changing the subject so that the original thread can stay focused on the
>> fullscreen/pointerlock questions.
>>
>> Elliott's statement isn't as definitive as the situation is in practice.
>> In all the cases I know of where we're implementing a spec, if there's a
>> WHATWG spec and the W3C has a fork, we look exclusively at the WHATWG
>> version of the spec. As far as I know, there is consensus on this among
>> Blink developers.
>>
>> The primary reason for this is that the WHATWG specs are kept up to date
>> and unversioned.
>
> Isn't this a problem?

No. ^_^

> How can we be sure that the spec hasn't changed by the time a feature
> actually ships? It is "living" after all so it might change from underneath
> us.

Responsible spec authors only make changes to features when browser
compat allows them to. If a feature has shipped, it's unlikely to be
changed; it's *definitely* not going to change without investigation
of the feasibility of making the change in the shipping browsers,
which entails actually talking to the engineers behind those browsers.
It's never a surprise.

If it ever is a surprise, someone did something wrong. Please name
and shame accordingly, so we can maintain high standards.

> Since Anne made changes to the fullScreen API, how do we know that the
> existing implementations still follow what the spec says? Is there supposed
> to be another conversation with mozilla, webkit and IE to figure this out?

See above.

> It would be great if there was a snapshot so implementors could refer to
> that. (Bug fixes would still be allowed)
> I don't really care where this version would be kept or who produces it.

A snapshot isn't a snapshot if bugfixes are allowed. There's no way
to differentiate "bugfixes" from "feature changes" in general; they're
just points on a spectrum that changes smoothly.

>> The only case that needs linking to both the W3C version and the WHATWG
>> version is when there's something in the W3C version that's not in the
>> WHATWG version. In which case, the history of how that came to be needs to
>> be explained.
>>
>> As Domenic said on the original thread, maybe we should document this
>> somewhere. I'm not really sure where would be useful.
>
>
> I'm unsure how you could since the situation is such as mess.
>
> Take the canvas spec for instance, it contains a bunch of APIs that are
> either obsolete (canvas workers), have no consensus (unbacked hit regions)
> or are not implementable (the new Path2D constructors).
> As an implementor, how would you be able to know this apart from scanning
> the mailing lists and talking to the right people?

Where is the breakage here? Are there things being committed to a
non-WHATWG version of the canvas spec that aren't reflected upstream?

~TJ

[Glenn Adams]

And you said:

No engineer on Blink should ever implement off of
>> the W3C fork of a WHATWG spec, because the W3C is a bad actor in those
>> cases

So what you are saying is that the W3C is a bad actor whenever it forks a WHATWG spec? That's a pretty broad brush. Are you saying that whenever the consensus process of the W3C differs with the personal opinion of a WHATWG editor that the W3C is being a bad actor?!

[Tab Atkins Jr.]

On Tue, Apr 15, 2014 at 2:09 PM, Glenn Adams <gl...@skynav.com> wrote:
> And you said:
>
>> No engineer on Blink should ever implement off of
>> >> the W3C fork of a WHATWG spec, because the W3C is a bad actor in those
>> >> cases
>
> So what you are saying is that the W3C is a bad actor whenever it forks a
> WHATWG spec? That's a pretty broad brush. Are you saying that whenever the
> consensus process of the W3C differs with the personal opinion of a WHATWG
> editor that the W3C is being a bad actor?!

No, I'm saying that whenever the W3C forks a WHATWG spec, they:

* rarely if ever update the fork, so it drifts behind the WHATWG
version by a significant amount (sometimes *years* - there are some
W3C forks of WHATWG specs that were last updated in 2012, *when they
initially forked*)
* sometimes make incompatible edits without attempting to get it into
the WHATWG version of the spec, and rarely if ever indicate this
prominently, so implementors accidentally following the W3C fork
implement incorrect things that are incompatible with what other
browsers are doing
* violate the spirit of their own refusal to allow forks of W3C specs,
a decision which has been repeatedly affirmed by W3C management.

This is why I say the W3C is a "bad actor" when they fork.

~TJ

[Rik Cabanier]

Hey Glenn, 

I'm unsure what you're trying to accomplish here. Let's leave the W3C vs WhatWG turf war out of this.

This thread is about improving where to look for specs. Let's not get distracted.

[Philip Jägenstedt]

On Tue, Apr 15, 2014 at 10:46 PM, Rik Cabanier <caba...@gmail.com> wrote:
>
> How can we be sure that the spec hasn't changed by the time a feature
> actually ships? It is "living" after all so it might change from underneath
> us.

What I've sometimes done when I've thought that something is likely to
get out of sync is to just leave a comment about which revision of the
spec has been followed. For example,
LayoutTests/fast/dom/global-event-handlers.html says "attribute list
from WHATWG HTML Living Standard r8389".

Mostly though, I just keep a close eye on the (parts of) specs that
I'm interested in and follow along in the relevant bugs and mailing
list discussions.

Philip

[Hajime Morrita]

Right. Document-Implementation gap isn't unique problem of Web standard. It's happening everywhere in software development. (Well, a bit exaggerating...)

Pointing specific revision from a comment is one good idea. Another approach is to refer spec bugs, and put such note in commit log. Bug tracker and mailing list threads generally capture more context that helps archaeology. Having it in commit log is less distracting in the code and it makes clear how dated the message is. You can find such commits in blink.

I also agree that participating the discussion is the key to stay up-to-date in both standard and implementation lands. It's ideal but too hard to capture all the intention in limited number of artifacts, that is web standards and the source code.

[Glenn Adams]

Hey Rik,

I didn't bring up W3C vs WHATWG in this thread. I'm simply pointing out:

(1) the WHATWG spec process has a variety of problems, while folks seem to only condemn the W3C process because it becomes "stale";

(2) Tab is going too far in claiming that the W3C is a bad actor;

(3) Some of us think the W3C is authoritative when there is a difference between the specs, others think the WHATWG version is authoritative; this produces ambiguity in the overall community of implementors, authors, and users;

(4) Some devs ask the legitimate question of what spec to follow when there is a technical difference, that being the point the brought up this discussion.

We can't address these problems by pretending they don't exist, which seems to be what some would prefer.

G.

[Tab Atkins Jr.]

On Tue, Apr 15, 2014 at 3:00 PM, Glenn Adams <gl...@skynav.com> wrote:
> I didn't bring up W3C vs WHATWG in this thread. I'm simply pointing out:
>
> (1) the WHATWG spec process has a variety of problems, while folks seem to
> only condemn the W3C process because it becomes "stale";
>
> (2) Tab is going too far in claiming that the W3C is a bad actor;
>
> (3) Some of us think the W3C is authoritative when there is a difference
> between the specs, others think the WHATWG version is authoritative; this
> produces ambiguity in the overall community of implementors, authors, and
> users;
>
> (4) Some devs ask the legitimate question of what spec to follow when there
> is a technical difference, that being the point the brought up this
> discussion.

As Ojan said, Blink project consensus is to follow the WHATWG spec
over the W3C fork when both exist.

Yes, it's not unanimous. It's consensus.

~TJ

[Chris Wilson]

On Tue, Apr 15, 2014 at 2:23 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:

... whenever the W3C forks a WHATWG spec, they:

* rarely if ever update the fork, so it drifts behind the WHATWG
version by a significant amount (sometimes *years* - there are some
W3C forks of WHATWG specs that were last updated in 2012, *when they
initially forked*)

Well, certainly not true in HTML.

 

* sometimes make incompatible edits without attempting to get it into
the WHATWG version of the spec, and rarely if ever indicate this
prominently, so implementors accidentally following the W3C fork
implement incorrect things that are incompatible with what other
browsers are doing

I'm not sure what "attempting to get it into the WHATWG spec" means, precisely, nor why the W3C WGs would find that particularly a goal.  

 

* violate the spirit of their own refusal to allow forks of W3C specs,
a decision which has been repeatedly affirmed by W3C management.

Making a conscious choice to be a one-way street is not the same as violating the spirit of their refusal.  The WHATWG says it's fine to fork their specs; the W3C avails themself of that privilege.  The W3C does NOT say it's fine to fork THEIR specs, out of concern that precisely what the WHATWG does would happen; that a third party would attempt to wrest the "definitive" title from them.  I would hope the W3C adds value to their versions of WHATWG specs, driven by their consensus work mode, and intellectual property policy*; if none, then I would expect the actors to participate in the WHATWG instead.

-Chris

* I would point out that the lack of a coherent IP policy prevents some actors from participating, and likely always will.  One can debate the value of consensus, but some of us believe it's somewhat important.

[Chris Wilson]

On Tue, Apr 15, 2014 at 3:06 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:

As Ojan said, Blink project consensus is to follow the WHATWG spec

over the W3C fork when both exist.

Actually, Ojan said

> In all the cases I know of where we're implementing a spec, if there's a WHATWG spec and the W3C has a fork, we look exclusively at the WHATWG version of the spec.

Which is not a statement of consensus, merely anecdotal evidence.  Is this policy declared?

As an aside, I think this would be a ludicrous policy.  Why would we look EXCLUSIVELY at the WHATWG version?  I would think the primary goal for Blink would be interoperability across browser implementations, and sadly due to IP concerns that would require investigating, at the very least, the W3C version as well.

[Adam Barth]

This thread is very active, but I wanted to answer your specific question.

On Tue Apr 15 2014 at 1:51:16 PM, Si Robertson <retrom...@gmail.com> wrote:

I have a question regarding this.

If the W3C and WHATWG ever encounter a situation where neither party can agree on an API specification, and both versions (W3C/WHATWG) of that specification remain inconsistent, which specification should be regarded as "the" standard one for developers to follow?

Sadly, developers are the ones who lose out in these sorts of disagreements.  In practice, I would expect developers follow whichever version gets implemented the browsers of their users.  If the browser implementations are split, then I would expect developers to create compatibility shims like in the bad old days of attachEvent/addEventListener.  Hopefully if we do our jobs well, we can help developers avoid that pain.

Adam

[Dirk Schulze]

On Apr 15, 2014, at 10:51 PM, Si Robertson <retrom...@gmail.com> wrote:

> I have a question regarding this.
>
> If the W3C and WHATWG ever encounter a situation where neither party can agree on an API specification, and both versions (W3C/WHATWG) of that specification remain inconsistent, which specification should be regarded as "the" standard one for developers to follow?

In situations where developers do not follow a spec blindly we try to sort problems out and reach consensus on mailing lists. This happened with many APIs of Canvas. As Rik pointed out, Path2D was one example where browser implementers spoke with each other, implemented the API and eventually the WHATWG spec changed.

I really really hope that engineers are always skeptical. Regardless if the spec is written by WHATWG or W3C. Therefore, I disagree with Ojan and Tab that you should exclusively follow WHATWG. Of course the same is the case for W3C specs. Instead we should try to talk more with other browser vendors.

IMO interoperability is much more important than following a spec. It is great to have a spec that gives guidance how the web should be shaped. At the end of the day, a spec must reflect reality also. If we have interoperable implementations the spec needs to reflect that even if it means the spec needs to change. We have been very fortunate that web specs and implementations live in a symbiosis for the last years.

Greetings,
Dirk

[Anne van Kesteren]

On Tue, Apr 15, 2014 at 11:08 PM, Chris Wilson <cwi...@google.com> wrote:
> The WHATWG says it's fine to fork their specs;

That is false. Making it possible to fork does not mean you are fine
with another organization doing that.

In particular, I have a hard time with the W3C making copies of my
work, causing significant confusion, and adding no value upstream (IPR
protection requires a published REC, not drafts months or years out of
date).

I gave the reasons for CC0 (and thereby allowing forking) here:
http://annevankesteren.nl/2013/03/zero


--
http://annevankesteren.nl/

[Si Robertson]

Does WHATWG have a clean index of web APIs anywhere? I'm finding it difficult to locate specific APIs at whatwg.org, e.g. Web Audio, Web MIDI, Web RTC, Gamepad, etc. I have 24 modern APIs bookmarked but they are W3C versions of the specs, and I would like to bookmark the WHATWG specs as well.

Thanks.

[PhistucK]

Like this?

http://www.whatwg.org/specs/

☆PhistucK

On Wed, Apr 16, 2014 at 4:22 PM, Si Robertson <retrom...@gmail.com> wrote:

Does WHATWG have a clean index of web APIs anywhere? I'm finding it difficult to locate specific APIs at whatwg.org, e.g. Web Audio, Web MIDI, Web RTC, Gamepad, etc. I have 24 modern APIs bookmarked but they are W3C versions of the specs, and I would like to bookmark the WHATWG specs as well.

Thanks.

[Rik Cabanier]

On Wed, Apr 16, 2014 at 3:11 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Apr 15, 2014 at 11:08 PM, Chris Wilson <cwi...@google.com> wrote:
> The WHATWG says it's fine to fork their specs;

That is false. Making it possible to fork does not mean you are fine
with another organization doing that.

You're confusing "fine" with "I don't like it". Per your own email, it is allowed/fine to fork the whatwg spec

 

In particular, I have a hard time with the W3C making copies of my
work, causing significant confusion, and adding no value upstream (IPR
protection requires a published REC, not drafts months or years out of
date).

I don't particularly like that you call this "your work". Yes, you are the one that typed in the words and slaved over the issues but multiple people contributed. 

The web belongs to everyone.

I agree that the W3C is frustratingly slow. From my own experience with the canvas spec, it's just too easy for one person or group to delay things for years (which discourages moving the spec forward).

[Si Robertson]

Nope, I have been looking through the those pages. I guess I'm looking for something similar to this, basically an index of APIs. If I'm going to start referencing the WHATWG specs I don't want to waste hours of my time digging through the site looking for specific APIs.

[PhistucK]

Does the W3C have a page equivalent to the MDN one you mentioned?

Anyway, just use Google! getContext inurl:whatwg.org/specs

☆PhistucK

[Si Robertson]

Most of the MDN documents link directly to the W3C specs, so finding specific W3C specs isn't a problem.

Google isn't the answer to everything... AudioContext inurl:whatwg.org ... :-)

Simple question, where are the specifications for Web Audio and Web MIDI at the WHATWG site? That might get me started in the right direction.

[PhistucK]

You left out the "/specs" string in the search query. It has no results. I am not sure Web Audio is specified by the WHATWG at all, so, yes, Google is the answer to everything (in your example). ;)

Same for Web MIDI.

The specifications are not always shared between the two. Only some of them are shared and you can see everything the WHATWG specifies in the whawg.org/specs page I mentioned.

Perhaps https://github.com/whatwg has a bit more, or specifications that are in early development, I am not sure.

Perhaps this is helpful?

http://platform.html5.org/

It is also maintained by the WHATWG, it seems (it appears in its GitHub repositories).

☆PhistucK

[Si Robertson]

Yep, the platform.html5.org link is useful, thanks for that. I will also follow links from the chromestatus.com page and MDN.

After this recent W3C vs WHATWG discussion two things are very clear from where I'm sitting - (1) documentation for standard web APIs is fragmented and messy, there really needs to be a single umbrella organisation to consolidate everything and make developers lives easier. (2) WHATWG really doesn't appear to have much involvement in web standards, so I'm not sure why this discussion got so heated in the first place, the majority of links at the MDN, platform.html5.org and chromestatus.com sites point at W3/W3C documentation.

Make of that what you will, overall I'm finding all of this frustrating more than anything else, and I'm not surprised there is a lot of confusion and misinformation in web development circles.

Anyway, thanks again :-)

[Chris Wilson]

Si, not all web specs have a WHATWG and a W3C one.  The two you mentioned - Web Audio and Web MIDI - are managed and published only in the W3C Web Audio WG.  Similarly, there are many other APIs that are not worked on (in the main) in the WHATWG.

[Chris Wilson]

On Wed, Apr 16, 2014 at 7:48 AM, Si Robertson <retrom...@gmail.com> wrote:

...WHATWG really doesn't appear to have much involvement in web standards...

/me *runs to microkitchen, makes big bowl of popcorn, runs back to laptop to watch* 

[Si Robertson]

Haha, well as I mentioned my previous comment (paraphrasing here) most of the links on the sites that I trust and use point to W3/C docs :-)

[PhistucK]

The WHATWG is maintaining the main specification - the HTML specification, which is (arguably) the most important one, from which everything basically derives.

That was a (really) wrong statement, anyway. Of course it is involved in web standards. HTML, URL and DOM are the pretty much the foundation of web clients (after network and protocol level stuff like TCP/IP and HTTP/HTTPS, obviously).

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Wilson]

On Wed, Apr 16, 2014 at 3:11 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Apr 15, 2014 at 11:08 PM, Chris Wilson <cwi...@google.com> wrote:
> The WHATWG says it's fine to fork their specs;

That is false. Making it possible to fork does not mean you are fine
with another organization doing that.

Perhaps "fine" does not describe your emotional state about it, but the license knowingly and willfully releases this control, with full knowledge that others may do things the original author considers incorrect, unfair, amoral or abhorrent. [*]

 

(IPR protection requires a published REC, not drafts months or years out of date).

 IPR protection requires a significant number of stakeholders to all sign up to contribute any potential IP.  You are correct a published REC is a linchpin for this, but it's not the only part.  (The cycle of drafts come in to play in consensus-building.)

I gave the reasons for CC0 (and thereby allowing forking) here:
http://annevankesteren.nl/2013/03/zero

Per your own statement there, I think you are discounting the fact that there appear to be a significant group who think "the person or entity maintaining the standard [is] tak[ing] it in the wrong direction" (referring to the WHATWG) - both some of the finer points of HTML, and the overall IP status and policy of the WHATWG.  You may, of course, disagree - but you 

-C

[*] I began my professional programming career working at the University of Illinois on NCSA PC Telnet, which was an open-source, open-license product.  Not only did others take the source, repackage and enhance it and resell (!) it, which was allowed by the license - the University of Illinois actually PAID for a site license to one of these packages, so every computer lab in UofI had a non-NCSA Telnet product (though a derivative) on its PCs.  So I understand the frustration.  But that's what CC0 means; you don't get to control it.

[Jon Rimmer]

On Wednesday, April 16, 2014 5:54:15 PM UTC+1, Chris Wilson wrote:

On Wed, Apr 16, 2014 at 3:11 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Apr 15, 2014 at 11:08 PM, Chris Wilson <cwi...@google.com> wrote:
> The WHATWG says it's fine to fork their specs;

That is false. Making it possible to fork does not mean you are fine
with another organization doing that.

Perhaps "fine" does not describe your emotional state about it, but the license knowingly and wilfully releases this control, with full knowledge that others may do things the original author considers incorrect, unfair, amoral or abhorrent. [*]

 

But it doesn't relinquish any right to condemn the behaviour of those who do fork the specifications for nefarious reasons, or to call out their hypocrisy, or to label them as bad actors. Indeed, such public condemnation is a necessary counter-balance to the liberal nature of the licensing. And any protest that "the licence says we can!" is further evidence of bad faith, since those involved fully understand the reasons why WHATWG specs provide a forking escape-hatch, because it is a direct response to the W3C's dysfunctional management of HTML that lead to the creation of the WHATWG and required it to rewrite the HTML specification.

A healthy community should not rely on all acceptable and unacceptable behaviour being explicitly delineated and enforced by legal rules. Far better is for the rules to provide a liberal baseline, which allows for flexibility and adaptation to changing circumstances, but with conventions and community approbation that exposes bad behaviour and routes around it where necessary. Policies that explicitly favour original, up-to-date specifications over unnecessary forks are a good example of the latter approach.

[Anne van Kesteren]

On Wed, Apr 16, 2014 at 2:28 PM, Rik Cabanier <caba...@gmail.com> wrote:
> On Wed, Apr 16, 2014 at 3:11 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
>> On Tue, Apr 15, 2014 at 11:08 PM, Chris Wilson <cwi...@google.com> wrote:
>> > The WHATWG says it's fine to fork their specs;
>>
>> That is false. Making it possible to fork does not mean you are fine
>> with another organization doing that.
>
> You're confusing "fine" with "I don't like it". Per your own email, it is
> allowed/fine to fork the whatwg spec

To use your line, you are confusing a license with an organization.
The WHATWG does not endorse plagiarism. The license the WHATWG uses
does allow for it. That distinction is important.

>> In particular, I have a hard time with the W3C making copies of my
>> work, causing significant confusion, and adding no value upstream (IPR
>> protection requires a published REC, not drafts months or years out of
>> date).
>
> I don't particularly like that you call this "your work". Yes, you are the
> one that typed in the words and slaved over the issues but multiple people
> contributed.

I'm pretty certain that the specifications I wrote would not be there
if I had not written them. I would be happy to be proven wrong so I
can work on something else, but so far encouraging people to work on
hard low-level issues has not yielded much result.

Of course the work is the result of many people providing input, but
we're not simply merging in edits.

> The web belongs to everyone.

Yes, hence CC0.

> I agree that the W3C is frustratingly slow. From my own experience with the
> canvas spec, it's just too easy for one person or group to delay things for
> years (which discourages moving the spec forward).

You guys made 27 distinct copies of that specification, none of them
really better than the original. It's quite a show.


--
http://annevankesteren.nl/

[Chris Wilson]

On Wed, Apr 16, 2014 at 10:39 AM, Jon Rimmer <jon.r...@gmail.com> wrote:

On Wednesday, April 16, 2014 5:54:15 PM UTC+1, Chris Wilson wrote:

On Wed, Apr 16, 2014 at 3:11 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Apr 15, 2014 at 11:08 PM, Chris Wilson <cwi...@google.com> wrote:
> The WHATWG says it's fine to fork their specs;

That is false. Making it possible to fork does not mean you are fine
with another organization doing that.

Perhaps "fine" does not describe your emotional state about it, but the license knowingly and wilfully releases this control, with full knowledge that others may do things the original author considers incorrect, unfair, amoral or abhorrent. [*]

 

But it doesn't relinquish any right to condemn the behaviour of those who do fork the specifications for nefarious reasons, or to call out their hypocrisy, or to label them as bad actors.

Well, it doesn't say anything about that, it's true.  But I would not agree that the W3C is being "nefarious", hypocritical (opportunistic, perhaps), or "bad actors" (in any of the classic definitions I could find).

 

Indeed, such public condemnation is a necessary counter-balance to the liberal nature of the licensing.

And the willful ignorance of any such condemnation is a necessary counter-balance to that, as well.  "The tree of liberty must be refreshed from time to time with the blood of patriots and tyrants" and all that.

 

And any protest that "the licence says we can!" is further evidence of bad faith, since those involved fully understand the reasons why WHATWG specs provide a forking escape-hatch, because it is a direct response to the W3C's dysfunctional management of HTML that lead to the creation of the WHATWG and required it to rewrite the HTML specification.

And the W3C's self-serving licensing of their specifications engenders major corporations being members, which feeds the intellectual property pipeline that keeps major vendors from sueing each other for implementing CSS (or whatever). 

I fully understand why WHATWG specs allow forking, as I was around before, during and after the "dysfunctional management of HTML".  Sooner or later, revolutions have to establish a working government or consider they've achieved their goals in the active government.

A healthy community should not rely on all acceptable and unacceptable behaviour being explicitly delineated and enforced by legal rules. Far better is for the rules to provide a liberal baseline, which allows for flexibility and adaptation to changing circumstances, but with conventions and community approbation that exposes bad behaviour and routes around it where necessary. Policies that explicitly favour original, up-to-date specifications over unnecessary forks are a good example of the latter approach.

Policies that explicitly favor IP awareness are also desirable.

In short: this is not so black and white as one might like to believe.  Should there be some protections so the W3C doesn't "lead the world down another dysfunctional path"?  Yes.  (FWIW, the W3C is very different now that it was then.)  Does that require forkability?  I dunno.  Can the WHATWG simply replace the need for the W3C?  Certainly not in its current form.

[Si Robertson]

If everyone is aiming for a world of open and standardized web APIs, API copyrights and/or API IP claims shouldn't even enter the discussion, both should be null and void. This bickering between different standardization groups is frightening and, quite frankly, childish.

Google and Mozilla, get together and form a new standardization group, boycott the existing ones and clean this mess up :-)

[Chris Wilson]

On Wed, Apr 16, 2014 at 1:11 PM, Anne van Kesteren <ann...@annevk.nl> wrote:

The WHATWG does not endorse plagiarism. The license the WHATWG uses

does allow for it. That distinction is important.

Please do not use inflammatory and incorrect words.

Plagiarism is "an act or instance of using or closely imitating the language and thoughts of another author without authorization and the representation of that author's work as one's own, as by not crediting the original author." (dictionary.com)

The WHATWG's license authorizes this use, and at least in the case of the HTML spec, Hixie and the WHATWG are explicitly credit, not only in the past but in the current tense; the "living standard" is even still referenced.

[Chris Wilson]

That would be a clear invokation of 927.

[Chris Wilson]

s/invokation/invocation.  Sigh.

[Si Robertson]

Yes it would, but in this case Google and Mozilla definitely have the muscle to make it work, and they have all the respect they need from the web development community. Existing web standardization groups would quickly be relegated to the tomes of history.

[PhistucK]

If you think about it, the two main people of the WHATWG (if I understand correctly) are Ian and Anne. Ian is a Googler (formerly from Opera, earlier from Netscape, which was a somewhat early incarnation Mozilla). Anne is a recent Mozillian (also formerly from Opera).

So, there you have it. ;)

☆PhistucK

[Glenn Adams]

On Wed, Apr 16, 2014 at 3:59 PM, PhistucK <phis...@gmail.com> wrote:

If you think about it, the two main people of the WHATWG (if I understand correctly) are Ian and Anne. Ian is a Googler (formerly from Opera, earlier from Netscape, which was a somewhat early incarnation Mozilla). Anne is a recent Mozillian (also formerly from Opera).

So, there you have it. ;)

This is why I previously stated that the WHATWG does not follow a consensus process. It endows certain individuals with the privilege of speaking for the entire community, whether some or or all of that community agrees with the results.

Even though I have a lot of respect for the technical output of these individuals, I don't always agree with their position, conclusion, or resulting work. And I have no recourse and no due process when it comes to resolving differences or even in insisting that they listen to my objections or those of anyone else.

IMO, this and the IP situation are sufficient to assign lower priority to WHATWG work, no matter what form it takes. At least the W3C doesn't have these problems, no matter how bad the "stale snapshot" problem is perceived.

[Rik Cabanier]

On Wed, Apr 16, 2014 at 1:11 PM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Wed, Apr 16, 2014 at 2:28 PM, Rik Cabanier <caba...@gmail.com> wrote:
> On Wed, Apr 16, 2014 at 3:11 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
>> On Tue, Apr 15, 2014 at 11:08 PM, Chris Wilson <cwi...@google.com> wrote:
>> > The WHATWG says it's fine to fork their specs;
>>
>> That is false. Making it possible to fork does not mean you are fine
>> with another organization doing that.
>
> You're confusing "fine" with "I don't like it". Per your own email, it is
> allowed/fine to fork the whatwg spec

To use your line, you are confusing a license with an organization.
The WHATWG does not endorse plagiarism. The license the WHATWG uses
does allow for it. That distinction is important.

Chris already replied far better than I could to this point :-)

 

>> In particular, I have a hard time with the W3C making copies of my
>> work, causing significant confusion, and adding no value upstream (IPR
>> protection requires a published REC, not drafts months or years out of
>> date).
>
> I don't particularly like that you call this "your work". Yes, you are the
> one that typed in the words and slaved over the issues but multiple people
> contributed.

I'm pretty certain that the specifications I wrote would not be there
if I had not written them. I would be happy to be proven wrong so I
can work on something else, but so far encouraging people to work on
hard low-level issues has not yielded much result.

Of course the work is the result of many people providing input, but
we're not simply merging in edits.

Yes, people trust you to make the right decision.

 

> The web belongs to everyone.

Yes, hence CC0. 

> I agree that the W3C is frustratingly slow. From my own experience with the
> canvas spec, it's just too easy for one person or group to delay things for
> years (which discourages moving the spec forward).

You guys made 27 distinct copies of that specification, none of them
really better than the original. It's quite a show.

You must be referring to this list: http://damowmow.com/temp/canvas-specs

At first glance, this does seem terrible. However, only the first spec (from 2006) doesn't have correct link to the latest version at the top.

Most of the other links are published working drafts or proposed extensions.

There's only one spec (http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas) that is built from a stale branch and I already asked for it to be removed a couple of times. AFAIK the only way to find it is through a google search.

Most of those links are the "heartbeat" specs that the HTML WG likes to do. I guess people complained that specs languished so they decided to produce one every quarter :-)

[PhistucK]

Hey - my response was not meant to be taken this way. I am not familiar with the actual politics in the WHATWG. I wrote that they are the two main people. This is not to say there is no consensus, this just means they are the two main people.​ I simply responded to the idea of Si.
However, I assume you know better here, since you are actively involved in these processes (WHATWG and W3C).

☆PhistucK

[Ojan Vafai]

I'm intentionally ignoring the discussion of WHATWG vs. W3C forking policies, IPR, etc. blink-dev is not the right place to discuss this.

In starting this thread, I just wanted to clarify that we use the most up to date version of the spec. We don't use outdated forks of specs. In practice, the WHATWG versions of specs are more up to date and represent wider input from browser vendors and thus are the specs to implement in order to achieve interoperability, which is primary goal of specs.

Of course, it's possible that in the future the WHATWG specs will become stale, in which case we won't use them. That's just not the case at the moment.

On Wed, Apr 16, 2014 at 12:10 AM, Dirk Schulze <dsch...@chromium.org> wrote:

On Apr 15, 2014, at 10:51 PM, Si Robertson <retrom...@gmail.com> wrote:

> I have a question regarding this.
>
> If the W3C and WHATWG ever encounter a situation where neither party can agree on an API specification, and both versions (W3C/WHATWG) of that specification remain inconsistent, which specification should be regarded as "the" standard one for developers to follow?

In situations where developers do not follow a spec blindly we try to sort problems out and reach consensus on mailing lists. This happened with many APIs of Canvas. As Rik pointed out, Path2D was one example where browser implementers spoke with each other, implemented the API and eventually the WHATWG spec changed.

I really really hope that engineers are always skeptical. Regardless if the spec is written by WHATWG or W3C. Therefore, I disagree with Ojan and Tab that you should exclusively follow WHATWG. Of course the same is the case for W3C specs. Instead we should try to talk more with other browser vendors.

IMO interoperability is much more important than following a spec. It is great to have a spec that gives guidance how the web should be shaped. At the end of the day, a spec must reflect reality also. If we have interoperable implementations the spec needs to reflect that even if it means the spec needs to change. We have been very fortunate that web specs and implementations live in a symbiosis for the last years.

Greetings,
Dirk

>
>
> On Tuesday, 15 April 2014 21:40:56 UTC+1, Adam Barth wrote:
> I think it's also fair to say that if there's a disagreement between a W3C spec and a WHATWG spec, that's something worth understanding.  The most common cause is just that the W3C spec is out-of-date, but sometimes there's an underlying argument between two groups of people, and in those cases it's worth at least understanding the arguments from each side.
>
> Adam
>
>
> On Tue Apr 15 2014 at 12:25:25 PM, Ojan Vafai <oj...@chromium.org> wrote:
> Changing the subject so that the original thread can stay focused on the fullscreen/pointerlock questions.
>
> Elliott's statement isn't as definitive as the situation is in practice. In all the cases I know of where we're implementing a spec, if there's a WHATWG spec and the W3C has a fork, we look exclusively at the WHATWG version of the spec. As far as I know, there is consensus on this among Blink developers.
>
> The primary reason for this is that the WHATWG specs are kept up to date and unversioned.
>
> The only case that needs linking to both the W3C version and the WHATWG version is when there's something in the W3C version that's not in the WHATWG version. In which case, the history of how that came to be needs to be explained.
>
> As Domenic said on the original thread, maybe we should document this somewhere. I'm not really sure where would be useful.
>
>
> On Tue, Apr 15, 2014 at 10:30 AM, Glenn Adams <gl...@skynav.com> wrote:
>
> On Tue, Apr 15, 2014 at 10:53 AM, Elliott Sprehn <esp...@chromium.org> wrote:
>
> On Tue, Apr 15, 2014 at 11:51 AM, Glenn Adams <gl...@skynav.com> wrote:
>
> [...]
>
>
> On 15 April 2014 15:45, Anne van Kesteren <ann...@annevk.nl> wrote:
>
> On Tue, Apr 15, 2014 at 3:35 PM, Si Robertson <retrom...@gmail.com> wrote:
> > Some of the docs are, but at least in this case the W3 docs show how stable
> > the API is considering nothing has changed since mid 2012 :-)
>
> Right, and that is false. The W3C copying work of others causes
> nothing but such confusion.
>
> There is not a consensus on this point. Those of us who have been involved in the W3C and other SDOs (Standards Development Organizations) for a long time tend to recognize only W3C documents; others who don't have that history tend to prefer the WHATWG.
>
> There is no correct answer. Only opinions.
>
>
> Note that blink does favor living standards as they have many advantages over the versioned spec and last call process.
>
> It is worth noting that the WHATWG documents suffer from problems as well:
>       • their IPR status is indeterminate
>       • they do not follow a consensus process
>       • they do not have a wide spread industry commitment
>       • they are not recognized by most other SDOs
>       • being "living" there is no fixed version to test against
> IMO, due diligence would suggest consideration be given to both W3C and WHATWG versions of the "same|similar" technical specifications, and a judgment will have to be rendered when there are differences.
>
> For citation purposes, it would be useful to cite both and call out any significant technical differences.
>
>
>
>
>