A few years ago, the W3C reached out to the WHATWG in order to put an end to the continuous bickering, stop work duplication, end the confusion that developers (and many others) feel due to the split, etc. The proposal was made in private to avoid the acrimonious politics that it would draw and in the hope of eventually surfacing it as a bilateral proposal rather than an olive branch from just one protagonist. (This may have been a mistake.)
The founding principle of the proposal was that in a world of computers and automated publishing, the living standard versus snapshot divide is stupid: you can have both, with one generated from the other. There is no need to convince others that your view is best. There is certainly no need to condescend to Web developers because they may not behave the way you wish they did. You only need to make it clear which is which and what each is for.
This proposal came after the Web Platform Test Project, which was a continuous and extremely friendly collaboration between the W3C and WHATWG, and may therefore have been overly optimistic (especially since it required approval from people not involved in WPT).
Either way, it was rejected by the WHATWG after long discussions. (Note that it was not formally accepted by the W3C either since that would have been a pointless exercise after the rejection).
It was known informally as the “Kadesh Proposal”, named after the Treaty of Kadesh. It also featured a prototype example implementation, but that no longer really works today, notably it no longer has the WHATWG logo, due to a bunch of third-party resources having been moved and other such bitrot.
I leave it below should anyone be interested.
- Both the
title
andh1
clearly mark snapshot documents as such. - Snapshot documents make use of
meta robots noindex
so as to never show up in search engines. - Snapshots of documents developed in collaboration by the two peer organisations are co-branded: both W3C and WHATWG logos, and if applicable the spec-specific logo.
- The “Usage of this Document” section clearly spells out what snapshots and live documents are for, which one you want to use for different purposes (in a non-judgemental manner), which is the default if you don't know, and a clear link. The proposed text which was derived from a previous discussion is included below.
- Banner: when you scroll anywhere in the snapshot past the "Usage of this Document" section a banner sticks to the top pointing out that it's a snapshot, and linking to the usage description and live document (the test implementation one was ugly as hell, this could of course be made nice).
- Style override. The same style override used to make Rescinded Recommendations look less like standards is applied (it's all pretty drab and black).
- There is a clear link to the live version from the snapshot (actually several).
- In snapshots, the subtitle further indicates the snapshot status.
- In most cases I would anticipate that a snapshot is just a version of the live document at a given moment in time. If however for whatever reason a trimmed-down snapshot is required (eg. because the live version has too far-fetched proposals, very detached from reality as can happen with some editors) and someone other than the live editor(s) made that change, that person is marked as “Publishing Editor”, without any change to the original editors' list.
Web standards are available in two flavours: snapshots, which are immutable versions made at a point in time and guaranteed never to change, and live versions which capture as much as possible the latest state of the technology and are intended to be continuously maintained and kept up to date.
Which version you should rely on and reference depends on your needs. If your specific situation demands am unchanging document, understanding that it is likely to contain defects that have been addressed elsewhere, then you will want to use the snapshot. If however you require a document that is as up-to-date as possible, then the live version is for you. If in doubt, we recommend you rely on the live document.
This document is a snapshot document. For the live version, please visit https://yadda yadda some link.
Yeah this failed for the same reason "compromises" with the W3C always fail: it doesn't address the fundamental reasons for the WHATWG to exist. For example, it continues to push for the existence of out-of-date copies of documents that look important and that people will reference.
The only reason for snapshots to exist is legal (patent protection), and so documents that exist for that purpose should be labeled as such. No blog posts about how "HTML 5.2 released!" and such other nonsense. No need for any branding at all (the fact that you even care about the branding on such documents shows that you want people to look at them).
Plus this does nothing to resolve the many, many other problems with the W3C. I've made lists of those over the years. Here's a copy of one of the times I made a proposal:
IDEAS FOR THE W3C
SHORT TERM: A PROPOSAL FOR HOW A WORKING GROUP SHOULD WORK
Here is a description of the work environment that I propose we use to
develop technologies in a W3C context. I present this merely as a
starting point for discussion; I am very open to negotiation. I
haven't included detailed rationales for many of them, since I hope
they are self- evident, but if they are not please do feel free to ask
me about them.
the group is open to anyone, not just people who are employed by
members (employees of members are required to go through their
employer; also I understand there are some complications with
employees of certain companies like Yahoo!, and this is not meant
to in any way affect that).
the WG does not have recurring teleconferences or face-to-face
meetings. (These are highly unfair to group members who do not have
an employer backing their participation, as well as being generally
extremely unproductive ways of making progress.) Individual members
of the group are naturally welcome to meet as they wish, and are
encouraged to present the fruits of such focused meetings to the
group by e-mail.
tentative decisions are first made by the editor by editing the
draft in response to feedback, and then fixed in response to
further feedback; the chair can then override such decisions if the
editor's decision is clearly wrong in terms of what the
implementors will implement (see above; the implementor have
ultimate authority).
no decisions are made in adhoc teleconference or face-to-face
meeting -- all technical input must be considered, whether it be
from someone in Africa who can't afford to travel to their next
village or from someone like us who can afford to rush to another
country on a whim. In particular, this means that "well we decided
at the foobar meeting that..." is never a valid argument.
editorial (non-normative) issues are left entirely to the editor,
the WG's time is not wasted dealing with issues such as what colour
an example should be. (The chair and the editor are encouraged to
discuss topics like this, of course, and the chair can always assign
another editor if the editor continually makes poor decisions.)
arguments are generally to be grounded in reason and data, not
unfounded assertions or "expert" opinions. (An "expert" is someone
who can present good rationales and knows the relevant data, not
someone with strong opinions.)
the TAG and a11y groups don't get treated as any more privileged
sources of feedback than any random person on the web. They need to
provide rationales and data just like everybody else.
the group is encouraged to seek out feedback from other groups such
as the TAG and a11y groups, but also from bloggers, community sites
that discuss the specs like A List Apart, discussion forums like
reddit, etc.
stability of the spec is decided by what is interoperably implemented,
not by a statement of the working group. It doesn't matter if the
editor thinks that a section of the spec is perfect; if it isn't
implemented, or doesn't match implementations, it's still not done.
the implementors with the majority of the likely resulting user
base must have absolute decision authority, not Tim, not the WG
chair, not me, not the accessibility community. They vote by writing
code and shipping it.
the WG's work product's authoritative version would be the most up
to date draft (either on dev.w3.org, or somewhere that immediately
mirrors dev.w3.org, or some other location that the spec editor's
changes go to). This is what press releases, etc, must point to,
not the TR page (unless the TR page is the location that is
continually updated to match the most recent changes, which would
be fine too, but is presumably even more radical).
the WG's work product must be licensed under the MIT license (under
W3C copyright, presumably), or another license that allows
unrestricted forking, reuse, editing, embedding in works with any
other license, whether itself free or proprietary, etc.
static copies of the WG's work product published by the W3C, e.g.
when a draft snapshot is published to the TR page, must be clearly
marked as being obsolete snapshots when published. For example,
either the document could have an always-visible warning, or the
document's title could be "Patent Policy Snapshot for WebSRT -
August", or some such.
the WG's work product must regularly (e.g. every six months or
every year) go through the entire patent policy cycle (i.e.
FPWD/LC/REC). This is to avoid coupling the patent policy
commitments (which are generally desired quickly and which
certainly need to apply as soon as implementations start appearing)
to the stability commitments (which are generally tied to proving
interoperability, something which only happens years after
implementations are well-established in the market). There should
not be any interpretation of "REC" in this context as being related
to stability, however.
the WG must be able to publish without fighting about pubrules
every time. For example:
if the document has a link to some third-party site (e.g.
oreilly.com) in some example, that link doesn't get removed
because of some obscure pubrules.
the document's styles don't have to match W3C styles if there is
a good reason to differ from W3C styles. (Naturally, this
doesn't apply just to change for change's sake.)
the document can use the latest version of HTML or other
technologies.
any timetable associated with the work is actually realistic, not a
hopefully optimistic fantasy designed to make the AC members happy.
the WG only has a public mailing list.
the WG only has one chair.
the WG chair assigns responsibilities like editorship, who runs
official group blogs, twitter accounts, wikis, etc.
people of practical importance in the working group (specifically,
the implementors) have significant impact on the selection of the
chair; the chair is not just opaquely appointed by W3C staff.
the WG chair gets the complete authority and technical ability to
ban anyone from that mailing list when they are disruptive, whether
that be through being rude, or through process trolling, or through
drowning the WG in minutiae, or through incompetence, at the WG
chair's discretion, even if that person is W3C staff, or me, or a
representative of a member company.
the W3C staff doesn't try to apply pressure on the chairs to get
things done quickly, or done in a particular way, etc. Reaching REC
is not a goal; interoperability is the only goal.
LONG TERM: A PROPOSAL FOR HOW THE W3C SHOULD WORK
At a high level, I think the organisation that develops the Web's
standards could consist of no more than:
hire and fire power over the following two people
moderator power over the mailing lists mentioned later
keep the servers running
keep the software up to date
fielding press
organising the meeting mentioned later
convincing one or two companies to make donations to
pay for the tech, the people person, the hardware,
and the meeting mentioned later
a list for authors to get authoring help
a list for css, svg, and other presentation-level tech
a list for webidl, dom core, and other core-level tech
a list for html, apis, and other semantic-level tech
an editor with exclusive editing authority, and each
licensed such that anyone who wants to try to write a
competing version of the spec can do so
new spec or a fork of an existing one
with part of the meeting being unconference-style with
rooms no bigger than ten people, and the other part
being a group activity like a trip to a tech museum,
skiing, white-water rafting, a trip to the beach...
so that companies can volunteer to grant their patents,
much like the W3C CG FSA
updates it gets a big warning at the top of the document
warning that the document is likely obsolete
There's a zillion other ways it could be set up, I'm not saying the
above is the only way, or even the best way.
SOME PROBLEMS
Here are some problems I've described in the past:
I think more fundamentally I would just phrase it as "there is too much
bureaucracy". For example, a spec's editor shouldn't have to go through a
multiyear process to explain why the document should be self-hosting (e.g.
why HTML4 should use an HTML4 DOCTYPE or XHTML1 should use an XHTML1
DOCTYPE). That's absurd. And yet it's par for the course -- despite years
of asking to be allowed to do so, the HTML working group has still been
barred by W3C staff from publishing the HTML5 spec using HTML5.
Similarly, the whole TR/REC process is out of touch with reality. In
practice, while it's useful for some government, contractual, and patent
protection purposes to have frozen snapshots that can be unambiguously
referenced, the majority of the Web is best served by directly referencing
the latest updates. As a concrete example, the latest HTML5 editor's draft
is a better reference for implementors and Web authors than the HTML4 REC.
And tomorrow's editor's draft will be a better reference than today's. Yet
the W3C TR/REC process makes the snapshot have higher visibility than the
"editor's draft" -- there's required warnings on drafts that say how
they're useless documents that nobody should look at, the w3.org home page
proudly points to obsolete documents like DOM2 Events and HTML4, etc.
This problem also exists (in an even less justifiable form) between
working drafts and editor's drafts, where the W3C site is organised to
give old obsolete working drafts (which really are no more than arbitrary
snapshots of the editors' drafts) more prominence than the editors'
drafts. This is a very real problem; I regularly see people referencing
old known-buggy drafts of HTML5 when implementing the spec. Even the big
warning we have on the spec now hasn't made sufficient impact.
The big warning reads "This is a work in progress! For the latest updates
from the HTML WG, possibly including important bug fixes, please look at
the editor's draft instead. [...]". This is yet another example of
bureaucracy -- what I wanted it to say is "This document is obsolete",
but, despite being true, W3C staff wouldn't agree to putting that message
up, and instead we had to settle on the ineffective message we have now.