Manu Sporny recently published A New Way Forward for HTML5, in which he takes issue with a number of procedural and some technical issues involved in the HTML5 effort. I sincerely believe that Manu's heart is in the right place, but his article contains several erroneous claims that need correcting. His article is long, and contains some good among the bad, so this is more of a drive-by reply to various pieces of it. I start with his list of action items at the article’s end:

1. Implementation of git for distributed source control.
2. Microsection splitter and documentation build system.
3. Recruit more committers into the HTML5 community.
4. Split features based on their experimental nature into unstable and testing during Last Call.
5. Implement in-line feedback mechanism for HTML5 spec.
6. Distributed extensibility proposals for HTML5.
7. Better, more precise accessibility language for HTML5.
8. Merge the HTML WG and WHAT WG communities. This may never happen.

Points 6 (distributed extensibility) and 7 (accessibility) are both difficult to reply to concisely, so I’ll skip them for now. Here’s my crack at the other points in turn. (If you’d like a peek at my take on distributed extensibility (ISSUE-41), I gave a talk at a recent BarCamp about it. Good luck deciphering the slides. Expect a larger blog treatment of the topic this summer.)

1. Implementation of git for distributed source control.

You can already use git with an upstream subversion repository—the HTML WG’s co-chair Sam Ruby has already made such a git clone of the WHATWG webapps repository—so we already have this.

2. Microsection splitter and documentation build system.

In the past, Ian has been very receptive to using tools provided by other community members in the spec build system— Philip Taylor's spec splitter and Sam Sneddon' Anolis are the obvious examples. If you build it, perhaps he’ll come. That said, I tend to agree with Sam that version control systems make the discussion about MicroSections largely a non-issue.

3. Recruit more committers into the HTML5 community.

Ian’s been trying to find willing editors for years and years, without much luck.

4. Split features based on their experimental nature into unstable and testing during Last Call.

This has already happened and will continue to happen. No change here.

5. Implement in-line feedback mechanism for HTML5 spec.

We already had an inline annotation system, and today Ian went ahead and added an inline comment system too.

8. Merge the HTML WG and WHAT WG communities.

Don’t worry so much about there being two similar-but-not-identical groups working on the same thing, mostly made up of the same people. As I’ve pointed out before, it worked for Ireland.

Manu would like me to clarify what [I] mean by “FUD and misinformation”— I claimed on reddit that his article is filled with them. I think the biggest, most egregious misstatement of his article is right near the beginning (emphasis mine):

The single greatest complaint heard from the standards community concerning the development of HTML5 is that it has not allowed for the scientific process. Throughout history, the ability to openly contribute ideas, scrutinize them, and form consensus around those ideas has been shown to produce the most desirable outcomes. HTML5 is currently a walled garden that must be opened to the greater standards community in order to ensure a stable framework for the future of the Web.

David Baron of Mozilla replied:

I strongly disagree with this statement. A key part of a scientific process is that the starting point is evidence. I think the development process of HTML5 gives arguments based on evidence more weight than any other W3C work I’ve been involved in, and has put more effort into gathering relevant evidence than any other W3C work I’ve been involved in. This is a good thing.

http://krijnhoetmer.nl/irc-logs/whatwg/20090723

Manu replied to David

Hrm, that paragraph is problematic, others have had the same reading as you have on it as well, which is not the message that I had intended. Granted, it’s meant to be an introductory paragraph which I spend the rest of the document elaborating on, but perhaps it needs to be revised.

It’s not the ‘gathering of evidence’ that I find problematic - quite the contrary, I think that’s a great way to deal with some these issues and it certainly has helped solve some rather hairy disagreements in this community.

It’s the unevenness in the ability to directly contribute to the specification that is the "walled garden" that I take issue with[…]

Ian is really the only one that is actively allowed to produce anything of significance in WHAT WG. In general, if he doesn’t agree with you, it doesn’t go in.

Peter Kasting, a Google Chrome developer, replied to Manu:

It’s already been stated explicitly multiple times in the past that the HTML5 process is not ultimately consensus-driven, so this shouldn’t be news to anyone. I for one consider that a feature, not a bug.

More from Manu’s reply to David

To put an HTML5+RDFa proposal together, I had to go outside of this community. I think it’s fair to say that one needs to have a pretty significant chunk of time on their hands as well as technical chops to make a contribution to the HTML5 specification.

Peter Kasting:

Incorrect. All sorts of people have made contributions of small corrections, opinions on issues, spec proposals, etc. Ian has publicly committed to reply to every email and so far I see him doing precisely that; frequently this results in spec changes. When people’s opinions are ultimately rejected, it is not without due consideration first.

More from Manu’s reply to David

To understand why this is viewed as an issue, we can look to the Microformats community, which has roughly 1,300 mailing list members. Everyone is able to contribute to the main product of that community: The Microformats wiki. Why isn’t it the same in this community -- a community that prides itself on being open to everyone?

To approach the issue from another angle, we have roughly 1,000 members on this mailing list and could have close to 1 billion people[1] that could be using some form of HTML by 2012, a number of those are web developers (read: a huge developer base).

The Linux kernel mailing lists have close to 30,000 members[2], and I don’t think it’s a stretch to say that there are fewer kernel developers in the world (read: small developer base) than there are web developers and designers. So, I’ve been wondering about the 30:1 discrepancy. Sure, the WHAT WG has been more successful in getting members than HTML WG... but what’s keeping more people from joining?

Peter Kasting:

You’re comparing non-analogous situations. LKML is inherently of interest to all kernel developers, pretty much by definition. The HTML spec creation process is not inherently interesting to all web developers.

A closer analogy would be to the engineers working on HTML support in UAs. I suspect that this mailing list _is_ inherently of interest to that group.

More from Manu’s reply to David

I’m asserting that it has something to do with developers not feeling like they can make a difference. We don’t give anybody the impression here that they could directly impact the specification if they so desired. Our "scientific process" isn’t open for all to participate at every level of the community.

Peter Kasting:

If people sending emails containing proposals, and having the editor directly respond to all of those emails, frequently by changing the spec, does not give you the impression you can impact the specification, I’m not sure what would.

More from Manu’s reply to David

I can git clone the Linux kernel, mess around with it and submit a patch to any number of kernel maintainers. If that patch is rejected, I can still share the changes with others in the community. Using the same tools as everybody else, I can refine the patch until there is a large enough group of people that agree, and implementation feedback to back up the patch, where I may have another chance of resubmitting the patch for re-review. This mechanism is a fundamental part of the community.

Peter Kasting:

Similarly, nothing prevents UA authors from coding any feature they wish and hoping it will gain traction. Similarly, nothing in the HTML5 process prevents anyone from proposing a feature that has been rejected by HTML5, and attempting to convince UA authors to support it directly. To the degree that these don’t happen, it is because practical considerations make success unlikely: it is much more difficult for a random web developer to convince a vendor to support his idea in a particular UA than for a random coder to post a patch online alongside a modified kernel build.

(However, it is not impossible: at least Firefox and Google Chrome can be built, as non-branded versions, from source by any interested party; and in fact that capability has been used for precisely the above purposes: see e.g. Iceweasel.)

More from Manu’s reply to David

I’m going to state that again, because that is the point I’m making here:

The ability to directly affect change at all levels of this community by anybody that chooses to do so should be behavior that we should be supporting, not stifling. The process that we have favors a select few and forces the rest into being casual observers.

1. [16:14] <takkaria> Manu seems to have missed the point as to why people in the whatwg list can’t join the HTMLWG list
2. [16:14] <takkaria> *not all people
3. [16:15] <takkaria> and the idea that merging mailing lists will suddenly make people happy is a bizarre one

1. [16:15] * Quits: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz) (Read error: 54 (Connection reset by peer))
2. [16:18] * Joins: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
3. [16:18] <takkaria> and again with the "HTML5 has no distributed extensibility" meme
4. [16:18] <takkaria> sheesh
5. [16:21] * gsnedders|work reminds himself that replying to that is not a productive use of his time
6. [16:22] <takkaria> a fair bit of that makes some interesting proposals
7. [16:22] <gsnedders|work> Mostly ones that have been made before, though
8. [16:22] <takkaria> but things like "Better, more precise accessibility language for HTML5." do kind of make me want to scream
9. [16:23] <takkaria> and saying that the scientific process is being disregarded whilst also saying experts don’t get to dictate what happend next
10. [16:23] <takkaria> but yeah, responding to this isn’t a good use of time
11. [16:24] * takkaria goes back to work
12. [16:26] <gsnedders|work> I’ll reply to it later, probably
13. [16:26] * gsnedders|work creates a lynx -dump copy of that file to reply to
14. [16:29] * Joins: Lachy (n=Lachlan@85.196.122.246)

1. [16:30] <Lachy> "HTML5 is currently a walled garden that must be opened to the greater standards community in order to ensure a stable framework for the future of the Web." -- http://html5.digitalbazaar.com/a-new-way-forward/
2. [16:31] <Lachy> It’s ironic that HTML5 has the most open development process compared with any previous HTML spec.
3. [16:31] <takkaria> no, see, 1000 people on a mailing list isn’t open enough
4. [16:31] <takkaria> we need to open it to the experts. :)

1. [16:33] * Joins: billmason (n=billmaso@ip144.unival.com)
2. [16:35] <Lachy> "In a CTC process, as used at the W3C, consensus should be reached before an editor changes a document." - we would never get anything done with that process
3. [16:35] * Joins: nessy (n=nessy@203-166-254-27.dyn.iinet.net.au)
4. [16:36] <Lachy> we’d get more criticism from people complaining about how the spec has stalled if we adopted a process like that
5. [16:36] * Quits: harig (n=aparan@59.90.71.35)
6. [16:37] <takkaria> he doesn’t suggest we move to a CTC model
7. [16:38] <takkaria> just that we magic up more committers
8. [16:38] <gsnedders|work> Lachy: Well, we can’t publish until we have consensus, and I think in terms of time taken there’s no difference between getting consensus on changes first and getting consensus after

1. [16:43] <annevk4> the HTML5 editor model is not that weird actually
2. [16:43] <annevk4> the CSS WG and WebApps WG are also using it
3. [16:43] <annevk4> those groups do make group decisions a bit more often than the HTML WG
4. [16:43] <Lachy> "it is difficult to tell which parts of the specification are at which level of maturity without deep knowledge of the history of the document" - Now he’s just blatently ignoring the status markers we’ve had for over a year
5. [16:44] <annevk4> he might be reading the W3C edition
6. [16:44] <Lachy> annevk4, those groups are also smaller and don’t have such large and diverse communities forming around them
7. [16:45] <annevk4> I’m not sure I’d say that about CSS, but the community there has arguably less of a say
8. [16:46] * gsnedders|work wonders why HTML 5 and CSS 3 doesn’t

1. [16:55] <Lachy> "The issue is that there are currently no proposals for distributed extensibility in HTML5 " - now that’s just a blatant lie. He knows full well that the microdata section is in the spec for that. He may not like it as it is, but lying about it not being there doesn’t help

The goal of the actions listed in this document is to allow all of the communities interested in HTML5 to collaborate on the specification in an efficient and agreeable manner. The tools that we elect to use have an effect on the perceived process in place. Currently, the process does not allow for wide-scale collaboration and the sharing and discussion of ideas that support consensus-based specification authoring.

The HTML5 specification currently weighs in at 4.1 megabytes of HTML. If one were to print it out, single-spaced and using 12-point font, the document would span 844 pages. It is not even complete yet and it is already roughly the same length as the new edition of "War and Peace" - a full 3 inches thick.

Reading an 844 page technical specification is daunting for even the most masochistic of standards junkies. The HTML 4.01 specification, problematic in its own right, is 389 pages. Not only are large specifications overwhelming, but it can be almost impossible to find all of the information you need in them. Clearly the specification needs to be long enough to be specific, but not any larger. The issue has more to do with focus and accessibility to web authors and developers than length.

The current HTML5 specification contains information that is of interest to web authors and designers, parser writers, browser manufacturers, HTML rendering engine developers, and CSS developers. Unfortunately, the spec attempts to address all of these audiences at once, quickly losing its focus. A document that is not focused on its intended audience will reduce its utility for all audiences. Therefore, some effort should be placed into making the current document more coherent for each intended audience.

"Know your audience" is a lesson that many creative writers learn far before their first comic, book, or novel is published. Instead of creating a single uber-specification, we should instead split the document into logically targeted sections that are more focused on their intended audience. For example, the following is one such break-out:

Again, David Baron:

Regarding the section "Action: Splitting HTML5 into Logically Targeted Documents", I agree that there is value in splitting the specification. However, I see significant danger in the way you propose to split it: separating the specification of what is available to authors and what should be implemented means the specification risks promising to authors what cannot be implemented, or cannot be implemented at a cost proportionate to the benefit (as HTML4 did in a number of places).

More from Manu’s reply to David

I may have not done a good job of expressing the purpose of microsections. The purpose of microsections would be to create as much language that could be re-used in each document as possible. Take the <progress> element for example:

http://www.whatwg.org/specs/web-apps/current-work/#the-progress-element

Web Developers, in general, don’t care about the "User Agent Requirements" parts of that section, which constitutes almost half of the content for the progress element. That is, they don’t tend to care (in general) about how the browser does what it does. Similarly, people that are creating user agents tend to not care about examples (in general) and would like to know more about the DOM Interface.

Peter Kasting:

Speaking as one of those people, you are completely mistaken. Examples are highly useful to UA authors. And implementation details are occasionally useful to web developers, insofar as they document expected behaviors very precisely and thus are useful when trying to test how real-world UA behaviors differ.

I think the only valid point here is that web developers trying to read the spec directly probably want the "implementation details" as a reference rather than inline.

More from Manu’s reply to David

They would probably rather see examples of how to use the element correctly. So, we have 3 possible microsections:

• progress-element-introduction
• progress-element-ua-requirements
• progress-element-examples

These microsections could be used to generate two separate documents from the same source[…]

The HTML5 specification, to date, has been edited in a way that has enjoyed large success in other open source projects. It uses a development philosophy called Commit-Then-Review (CTR). This is counter to the normal W3C process, called Consensus-Then-Commit (CTC).

In a CTR process, developers make changes to an open source project and commit their changes for review by other developers. If the new changes work better, they are kept. If they don’t work, they are removed. Source control systems such as CVS, Subversion, and Git are heavily relied upon to provide the ability to rewind history and recover lost changes. This process of making additions to a specification can cause an unintended psychological effect; ideas that are already in a specification are granted more weight than those that are not. In the worst case, one may use the fact that text exists to solve a certain problem to squelch arguments for better solutions.

In a CTC process, as used at the W3C, consensus should be reached before an editor changes a document. This approach assumes that it is much harder to remove language than it is to add it. The approach is often painfully slow and it can take weeks to reach consensus on particularly touchy items.

There is nothing wrong with either approach as long as certain presumptions hold. One of the presumptions that CTR makes is that there are many people who may edit a given project. This ensures that good ideas are improved upon, bad ideas are quickly replaced by better ideas, and that no one has the ability to impose his or her views on an entire community without being challenged. However, in HTML5, there is only one person who has editing privileges for the source document. This shifts the power to that individual and requires everyone else in the project to react to changes implemented by that committer.

CTR also requires a community where there is mutual trust among the project leaders and contributors. The HTML5 community is, unfortunately, not in that position yet.

Commit Then Review is a valuable philosophy, but it is dangerous when you only have one committer. Having only one committer creates a barrier to dissenting opinion. It does not allow anyone else to make a lasting impact on the only product of HTML WG and WHAT WG - the HTML5 specification.

It is imperative that more editors are empowered in order to level the playing field for the HTML5 specification. It is also important that edit-wars are prevented by adopting a system that allows for distributed editing and source management.

The Git source control system is one such distributed editing and management solution. It doesn’t require linear development and it is used to develop the Linux kernel - a project dealing with many more changes per day than the HTML5 specification. It allows for separate change sets to be used and, most importantly, there is no one in "control" of the repository at any given point. There is no central authority, no political barrier to entry, and no central gatekeeper preventing someone from working on any part of the specification.

Distributed source control systems are like peer-to-peer networks. They make the playing field flat and are very difficult to censor. The more people that have the power to clone and edit the source repository, the larger the network effects. We would could go from the one editor we have now, to ten editors in a very short time, and perhaps a hundred contributors over the next decade.

There have been three major instances spanning 12-24 months in which expert opinion was not respected during the development of the current HTML5 specification. These instances concerned Scalable Vector Graphics (SVG), Resource Description Framework in Attributes (RDFa), and the Web Accessibility Initiative (WAI).

The situation has received enough attention so that there are now web comics and blogs devoted to the conflict between various web experts and the author of the HTML5 specification. These disagreements have become a spectacle with many experts now refusing to take part in the development of the HTML5 specification citing others’ unsuccessful attempts to convey decades of research to the current editor of the HTML5 specification.

Similarly, the editor of the current specification has many valid reasons not to integrate suggestions into the massive document that is HTML5. However, an imperfection in a particular suggestion does not eliminate the need for a discussion of alternative proposals. The way the problem is being approached, by both sides, is fundamentally flawed.

The HTML5 document should be broken up into smaller sections. Let’s call them microsections. The current specification source is 3.4 megabytes of editable text and is very difficult to author. It is especially daunting to someone who only wants to edit a small section related to their area of expertise. It is even more challenging if one wishes to re-arrange how the sections fit together or to re-use a section in two documents without having to keep them in sync with one another.

Ideally, certain experts, W3C Task Forces, Working Groups, and technology providers could edit the HTML5 specification microsections without having to worry about larger formatting, editing, merging, or layout issues. These microsections could then be processed by a documentation build system into different end-products. For example, HTML5+RDFa or HTML5+RDFa+ARIA, or HTML5+ARIA-RDFa-Microdata. Specifications containing different technologies could be produced very quickly without the overhead of having to author and maintain an entirely new set of documents. You wouldn’t need an editor per proposal to keep all of them in sync with one another, thus reducing the cost of making new proposals. Some microsections could even be used across 2-3 HTML5-related documents.

This approach, coupled with the move to a more decentralized source control mechanism, would provide a path for anyone who can clone a Git repository and edit an HTML file to contribute to the HTML5 specification. Merging changes into the "official" repository could be done via W3C staff contacts to ensure fair treatment to all proposals.

There is language in the HTML5 specification that indicates that different parts of the specification are at different levels of maturity. However, it is difficult to tell which parts of the specification are at which level of maturity without deep knowledge of the history of the document. This needs to change if we are going to start giving the impression of a stable HTML5 specification.

When someone who is not knowledgeable about the arcane history of the HTML5 Editors Draft sees the <datagrid> element in the same document as the <canvas> element, it is difficult for them to discern the level of maturity of each. In other words, canvas is implemented in many browsers while datagrid is not, yet they are outlined in the same document. The HTML5 specification does have a pop-up noting which features are implemented, have test cases, and are marked for removal, however it is difficult to read the document knowing exactly which paragraphs, sentences and features are experimental and which ones are not.

This is not to say that either <datagrid> or <canvas> shouldn’t be in the HTML5 specification. Rather, there should be different HTML5 specification maturity levels and only features that have reached maturity should be placed into a document entering Last Call at the W3C. We should clearly mark what is and isn’t experimental in the HTML5 specification. We should not standardize on any features that don’t have working implementations.

There is much that the standards community can learn from the release processes of larger communities like Debian, Ubuntu, RedHat, the Linux kernel, FreeBSD and others. Each of those communities clearly differentiates software that is very experimental, software that is entering a pre-release testing phase, and software that is tested and intended for public consumption.

If the HTML5 specification generation process adopts Microsections and a distributed source control mechanism, it should be easy to add, remove, and migrate features from an experimental document (Editors Draft), to a testing specification (Working Draft), to a stable specification (Recommendation).

While it may seem as if this is how W3C already operates, note that there is usually only a single stage that is being worked on at a time. This doesn’t fit well with the way HTML5 is being developed in that there are many people working on stable features, testing features, and experimental features simultaneously. A new release process is needed to ensure a smooth, non-disruptive transition from one phase to the next.

When the WHAT WG started what was to become HTML5, the group was asked to do the work outside of the World Wide Web Consortium process. As a benefit of working outside the W3C process, the HTML5 specification was authored and gained support and features very quickly. Letting anyone join the group, having a single editor, dealing directly with the browser manufacturers, and focusing on backwards compatability all resulted in the HTML5 specification as we know it today.

When the W3C and WHAT WG decided to collaborate on HTML5 as the future language of the web, it was decided that work would continue both in the HTML WG and the WHAT WG. People from the WHAT WG joined the HTML WG and vice-versa to show good faith and move towards openly collaborating with one another. At first, it seemed as if things were fine between the two communities. That is, until the emergence of an "us vs. them" undercurrent - both at the W3C and in WHAT WG.

Keeping both communities active was and will continue to be a mistake. Instead of combining mailing lists, source control systems, bug trackers and the variety of other resources controlled by each group, we now operate with duplicates of many of the systems. It is not only confusing, but inefficient to have duplicate resources for a community that is supposed to be working on the same specification. It sends the wrong signal to the public. Why would two communities that are working on the same thing continue to separate themselves from one another unless there was a more fundamental issue that existed?

The communities should be merged slowly. Data should be migrated from each duplicate system and a single system should be selected. The mailing lists should be one of the first things to be merged. If either community feels that the other community isn’t the proper place for a list, then a completely new community should be created that merges everyone into a single, cohesive group.

The two communities should bid on an html5.xyz domain (html5.org, html5.info, html5.us) and consolidate resources. This would not only be more efficient, but also eventually remove the "us vs. them" undercurrent.

In order to contribute bug reports, features, or comments on the HTML5 specification, one must send an e-mail to either the HTML WG or the WHAT WG. The combined HTML5 and WHAT WG mailing list traffic can range from 600 to 1,200 very technical e-mails a month. Asking those who would like to comment on the HTML5 specification to devote a large amount of their time to write and respond to mailing list traffic is a formidable request. So formidable that many choose not to participate in the development of HTML5.

There are many websites that allow people to interactively comment on articles or reply to comments on web pages. We need to ensure that there are as few barriers as possible for commenting on the HTML5 specification. Sending an e-mail to the HTML WG or WHAT WG mailing lists should not be a requirement for providing specification feedback. It should be fairly easy to create a system that allows specification readers to comment directly on text ambiguities, propose alternate solutions, or suggest text deletions when viewing the HTML5 specification.

The down-side to this approach is that there may be a large amount of noise and a small amount of signal but that would be better than no signal at all. We must understand that many web developers, authors, and those who have an interest in the future of the Web cannot put as much time into the HTML5 specification as those who are paid to work on it.

If one were to go to the trouble of adding several new sections into HTML5 or modifying parts of the document, they would then need to keep their changes in sync with the latest version of the document at svn.whatwg.org. This is because there is currently only one person who is allowed to make changes to the "official" HTML5 specification. Keeping documents in sync is time consuming and should not be required of participants in order to affect change.

Since the HTML5 specification document is changed on an almost daily basis, the current approach forces editors to play a perpetual game of catch-up. This results in them spending more time merging changes than contributing to the HTML5 document. It may also cause the feeling that their changes are less important than those further upstream.

As previously mentioned, moving to a microsectioned approach can help in this case as well. There can be a number of alternative microsections that editors may author so that each section can be a drop-in replacement. The document build system could be instructed, via a configuration file, on which microsections to use for a particular output product. Therefore if someone wanted to construct a version of HTML5 with a certain feature X, all that would be required is the authoring of the microsection and an instruction for the documentation build system to generate an alternative specification with the microsection included.

One of the things that will vanish when the XHTML2 Working Group is shut down at the end of this year is the concept that there would be a unified, distributed platform extensibility mechanism for the web. In short, distributed platform extensibility allows for the HTML language to be extended to contain any XML document. Examples of XHTML-based extensibility include embedding SVG, MathML, and a variety of other specialized XML-based markup languages into XHTML documents.

HTML5 is specifically designed not to be extended in a decentralized manner for the non-XML version of the language. It special-cases SVG and MathML into the HTML platform. It also disallows platform extensibility and language extensibility in HTML5 (not XHTML5) using the same restricted rubric when they are clearly different types of extensibility mechanisms.

Many proponents of distributed extensibility are very concerned by this rubric and resulting design decision. At the heart of distributed extensibility is the assertion that anyone should be able to extend HTML in the future to address their markup needs. It is a forward-looking statement that asserts that the current generation cannot know how the world might want to extend HTML. The power should be placed into the hands of web developers so that they may have more tools available to them to solve their particular set of problems.

Whether or not distributed extensibility will ever be used on a large scale is not the issue. The issue is that there are currently no proposals for distributed extensibility in HTML5 (again, not XHTML5). Without a proposal, there is no counter-point for the "no distributed extensibility" assertion that HTML5 makes. Thus, if the W3C were to form consensus at this point, there would be only one option.

Consensus around a single option is not consensus. In the very least, HTML5 needs draft language for distributed extensibility. It doesn’t need to be the same solution as XHTML5 provides, it doesn’t even need to be close, but alternatives should exist. XHTML spent many years solving this problem and because of that, SVG and MathML found a home in XHTML documents. Enabling specialist communities, such as the visual arts and mathematics, to extend HTML to do things that were not conceivable during the early days of the Web is a fundamental pillar of the way the Web operates today.

Similarly, a set of tools to provide data extensibility do not exist in a form that are acceptable to the standards community. These tools are also going to fundamentally shape the way we embed and transfer information in web pages. If we are realistic about the expanse of problems that the Web is being called upon to solve, we should ensure that data extensibility capabilities are provided as we move forward.

We cannot be everything to everyone, we should provide some combination of features like Javascript, embedding XML documents, and RDFa, in both HTML5 and XHTML5 to help web developers solve their own problems without needing to affect change in the HTML5 specification.

More from Manu’s reply to David

Other reviewers of the document had said that as well. Perhaps it is not desirable to talk about it in this discussion (which is about process)... but I thought it should be mentioned (and will be brought up in the coming months). I think that there are enough people that care about it to author some spec language to guarantee that round-tripping between HTML5 and XHTML5 is possible. That is, that xmlns: is preserved in the DOM in HTML5. Although, you’re right, that’s a discussion for another time.

Accessibility is rarely seen as important until one finds oneself in a position where they or a loved one’s vision, hearing, or motor skills do not function at a level that makes it easy to navigate the web. Accessible websites are important not only to those with disabilities, but also to those who cannot interact with a website in a typical fashion. For example, web accessibility is also important when one is on a small form factor device, using a text-only interface, or a sound-based interface.

Members of the Website Accessibility Initiative (WAI) and the creators of The Accessible Rich Internet Applications (ARIA) technical specification have noted on a number of occasions that they feel as if they are being ignored by the HTML5 community.

Empowering WAI to edit the HTML5 specification in a way that does not conflict with others, but produces an accessibility-enhanced HTML5 specification is important to the future of the Web. Microsections and distributed source control would allow this type of collaboration without affecting the speed at which HTML5 is being developed. It may be that WAI needs a specification writer that is capable of producing unambiguous language that will enable browser manufacturers to easily create interoperable implementations.

Again, David Baron:

I think some of the [accessibility] input that has been ignored or has been felt to be ignored is input that is difficult to act on. Specification development ought to work from requirements to solutions rather than straight to solutions. This is done to make sure that the requirements are addressed, to make sure that the specification does not become more complicated than needed to address the requirements, and (most importantly in this case) to avoid unresolvable debates between parties that are emotionally attached to particular technical solutions. I think a number of the arguments that have been ignored (e.g., some of the arguments over @headers or @summary) have been arguments made *in the face of* evidence that the particular technical solutions do not work in practice, and without presenting the requirements that are not addressed by the HTML5 specification’s replacements for those particular (non-functioning) solutions. I think such arguments ought to be ignored, ignoring them is not a problem, and giving those who make them and then complain that they are ignored the power to edit the specification would be a mistake. However, I think HTML5 specification reflects significant consideration for the needs of disabled users, and I strongly encourage more input regarding use cases for and requirements of disabled users that the specification fails to meet.

blah blah blah

More from Manu’s reply to David

I agree with the majority of what you had to say. The issue is that, once again, the WAI community was unaware or felt like they were not being given the opportunity to affect change.

It’s a break down in communication on both sides. WHAT WG has not been clear about what we require, or we haven’t made it clear to WAI. There are at least 8-10 people in WAI that are confused about why they are being repeatedly rejected - perhaps they’re emotionally tied to their solutions, perhaps WHAT WG doesn’t get what they’re trying to accomplish. Those possibilities are beside the point:

There is no easy mechanism for them to edit the specification, and until recently, they were under the general impression that Ian was the gatekeeper for the HTML5 specification.

They should be able to edit /something/ lasting, publish it for review, and rise or fall on the merits and accuracy of their specification language. They are not being given the opportunity to do so.

Peter Kasting:

Anyone can post a proposal anywhere on the web, which they themselves edit. If they want the imprimatur of the WHATWG, then it seems reasonably to expect that that proposal would have to be accepted by the editor(s) of that group.

I’m not sure why there is a perceived lack of clarity here. Rejected proposals are always given concrete rationale for rejection (IMO).