It’s just data

WHATWG/W3C Collaboration

I’ve been having fun working on the URL Living Standard. The first change I landed was to convert the spec from Anolis to Bikeshed. Here’s the before and after after. And just for fun, here is the beginning on 2014 and beginning of 2013. The point being that arbitrary snapshots of living standards do exist.

Along the way, I’ve been named by my employer’s AC member to be a member of the W3C WebApps Working Group, and invited to become a member of the WHATWG organization on GitHub. I’ve been named as co-editor of the spec in both organizations, and at that point the fun abruptly stopped. Apparently, the larger political issues that I had successfully avoided in the past moved front and center.

Here’s what I said in September:

While I am optimistic that at some point in the future the W3C will feel comfortable referencing stable and consensus driven specifications produced by the WHATWG, it is likely that some changes will be required to one or both organizations for this to occur; meanwhile I encourage the W3C to continue on the path of standardizing a snapshot version of the WHATWG URL specification, and for HTML5 to reference the W3C version of the specification.

Now it is time for me to spell out how I see that happening.

I’ll start out by saying that I continue to want the WebApps WG to follow through on its charter obligation to continue to publish updates to the URL Working Draft. And once updates resume, I want to work on making doing so entirely unnecessary. While this may sound puzzling, there is a method to my madness. I want to establish an environment where an open discussion of this matter can be held without anybody feeling that there are options that are closed to them or that there is a gun to their head.

Next I’ll state an observable fact: there exists people who value the output of the W3C process. The fact that there are people who don’t doesn’t make the first set of people go away or become any less important. Note that I said the output of the W3C process. People who value that don’t necessarily (or even generally) want to observe or participate in the making of the sausage.

What they value instead is regular releases and making the bleeding edge publicly available. And for releases, what they care most about are the items that are covered during a W3C Transition (example). In particular, they are interested in evidence of wide review, evidence that issues have been addressed, evidence that there are implementations, and the IPR commitments that are captured along the way.

Some have (and do) argue that these needs can be met in other ways. Not everybody is convinced of this. I’m not convinced. In particular, the existence of a bugzilla database with numerous bugs closed as WORKS4ME without explanation doesn’t satisfy me.

To date, those needs have intentionally not been met by the WHATWG. And an uneasy arrangement has been created where specs have been republished at the W3C with additional editors listed, in many cases in name only. Those copies were then shepherded through the W3C process. Many are not happy with this process. I personally can live with it, but I’d rather not.

I said that this will require changes by one or both organizations. I will now say that I expect this to require cooperation and changes by both. I’ll start by describing the changes I feel are needed by the WHATWG, of which there are three.

  1. Agree to the production of planned snapshots. And by that I mean byte-for-byte copies. As a part of this that would mean the identification of "items at risk" at early stages of the process, and the potential removal of these items later in the process. These snapshots will need to meet the needs of the W3C, primarily pubrules, and only linking to W3C approved references. Even though it should have to go without saying, apparently it needs to be said: those specs need to be snark free. Finally I'll go further and suggest that those snapshots be hosted by the W3C, much in the way that the W3C hosts WHATWG's bugzilla database and mailing list archives.

  2. Participation in the production of Transition Requests. That would involve providing evidence of wide review and evidence that issues are addressed. It also could include, but doesn't necessary require, direct participation in the transition calls.

  3. Understanding and internalizing the notion that the combination of an open license coupled with begin unwilling or unable to address a perceived need by others is a valid reason for a fork. Yes, I know that the W3C hasn't adopted an open license themselves, and I believe that is wrong too. But that doesn't change the fact that an open license plus an unmet need is sufficient justification for a fork.

I’ll close my discussion on the WHATWG changes I envision with a statement that participation in the W3C process (to the extent described by #1 and #2 above) is optional and will likely be done on a spec by spec basis. Editors of some WHATWG specs may not chose not to participate in this process, and that’s OK, I simply ask that those that don’t recognize the implications of this choice (specifically #3 above).

Responsibility for advancing specs for which the WHATWG editors voluntarily elect to participate in the process would fall to a sponsoring W3C Working Group. Starting to sponsor, ceasing to sponsor, and forking a spec would require explicit W3C Working Group decisions. As a general rule, Working Groups should only consider sponsoring focused, modular specifications.

Here’s what sponsoring would (and most importantly, would not) involve:

  1. No editing. As suggested above, snapshots produced by the WHATWG would be archived, but these archives would be byte-for-byte beyond the changes involved in archiving itself (example: updating stylesheet links to point to captured snapshots of stylesheets). The one possible exception to this would be in the updating of normative references, but this would only be done with the concurrence of the WHATWG editors.

  2. Participation would be limited to the production of Transition Requests. This would include providing evidence of wide review, evidence that issues are formally addressed, recording and reporting of Formal Objections, collecting patent disclosures, etc.

That’s it. Of course, the process will remain the same for documents that are copied and shepherded instead, but I see no reason that WebApps WG couldn't sponsor the WHATWG URL standard through this process, the HTML WG couldn't do the same for the DOM standard, the I18N WG couldn't do the same for the Encoding standard, etc.

While everybody may come into a sponsorship collaboration with the best intentions, we need to realize that things may not always go as planned. There may be disagreements. It has been known to happen. When such occurs:

  1. Everyone involved should work very hard to resolve the dispute as the consequence of breakage is very bad all around.

  2. If no agreement can be reached, the W3C Working Group will likely stop the sponsorship of the specific spec involved in the dispute.

  3. If a Working Group stops sponsoring a spec, the Working Group could still fork that spec - but that would be a suboptimal solution for both W3C and WHATWG. It would also re-inflame the debates between organizations.

  4. Nonetheless, since each organization has different criteria, we must recognize that this could happen; especially for large, broad, complex specs. Accordingly it makes sense for both organizations to continue the trend towards smaller and more modular specifications

I have no idea if others are willing to go along with this, but I hope that this concrete proposal helps anchor this discussion. I invite others that are inclined to do so to suggest revisions or to create proposals of their own. As an example, since the above describes an environment of collaboration and sharing of work, perhaps co-branding may be worth exploring?

This clearly will take time. As an editor of the URL specification, I’d like to propose that it be the first test of this proposal. In the meanwhile, I plan to spend my time coding.

For those that wish to dig further, a few links:


An important objective is to avoid having multiple, different specs which purport to define the same thing, from different organizations.

URL, Encoding, and parts of many others (Origin, MIME types, sniffing), substantial parts of the spec were (at least originally) defined in the IETF. Many other specs (in W3C and IETF both) make normative reference to the IETF document. Leaving the IETF specs alone while defining something different will not meet the goal.

The IETF has no one explicitly working on updating those specs, no ‘activities’, no staff.

So my suggestion is to modify your proposal to make explicit that when the document in question attempts to supplant, redefine, obsolete or otherwise conflict with existing specs, that the W3C / WHATWG collaboration work to also update/obsolete/supplant/modify the IETF specs as well.

I’m not entirely sure how to proceed. I think it will be different for each overlap. Some constraints:

Doing this has quite a bit of overhead, but not doing it seems unacceptable, if I’ve captured the goal.

Posted by Larry Masinter at

Looks like the constraints are missing?  Perhaps my weblog software ate them?

At the moment, I’m focusing primarily on the URL standard.  Perhaps it will be a good model for the rest.  See workmode.

Meanwhile, the URL standard is pretty bold and pretty explicit about having a goal to obsolete the relevant RFCs.

Posted by Sam Ruby at

Good Search Engine

Posted by Google at

This is great for all types of users. We are waiting for this news.

Posted by Bruce David at

Thanks for great article.

Posted by Her şeyin zararları bilgiler at

Our life is shortest, mustn’t porcupine impatience.

Posted by shoes in stock at

So my recommendation is to change your proposition to make unequivocal that when the archive being referred to endeavors to supplant, rethink, out of date or generally struggle with existing specs, that the W3C/WHATWG joint effort work to likewise refresh/out of date/supplant/alter the IETF specs too.

Posted by Buy Dissertation at

I shall be very thankful for the valuable post

Posted by forskolinfuel-reviews at

I shall be very thankful for the valuable post

Posted by forskolinfuel-reviews at

Just a smile and the rain is gone Can hardly believe it, yeah. There’s an angel standing next to me. Reaching for my heart Just a smile and there’s no way back .Can hardly believe it, yeah But there’s an angel calling me. Reaching for my heart I know that I’ll be okay now. This time, it’s real I lay my love on you It’s all I wanna do Every time I breathe I feel brand new You open up my heart Show me all your love and walk right through As I lay my love on you.
dumb ways to die

Posted by fireboy and watergirl 4 at

Deep web sites are something prominent one which you can nevermore guess.  It is hidden and a dark shade of the internet whose list of contents cannot be listed by any existing or additional search engines

Posted by deep web at

Great site and a great topic as well I really get amazed to read this. It’s really good. I like viewing web sites which comprehend the price of delivering the excellent useful resource free of charge. Assignment help | Assignment Expert | Marketing Assignment help | Law Assignment help

Posted by Assignment help at

TV9 Gujarati is a Gujarati language 24-hour news channel. It functions from Ahmadabad city of India’s Gujarat state. Its story satisfied is admired being the only Gujarati news channel
TV9 Gujarati Live News

Posted by TV9 Gujarati Live News at

Add your comment