Skip to content

Instantly share code, notes, and snippets.

@darobin

darobin/kadesh.md

Last active December 2, 2016 07:02
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save darobin/40722d7024e7c3099c37e1478138903e to your computer and use it in GitHub Desktop.
Save darobin/40722d7024e7c3099c37e1478138903e to your computer and use it in GitHub Desktop.
Download ZIP
Old W3C/WHATWG peace proposal
Raw
kadesh.md

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

Usage of this Document

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.

@Hixie
Copy link

Hixie commented Dec 2, 2016

What does that even mean

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment