W3C home > Mailing lists > Public > public-html-admin@w3.org > November 2014

Re: W3C/WHATWG overlap going forward

From: Sam Ruby <rubys@intertwingly.net>
Date: Fri, 28 Nov 2014 05:35:00 -0500
Message-ID: <54784FD4.4020809@intertwingly.net>
To: public-html-admin@w3.org
On 11/28/2014 03:34 AM, Henri Sivonen wrote:
> On Wed, Nov 12, 2014 at 5:28 AM, Sam Ruby <rubys@intertwingly.net> wrote:
>> 1) A number of individuals within the WHATWG would like to see the W3C no
>> longer copy and/or work on areas that overlap with ongoing WHATWG efforts.
>
> I think that *if* the W3C is going to specify things that do overlap
> WHATWG efforts, rewriting things to "not copy" is worse than copying,
> since rewrites are likely to introduce subtle deviations. I think the
> ideal outcome would be for the W3C normatively reference WHATWG specs
> such that the normative statement get imported by reference under the
> PP; see the last sentence of this email.
>
>> There also is an interest in limiting the
>> observable differences between what the WHATWG HTML spec and the W3C HTML
>> require of both content producers and user agents.
>
> Indeed.
>
>> 3) We discussed proposals for modularity
>
> This seems to contradict the point quoted above about limiting the
> differences between WHATWG HTML and W3C HTML.

I encourage everybody to read the original email:

http://lists.w3.org/Archives/Public/public-html-admin/2014Nov/0036.html

In particular, the line "We clearly have conflicting priorities.  It 
happens.".

>> 1) We expect to only provide non-substantive errata for 5.0.
>
> Will 5.0 then be marked obsolete as soon as it is known to contain
> substantive errors? It seems bad to let people read something that has
> known substantive errors without warning the readers.

It seems to me that this suggestion would apply to all specifications, 
not just HTML.  Changes to how the W3C deals with errata are being 
explored on public-w3process:

http://lists.w3.org/Archives/Public/public-w3process/2014Nov/0121.html

I encourage you to bring up your suggestions there.  It is my 
expectation that the HTML WG will follow the outcome of that discussion.

>> 3) In 1Q15, we will identify which specs in the WHATWG the HTML WG would
>> like to refer to directly, and will schedule a call with the director to
>> build a plan.  Examples of documents that could be referenced by W3C HTML
>> Work: Fetch, URL, Streams.
>
> Cool. If Fetch, URL and Streams become referencable by the W3C, why
> not WHATWG HTML itself so that the W3C could focus on extension specs?

For reasons mentioned in the above mail (0036.html), I see this as 
unlikely to occur in the near term.  I also believe that it is unlikely 
to occur for "kitchen sink" specifications.  As work in that 
specification is "spun out" into separate specifications, directly 
referencing those parts is much more of a possibility.

> I wonder if this WG could, from time to time, publish a REC that, in
> addition to boilerplate, just says "This Recommendation normatively
> references the snapshot of WHATWG HTML dated yyyy-mm-dd as if its
> normative statements were included herein." (Where yyyy-mm-dd is
> enough in the past for Members to have time to be comfortable. The
> current track record suggests this doesn't need to be more than a year
> in the past. I suppose continuing the statement with "except for X, Y
> and Z" would still be better than the W3C publishing a different
> document or, worse, a set of modularized documents and leave it as an
> exercise to the reader to figure out the diffs.)

For archival purposes, I would like to see the snapshot hosted at the 
W3C.  First with URL, and then with others, I'd like to explore that 
snapshot being the Recommendation itself.  Related reading on my current 
thinking on how that would occur:

http://intertwingly.net/blog/2014/11/20/WHATWG-W3C-Collaboration
http://lists.w3.org/Archives/Public/public-w3process/2014Nov/0185.html

- Sam Ruby
Received on Friday, 28 November 2014 10:35:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:57:30 UTC