HTML 5 Video

The debate over the <video> tag in HTML 5 is still relevant and much more urgent at this time. We should use this page to compile arguments against the Theora recommendation and present refutations to establish Theora as the ideal solution to meet W3C and international multimedia priorities.

There is an open-access Zotero collection we can use to compile key points and citations from various articles debating about the <video> tag here.

Below are the requirements from the WHATWG Wiki pertaining to editing the spec. Italicized text followed by notation such as "(A)" point to responses below:

Is there a process for removing bad ideas from the spec?

There are several processes by which we trim weeds from the specifications.

• On a regular basis, especially around explicit call-for-comments, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features(A), then they eventually are removed altogether.

• Anyone can ask for a feature to be removed; such feedback is considered like all other feedback and is based on the merits of the arguments put forward(B).

• If browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential of fundamentally wrong or damaging, then, after due consideration, features will be removed(C).

Removing features is a critical part of spec development.

Is there a process for adding new features to the spec?

The process is rather informal, but basically boils down to this:

1. Research the use cases and requirements by discussing the issue with authors and implementors.
2. Come up with a clear description of the problem that needs to be solved.
3. Discuss your proposal with authors and implementors. Read the responses. Listen to the feedback. Consider whether your ideas are good solutions to the use cases and requirements put forward. Discussions here should be done in public, e.g. on an archived public mailing list or documented in blogs.
4. Get implementors to commit to implementing the feature. If you can't get several implementors to implement the feature, then get at least one user agent to implement it experimentally. Experimental implementations should be publicly available.
5. Bring the experimental implementations to the attention of the spec's editor. Document the experience found from any implementations, the use cases and requirements that were found in the first step, the data that the design was based on.
6. Demonstrate the importance of the problem. Demonstrate that the solution is one that will be used correctly and widely enough for it to solve the stated problem.
7. Participate in the subsequent design discussions, considering all the proposals carefully. Typically at this step the original design gets thrown out and a significantly better design is developed, informed by the previous research, new research, and implementation and author experience with experimental implementations. Sometimes, the idea is abandoned at this stage.

If the idea survives the above design process, the spec will be eventually updated to reflect the new design. Implementations will then be updated to reflect the new design (if they aren't, that indicates the new design is not good, and it will be reworked or removed). The spec will be updated to fix the many problems discovered by authors and implementors, over a period of several years, as more authors and implementors are exposed to the design. Eventually, a number of provably interoperable implementations are deployed. At this point development of the feature is somewhat frozen.

Writing a comprehensive test suite is also an important step, which should start a bit before implementations start being written to the spec. (Test suites usually find as many problems with implementations as they do with the spec; they aren't just for finding browser bugs.) We don't yet have a good story with respect to test suites, sadly. If you want to help us out, let the mailing list know! Be aware, though, it's a lot of work.