After 5

“The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.” (Cunningham's Law)

As we approach the point at which HTML5 will become a Recommendation, it is time to think about how HTML would best be handled next.

One thing is certain: it won’t be the way in which it has been handled over the past couple years. The organisation over the period was targeted almost solely at shipping, and therefore largely at cleaning things up on a deadline. But once that stage is reached, no such organisation is needed.

The goal of this document is to propose a small set of basic principles for the organisation of the HTML project after 5.0.

Opening HTML

The idea that Web standards should be open and efforts to make them so have served us well. Over time, however, the ways in which people build the Web have evolved. The ways in which we cooperate have improved. Much that was experimental in open source projects a decade or two ago, and even more that we never foresaw back then, now forms the bedrock of Web development.

The manner in which we create Web standards today lags behind the Web community’s common practices. Web technology is a commons; we need to manage it as such.

There is much to do but examples such as the RICG or the DOM show that it is within reach and tell us of the pitfalls to avoid.

The following principles of openness are to guide the next stages of the HTML specification.

Forkable: A decade or two ago, forking was perceived as a mode of failure. Today, it is a mode of collaboration: Make Forks Not War. In order to enable participation through forking, the specification text in the editors' drafts needs to be under a license that supports this usage. Creative Commons seems like a natural choice. (Note that the editors' drafts may use a CC license but the text published by an SDO afterwards might not be; that's still okay.)
Royalty-Free: The new approach will naturally maintain our ability to ship documents through the W3C Process so as to ensure that the Web remains open for all.
Hackable: A project is only open if it is indeed practicable to participate in it. Having access to the code is not enough, it needs to be possible to genuinely process it, through the usage of sane convention and open tools that are close enough to common developer conventions that they can be picked up easily.

Enabling Hackability

The forkability and royalty-free properties are essentially process issues for which we have existing solutions. As such, they are of little direct interest.

The issue of hackability requires further description though. Beyond the tooling details, which are SMOPs, a better understanding of the goals and approach are useful to have.

To begin making HTML a hackable specification will be to split it up into as many pieces as required. This is not modularisation as was envisaged previously for XHTML. Rather, it is a simple application of the principles at work in software development that make code more maintainable — and therefore more open.

In order to make the split up specification and forks and proposals from the community comprehensible, specifications in progress will be made available together under drafts.webplatform.org, including a master index of all those specifications.

To avoid confusion and stay away from the complexities of W3C documents, the templates used for the split extension specifications will be visually distinct from those that have traditionally been used. (But they will be converted to the regular W3C layout when published there.)

All of the split specifications will be actively seeking forking and pull requests.

Specifications are in many ways similar to software products and an important part of hackability is to support the same best practices in use there to enable maintainability. This includes branching conventions, a distinction between stable features (as demonstrated through testing) and development or topic branches where new proposals are made.

Next Steps

While the focus on openness for this project may come across as more ideological than anything else, it is, at heart, a pragmatic proposal.

Making HTML hackable is a logical part of the Extensible Web Manifesto that we are following. The present barriers to developer participation and our systemic inability to encourage more editors to join are hurting the platform. Encouraging developers who are making use of platform primitives to take the extra step, acquire an understanding of how the platform is defined, and contribute would help address existing and upcoming issues, most likely in a manner that is easier to implement than higher-level primitives.

For example, date inputs are still painfully terrible today despite having been proposed for the longest time. That is one area (amongst many) for which developer-proposed primitives would lead to better results both for authors and implementers. That is precisely what we are planning to encourage.

Starting now and ongoing over the coming weeks:

the first generation of tooling will be made available;
the first split specifications will be put up;
documentation to assist the community will progressively be published;
(possibly) Discourse Specifiction will be move to webplatform.org and become part of the project.

In the meantime, we are listening for input and suggestions, and, of course, reporting issues and submitting pull requests are welcome!