WHATWG Wiki - User contributions [en]

Why not reuse legend

2009-09-17T14:13:34Z

JimJJewett: point to Maciej Stachowiak's summary; explain the problem

Tables and figures should have captions, or at least legends.

Lists sometimes need headers.

The dt element is sometimes a mini-header.

label can be viewed as a mini-header.

Why are there so many similar elements, and why are they not being re-used?

Unfortunately, each of the existing elements has some behavior (in practice, at least) that causes technical problems when trying to reuse them.

[http://lists.w3.org/Archives/Public/public-html/2009Sep/0652.html summary by Maciej Stachowiak]

FAQ

2009-09-17T13:57:23Z

JimJJewett: /* Is design rationale documented? */ link to problems with caption etc

== The WHATWG ==

=== What is the WHATWG? ===

The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.

The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

=== What is the WHATWG working on? ===

The WHATWG's main focus is HTML5. The WHATWG also works on Web Workers and occasionally specifications outside WHATWG space are discussed on the WHATWG mailing list and forwarded when appropriate.

In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] will bring us.

=== How can I get involved? ===

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

=== Is participation free? ===

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C's new HTMLWG] by going through the slightly longer application process.

== The WHATWG Process ==

=== How does the WHATWG work? ===

People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.

This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).

This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.

There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.

Currently the editor is Ian Hickson.

=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===

Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or ian@hixie.ch. All feedback will receive a reply in due course.

If you want feedback to be dealt with faster than "eventually", e.g. because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editor know by either e-mailing him (ian@hixie.ch), or contacting him on [[IRC]] (Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.

Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.

=== Is there a process for removing bad ideas from a specification? ===

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, 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.

* 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.

Removing features is a critical part of spec development.

=== Is there a process for adding new features to a specification? ===

The process is rather informal, but basically boils down to this:
# Research the use cases and requirements by discussing the issue with authors and implementors.
# Come up with a clear description of the problem that needs to be solved.
# 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.
# 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.
# 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.
# 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.
# 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.

== HTML5 ==

=== What is HTML5? ===

[http://www.whatwg.org/specs/web-apps/current-work/ HTML5] is the main focus of the WHATWG community and also that of the W3C HTML Working Group. HTML5 is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML (HTML5) and XML (XHTML5) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

=== How can I keep track of changes to the spec? ===

The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any svn client to check out the latest version and use your clients diff tools in order compare revisions and see what has been changed. You may also use the online [http://html5.org/tools/web-apps-tracker (X)HTML5 Tracking]. The tool provides an online interface for selecting and comparing revisions of the spec.

=== When will HTML5 be finished? ===

"Finished" is a big deal... You'll be able to use HTML5 long before then. See [[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]

It is estimated by the editor that HTML5 will reach the W3C Candidate Recommendation stage during 2012. That doesn't mean you can't start using it yet, though. Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. <canvas>). But other sections are still being actively worked on and changed regularly, or not even written yet.

'''You can see annotations in the margins showing the estimated stability of each section.'''

The possible states are:

* ''Idea; yet to be specified'' -- the section is a placeholder.
* ''First draft'' -- An early stage.
* ''Working draft'' -- An early stage, but more mature than just "first draft".
* ''Last call for comments'' -- The section is nearly done, but there may be feedback still to be processed. Send feedback sooner rather than later, or it might be too late.
* ''Awaiting implementation feedback'' -- The section is basically done, but might change in response to feedback from implementors. Major changes are unlikely past this point unless it is found that the feature, as specified, really doesn't work well.
* ''Implemented and widely deployed'' -- the feature is specified and complete. Once a section is interoperably implemented, it’s quite stable and unlikely to change significantly. Any changes to such a section would most likely only be editorial in nature, particularly if the feature is already in widespread use.

There are also two special states:

* ''Being edited right now'' -- the section is in high flux and is actively being edited. Contact Hixie on [[IRC]] if you have immediate feedback.
* ''Being considered for removal'' -- for one reason or another, the section is being considered for removal. Send feedback soon to help with the decision.

The point to all this is that you shouldn’t place too much weight on the status of the specification as a whole. You need to consider the stability and maturity level of each section individually.

It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004. That's actually not that crazy, though. Work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now.

For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

(In the interests of full disclosure, the W3C's [http://www.w3.org/2007/03/HTML-WG-charter.html#deliverables official line] is that the HTML5 spec will be complete, with interoperable implementations, in late 2010. However, that same timetable gave a date for First Public Working Draft that was eight months premature, and the W3C, as of the predicted date for the third milestone, Candidate Recommendation, had still not come anywhere near reaching the second milestone, Last Call. You can make your own judgements regarding the W3C timetable's credibility.)

=== What about Microsoft and Internet Explorer? ===

Microsoft has already started implementing parts of HTML5 in IE8.

HTML5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

=== Is design rationale documented? ===

Sort of. Often the documentation can be found in the mailing list or IRC channel archives. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification huge.

For a few cases that someone did take the time document, the information can be found at the following locations:

* [[WhyNoNameSpaces]]
* [[WhyNoScriptImplements]]
* [[WhyNotReuseLegend]] -- or another ''mini-header'' element.

Also see HTML5 feature proposals below.

== HTML5 syntax issues ==

=== Will HTML5 finally put an end to the XHTML as <code>text/html</code> debate? ===

Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''

=== What will the DOCTYPE be? ===

In HTML:

<code><!DOCTYPE html></code>

In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.

For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.

<code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>.

Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.

Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code><!DOCTYPE HTML></code> or <code><!doctype html></code>.

These alternatives were chosen because they meet the following criteria:

* They trigger standards mode in all current and all relevant legacy browsers.
* They are well-formed in XML and can appear in XHTML documents.
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.
* The first is short and memorable to encourage its use.
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.

=== Under what conditions should a DOCTYPE be used in XHTML? ===

Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:

# The document is intended to be a polyglot document that may be served as both HTML or XHTML.
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].

=== How are pre-HTML5 documents parsed? ===

All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by HTML5. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax of HTML5 therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed using the HTML5 parser.

Validators are allowed to have different code paths for previous levels of HTML.

=== If there is no DTD, how can I validate my page? ===

With an [http://validator.whatwg.org/ HTML5 validator].

=== What is an HTML Serialization? ===

The HTML serialization refers to the syntax of an HTML document defined in HTML5. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.

Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.

=== What is an XML (or XHTML) Serialization? ===

The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is “html” in the HTML namespace, the document is referred to as an XHTML document.

=== What MIME type does HTML5 use? ===

The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike XHTML1, XHTML5 ''must not'' be served as <code>text/html</code>.

Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.

=== Should I close empty elements with <code>/></code> or <code>></code>? ===

Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code><br /></code>, you only need to write <code><br></code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 to HTML5.

HTML5 also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.

=== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ===

No, HTML and XML have [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|many significant differences]], particularly parsing requirements, and you cannot process one using tools designed for the other. However, since HTML5 is defined in terms of the DOM, in most cases there are both HTML and XHTML serializations available that can represent the same document. There are, however, a few differences explained later that make it impossible to represent some HTML documents accurately as XHTML and vice versa.

If you wish to process an HTML document as XHTML, it requires that you and convert it into XHTML first; and vice versa for processing XHTML as HTML.

=== What is the namespace declaration? ===

In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn’t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].

=== Will there be support for namespaces in HTML? ===

HTML5 is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.

In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.

In conclusion, while HTML5 does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.

=== How do I specify the character encoding? ===

For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:

<meta charset="UTF-8">

The following restrictions apply to character encoding declarations:

* The character encoding name given must be the name of the character encoding used to serialize the file.
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.

Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.

For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".

To ease transition from HTML4 to HTML5, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.

<?xml version="1.0" encoding="UTF-8"?>

Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.

=== What are the differences between HTML and XHTML? ===

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===

Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.

Case sensitivity :
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).
Namespaces:
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)

=== Why does HTML5 legitimise tag soup? ===

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.

For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.

== HTML5 feature proposals ==

=== HTML5 should support <code>href</code> on any element! ===

The spec allows <a> to contain blocks. It doesn't support putting href="" on any element, though.

Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML5. The main reason this isn't in HTML5 is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element and a little script.
* It doesn’t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.

The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.

Wrapping <a> elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:
<pre>
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>
</pre>

=== HTML5 should support list headers! ===

You can give a header to a list using the <figure> and <legend> elements:

<pre>
<figure>
<legend>Apples</legend>
<ul>
<li>Granny Smith</li>
<li>Evil Apple of Knowledge</li>
<li>Apple, Inc</li>
</ul>
</figure>
</pre>

You can also label a group of lists using a definition list:

<pre>
<dl>
<dt>Dry:</dt>
<dd>
<ul>
<li>1c flour</li>
<li>1/4c sugar</li>
<li>1tsp baking soda</li>
</ul>
</dd>
<dt>Wet:</dt>
<dd>
<ul>
<li>1 egg </li>
<li>1/2c milk</li>
<li>1tsp vanilla extract</li>
</ul>
</dd>
</dl>
</pre>

These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near <li> elements.

=== HTML5 should support a way for anyone to invent new elements! ===

There are actually quite a number of ways for people to invent their own extensions to HTML:

* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)

There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.

We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.

=== HTML5 should group <dt>s and <dd>s together in <di>s! ===

This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.

=== Why are some presentational elements like <b>, <i> and <small> still included? ===

The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.

While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.

Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.

Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.

In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.

This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The <b> and <i> Elements]</cite>

Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.

==== But they are PRESENTATIONAL! ====

While <b>, <i> and <small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, <small> corresponds to the really quickly spoken part at the end of radio advertisements. The problem with elements like <font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers).

=== The <cite> element should allow names of people to be marked up ===

From what we've seen, <cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.

So, we can't really decide what the element should be based on past practice, like we usually do.

This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for <cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.

There are already many ways of marking up names already (e.g. the hCard Microformat, the microdata vCard vocabulary, <span> and class names, etc), if you really need it.

=== The <time> element should allow vague times ("March") and times from ancient history to be marked up ===

This has been discussed a number of times. For an overview of the topic, please see these e-mails:
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

Not especially. There are people who for a number of reasons are unable to join the W3C group, and there are others who are unable to join the WHATWG group. The editor is in both groups and takes all input into account -- and there are far more places where input on HTML5 is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc).

=== Which group has authority in the event of a dispute? ===

The editor takes feedback from everyone into account and does not look at the source of those arguments for technical arguments.

=== What is the history of HTML? ===

Here are some documents that detail the history of HTML:
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki]
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#history0 The history section in HTML5 itself]

== Web Workers ==

Besides HTML5 the WHATWG works on [http://www.whatwg.org/specs/web-workers/current-work/ Web Workers]. It does this together with the W3C WebApps Working Group.

== Mailing List ==

=== Should I top-post or reply inline? ===

Please reply inline or make the reply self-contained.

Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.

That is, you should reply like this:

<pre>
Ian wrote:
> What do you want?

I want cats!

> When do you want it?

Now!
</pre>

You should definitely not reply like this (because this requires people to read your e-mail backwards):

<pre class="error" >
No

Ian wrote:
> Is this a good example of how to post e-mails?
</pre>

You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):

<pre class="error" >
This is a bad way to write e-mail.

Ian wrote:
> Is this a good way to write e-mail?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text
</pre>

You should also not reply like this (with no context at all), because the reader will not know what you are referring to:

<pre class="error" >
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.
</pre>

Quote enough original text or provide an introduction yourself.

If you use Outlook or Outlook Express, you can use either [http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook-QuoteFix] or [http://home.in.tum.de/~jain/software/oe-quotefix/ OE-QuoteFix]. These plugins fix several of Outlook's problems with sending properly formatted emails.
H

Why no script implements

2009-09-14T19:02:01Z

JimJJewett: create page

Adding the implements attribute to scripts would allow user agents to recognize the purpose of a script, and not bother to download scripts it already had in cache, or for which it provided a native implementation.

Toby Inkster provided a pretty good argument for including it in http://lists.w3.org/Archives/Public/public-html/2009Sep/0538.html

Simon Pieters provided the more subtle counterargument in http://lists.w3.org/Archives/Public/public-html/2009Sep/0540.html

Basically, the warning about how imprecise and unreliable DOM feature testing can be (
http://dev.w3.org/html5/spec/Overview.html#dom-feature-strings ) would also apply to @implements.

Why no namespaces

2009-09-14T18:52:20Z

JimJJewett: trying to get list right

In most of computer science, namespaces are a wonderful invention and greatly simplify maintenance.

XML namespaces were intended to provide these advantages to markup languages, and they have had some success within XML, perhaps because its draconian error-handling encourages careful use.

Unfortunately, XML namespaces don't work so well in HTML -- in practice, the web is more like a bunch of piles than like a well-organized filing cabinet.

Maciej Stachowiak explained some of the problems very well in
http://lists.w3.org/Archives/Public/public-html/2009Jul/0919.html

An unfairly short summary is that:

Short names like "rdf:" or "foaf:" often work OK, if they are treated as globally unique. But by definition, they aren't globally unique, and they really can't be. In some cases, HTML has opted to define prefixes itself (such as aria-*), but the general XML solution is to use a URL.

Long namespace names, including URLS, are a pain to type, make the code unreadable, and are magnets for cut-and-paste editing which sometimes ends up invalidating the use anyhow.

Why no namespaces

2009-09-14T18:50:00Z

JimJJewett: cleaned up

In most of computer science, namespaces are a wonderful invention and greatly simplify maintenance.

XML namespaces were intended to provide these advantages to markup languages, and they have had some success within XML, perhaps because its draconian error-handling encourages careful use.

Unfortunately, XML namespaces don't work so well in HTML -- in practice, the web is more like a bunch of piles than like a well-organized filing cabinet.

Maciej Stachowiak explained some of the problems very well in
http://lists.w3.org/Archives/Public/public-html/2009Jul/0919.html

An unfairly short summary is that

+ Short names like "rdf:" or "foaf:" often work OK, if they are treated as globally unique. But by definition, they aren't globally unique, and they really can't be. In some cases, HTML has opted to define prefixes itself (such as aria-*), but the general XML solution is to use a URL.

+ Long namespace names, including URLS, are a pain to type, make the code unreadable, and are magnets for cut-and-paste editing which sometimes ends up invalidating the use anyhow.

Why no namespaces

2009-09-14T18:48:51Z

JimJJewett: created page

In most of computer science, namespaces are a wonderful invention, that greatly simplify maintenance.

XML namespaces were intended to provide these advantages to markup languages, and they have had some success within XML, perhaps because its draconian error-handling encourages careful use.

Unfortunately, XML namespaces don't work so well in HTML -- in practice, the web is more like a bunch of piles than like a well-organized filing cabinet.

Maciej Stachowiak explained some of the problems very well in
http://lists.w3.org/Archives/Public/public-html/2009Jul/0919.html

An unfairly short summary is that

(a) Short names like "rdf:" or "foaf:" often work OK, if they are treated as globally unique. But by definition, they aren't globally unique, and they really can't be. In some cases, HTML has opted to define prefixes itself (such as aria-*), but the general XML solution is to use a URL.

(b) Long namespace names, including URLS, are a pain to type, make the code unreadable, and are magnets for cut-and-paste editing which sometimes ends up invalidating the use anyhow.

FAQ

2009-09-14T18:38:22Z

JimJJewett: /* Is there documentation of the reasoning behind various decisions? */ Make the dead links potentially live

== The WHATWG ==

=== What is the WHATWG? ===

The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.

The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

=== What is the WHATWG working on? ===

The WHATWG's main focus is HTML5. The WHATWG also works on Web Workers and occasionally specifications outside WHATWG space are discussed on the WHATWG mailing list and forwarded when appropriate.

In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] will bring us.

=== How can I get involved? ===

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

=== Is participation free? ===

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C's new HTMLWG] by going through the slightly longer application process.

== The WHATWG Process ==

=== How does the WHATWG work? ===

People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.

This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).

This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.

There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.

Currently the editor is Ian Hickson.

=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===

Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or ian@hixie.ch. All feedback will receive a reply in due course.

If you want feedback to be dealt with faster than "eventually", e.g. because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editor know by either e-mailing him (ian@hixie.ch), or contacting him on [[IRC]] (Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.

Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.

=== Is there a process for removing bad ideas from a specification? ===

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, 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.

* 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.

Removing features is a critical part of spec development.

=== Is there a process for adding new features to a specification? ===

The process is rather informal, but basically boils down to this:
# Research the use cases and requirements by discussing the issue with authors and implementors.
# Come up with a clear description of the problem that needs to be solved.
# 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.
# 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.
# 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.
# 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.
# 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.

== HTML5 ==

=== What is HTML5? ===

[http://www.whatwg.org/specs/web-apps/current-work/ HTML5] is the main focus of the WHATWG community and also that of the W3C HTML Working Group. HTML5 is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML (HTML5) and XML (XHTML5) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

=== How can I keep track of changes to the spec? ===

The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any svn client to check out the latest version and use your clients diff tools in order compare revisions and see what has been changed. You may also use the online [http://html5.org/tools/web-apps-tracker (X)HTML5 Tracking]. The tool provides an online interface for selecting and comparing revisions of the spec.

=== When will HTML5 be finished? ===

"Finished" is a big deal... You'll be able to use HTML5 long before then. See [[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]

It is estimated by the editor that HTML5 will reach the W3C Candidate Recommendation stage during 2012. That doesn't mean you can't start using it yet, though. Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. <canvas>). But other sections are still being actively worked on and changed regularly, or not even written yet.

'''You can see annotations in the margins showing the estimated stability of each section.'''

The possible states are:

* ''Idea; yet to be specified'' -- the section is a placeholder.
* ''First draft'' -- An early stage.
* ''Working draft'' -- An early stage, but more mature than just "first draft".
* ''Last call for comments'' -- The section is nearly done, but there may be feedback still to be processed. Send feedback sooner rather than later, or it might be too late.
* ''Awaiting implementation feedback'' -- The section is basically done, but might change in response to feedback from implementors. Major changes are unlikely past this point unless it is found that the feature, as specified, really doesn't work well.
* ''Implemented and widely deployed'' -- the feature is specified and complete. Once a section is interoperably implemented, it’s quite stable and unlikely to change significantly. Any changes to such a section would most likely only be editorial in nature, particularly if the feature is already in widespread use.

There are also two special states:

* ''Being edited right now'' -- the section is in high flux and is actively being edited. Contact Hixie on [[IRC]] if you have immediate feedback.
* ''Being considered for removal'' -- for one reason or another, the section is being considered for removal. Send feedback soon to help with the decision.

The point to all this is that you shouldn’t place too much weight on the status of the specification as a whole. You need to consider the stability and maturity level of each section individually.

It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004. That's actually not that crazy, though. Work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now.

For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

(In the interests of full disclosure, the W3C's [http://www.w3.org/2007/03/HTML-WG-charter.html#deliverables official line] is that the HTML5 spec will be complete, with interoperable implementations, in late 2010. However, that same timetable gave a date for First Public Working Draft that was eight months premature, and the W3C, as of the predicted date for the third milestone, Candidate Recommendation, had still not come anywhere near reaching the second milestone, Last Call. You can make your own judgements regarding the W3C timetable's credibility.)

=== What about Microsoft and Internet Explorer? ===

Microsoft has already started implementing parts of HTML5 in IE8.

HTML5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

== HTML5 syntax issues ==

=== Will HTML5 finally put an end to the XHTML as <code>text/html</code> debate? ===

Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''

=== What will the DOCTYPE be? ===

In HTML:

<code><!DOCTYPE html></code>

In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.

For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.

<code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>.

Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.

Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code><!DOCTYPE HTML></code> or <code><!doctype html></code>.

These alternatives were chosen because they meet the following criteria:

* They trigger standards mode in all current and all relevant legacy browsers.
* They are well-formed in XML and can appear in XHTML documents.
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.
* The first is short and memorable to encourage its use.
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.

=== Under what conditions should a DOCTYPE be used in XHTML? ===

Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:

# The document is intended to be a polyglot document that may be served as both HTML or XHTML.
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].

=== How are pre-HTML5 documents parsed? ===

All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by HTML5. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax of HTML5 therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed using the HTML5 parser.

Validators are allowed to have different code paths for previous levels of HTML.

=== If there is no DTD, how can I validate my page? ===

With an [http://validator.whatwg.org/ HTML5 validator].

=== What is an HTML Serialization? ===

The HTML serialization refers to the syntax of an HTML document defined in HTML5. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.

Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.

=== What is an XML (or XHTML) Serialization? ===

The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is “html” in the HTML namespace, the document is referred to as an XHTML document.

=== What MIME type does HTML5 use? ===

The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike XHTML1, XHTML5 ''must not'' be served as <code>text/html</code>.

Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.

=== Should I close empty elements with <code>/></code> or <code>></code>? ===

Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code><br /></code>, you only need to write <code><br></code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 to HTML5.

HTML5 also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.

=== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ===

No, HTML and XML have [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|many significant differences]], particularly parsing requirements, and you cannot process one using tools designed for the other. However, since HTML5 is defined in terms of the DOM, in most cases there are both HTML and XHTML serializations available that can represent the same document. There are, however, a few differences explained later that make it impossible to represent some HTML documents accurately as XHTML and vice versa.

If you wish to process an HTML document as XHTML, it requires that you and convert it into XHTML first; and vice versa for processing XHTML as HTML.

=== What is the namespace declaration? ===

In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn’t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].

=== Will there be support for namespaces in HTML? ===

HTML5 is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.

In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.

In conclusion, while HTML5 does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.

=== How do I specify the character encoding? ===

For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:

<meta charset="UTF-8">

The following restrictions apply to character encoding declarations:

* The character encoding name given must be the name of the character encoding used to serialize the file.
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.

Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.

For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".

To ease transition from HTML4 to HTML5, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.

<?xml version="1.0" encoding="UTF-8"?>

Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.

=== What are the differences between HTML and XHTML? ===

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===

Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.

Case sensitivity :
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).
Namespaces:
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)

=== Why does HTML5 legitimise tag soup? ===

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.

For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.

== HTML5 feature proposals ==

=== HTML5 should support <code>href</code> on any element! ===

The spec allows <a> to contain blocks. It doesn't support putting href="" on any element, though.

Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML5. The main reason this isn't in HTML5 is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element and a little script.
* It doesn’t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.

The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.

Wrapping <a> elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:
<pre>
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>
</pre>

=== HTML5 should support list headers! ===

You can give a header to a list using the <figure> and <legend> elements:

<pre>
<figure>
<legend>Apples</legend>
<ul>
<li>Granny Smith</li>
<li>Evil Apple of Knowledge</li>
<li>Apple, Inc</li>
</ul>
</figure>
</pre>

You can also label a group of lists using a definition list:

<pre>
<dl>
<dt>Dry:</dt>
<dd>
<ul>
<li>1c flour</li>
<li>1/4c sugar</li>
<li>1tsp baking soda</li>
</ul>
</dd>
<dt>Wet:</dt>
<dd>
<ul>
<li>1 egg </li>
<li>1/2c milk</li>
<li>1tsp vanilla extract</li>
</ul>
</dd>
</dl>
</pre>

These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near <li> elements.

=== HTML5 should support a way for anyone to invent new elements! ===

There are actually quite a number of ways for people to invent their own extensions to HTML:

* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)

There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.

We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.

=== HTML5 should group <dt>s and <dd>s together in <di>s! ===

This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.

=== Why are some presentational elements like <b>, <i> and <small> still included? ===

The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.

While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.

Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.

Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.

In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.

This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The <b> and <i> Elements]</cite>

Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.

==== But they are PRESENTATIONAL! ====

While <b>, <i> and <small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, <small> corresponds to the really quickly spoken part at the end of radio advertisements. The problem with elements like <font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers).

=== The <cite> element should allow names of people to be marked up ===

From what we've seen, <cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.

So, we can't really decide what the element should be based on past practice, like we usually do.

This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for <cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.

There are already many ways of marking up names already (e.g. the hCard Microformat, the microdata vCard vocabulary, <span> and class names, etc), if you really need it.

=== The <time> element should allow vague times ("March") and times from ancient history to be marked up ===

This has been discussed a number of times. For an overview of the topic, please see these e-mails:
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.

== Is there documentation of the reasoning behind various decisions? ==

Sort of. Often the only documentation is the archive of the mailing list or IRC channel at the time. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification even larger.

For a few cases that someone did take the time document, the information can be found at the following locations.

[[WhyNoNameSpaces]]

[[WhyNoScriptImplements]]

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

Not especially. There are people who for a number of reasons are unable to join the W3C group, and there are others who are unable to join the WHATWG group. The editor is in both groups and takes all input into account -- and there are far more places where input on HTML5 is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc).

=== Which group has authority in the event of a dispute? ===

The editor takes feedback from everyone into account and does not look at the source of those arguments for technical arguments.

=== What is the history of HTML? ===

Here are some documents that detail the history of HTML:
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki]
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#history0 The history section in HTML5 itself]

== Web Workers ==

Besides HTML5 the WHATWG works on [http://www.whatwg.org/specs/web-workers/current-work/ Web Workers]. It does this together with the W3C WebApps Working Group.

== Mailing List ==

=== Should I top-post or reply inline? ===

Please reply inline or make the reply self-contained.

Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.

That is, you should reply like this:

<pre>
Ian wrote:
> What do you want?

I want cats!

> When do you want it?

Now!
</pre>

You should definitely not reply like this (because this requires people to read your e-mail backwards):

<pre class="error" >
No

Ian wrote:
> Is this a good example of how to post e-mails?
</pre>

You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):

<pre class="error" >
This is a bad way to write e-mail.

Ian wrote:
> Is this a good way to write e-mail?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text
</pre>

You should also not reply like this (with no context at all), because the reader will not know what you are referring to:

<pre class="error" >
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.
</pre>

Quote enough original text or provide an introduction yourself.

If you use Outlook or Outlook Express, you can use either [http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook-QuoteFix] or [http://home.in.tum.de/~jain/software/oe-quotefix/ OE-QuoteFix]. These plugins fix several of Outlook's problems with sending properly formatted emails.
H

FAQ

2009-09-14T18:35:47Z

JimJJewett: Added section on why decisions were made

== The WHATWG ==

=== What is the WHATWG? ===

The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.

The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

=== What is the WHATWG working on? ===

The WHATWG's main focus is HTML5. The WHATWG also works on Web Workers and occasionally specifications outside WHATWG space are discussed on the WHATWG mailing list and forwarded when appropriate.

In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] will bring us.

=== How can I get involved? ===

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

=== Is participation free? ===

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C's new HTMLWG] by going through the slightly longer application process.

== The WHATWG Process ==

=== How does the WHATWG work? ===

People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.

This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).

This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.

There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.

Currently the editor is Ian Hickson.

=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===

Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or ian@hixie.ch. All feedback will receive a reply in due course.

If you want feedback to be dealt with faster than "eventually", e.g. because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editor know by either e-mailing him (ian@hixie.ch), or contacting him on [[IRC]] (Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.

Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.

=== Is there a process for removing bad ideas from a specification? ===

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, 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.

* 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.

Removing features is a critical part of spec development.

=== Is there a process for adding new features to a specification? ===

The process is rather informal, but basically boils down to this:
# Research the use cases and requirements by discussing the issue with authors and implementors.
# Come up with a clear description of the problem that needs to be solved.
# 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.
# 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.
# 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.
# 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.
# 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.

== HTML5 ==

=== What is HTML5? ===

[http://www.whatwg.org/specs/web-apps/current-work/ HTML5] is the main focus of the WHATWG community and also that of the W3C HTML Working Group. HTML5 is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML (HTML5) and XML (XHTML5) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

=== How can I keep track of changes to the spec? ===

The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any svn client to check out the latest version and use your clients diff tools in order compare revisions and see what has been changed. You may also use the online [http://html5.org/tools/web-apps-tracker (X)HTML5 Tracking]. The tool provides an online interface for selecting and comparing revisions of the spec.

=== When will HTML5 be finished? ===

"Finished" is a big deal... You'll be able to use HTML5 long before then. See [[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]

It is estimated by the editor that HTML5 will reach the W3C Candidate Recommendation stage during 2012. That doesn't mean you can't start using it yet, though. Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. <canvas>). But other sections are still being actively worked on and changed regularly, or not even written yet.

'''You can see annotations in the margins showing the estimated stability of each section.'''

The possible states are:

* ''Idea; yet to be specified'' -- the section is a placeholder.
* ''First draft'' -- An early stage.
* ''Working draft'' -- An early stage, but more mature than just "first draft".
* ''Last call for comments'' -- The section is nearly done, but there may be feedback still to be processed. Send feedback sooner rather than later, or it might be too late.
* ''Awaiting implementation feedback'' -- The section is basically done, but might change in response to feedback from implementors. Major changes are unlikely past this point unless it is found that the feature, as specified, really doesn't work well.
* ''Implemented and widely deployed'' -- the feature is specified and complete. Once a section is interoperably implemented, it’s quite stable and unlikely to change significantly. Any changes to such a section would most likely only be editorial in nature, particularly if the feature is already in widespread use.

There are also two special states:

* ''Being edited right now'' -- the section is in high flux and is actively being edited. Contact Hixie on [[IRC]] if you have immediate feedback.
* ''Being considered for removal'' -- for one reason or another, the section is being considered for removal. Send feedback soon to help with the decision.

The point to all this is that you shouldn’t place too much weight on the status of the specification as a whole. You need to consider the stability and maturity level of each section individually.

It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004. That's actually not that crazy, though. Work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now.

For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

(In the interests of full disclosure, the W3C's [http://www.w3.org/2007/03/HTML-WG-charter.html#deliverables official line] is that the HTML5 spec will be complete, with interoperable implementations, in late 2010. However, that same timetable gave a date for First Public Working Draft that was eight months premature, and the W3C, as of the predicted date for the third milestone, Candidate Recommendation, had still not come anywhere near reaching the second milestone, Last Call. You can make your own judgements regarding the W3C timetable's credibility.)

=== What about Microsoft and Internet Explorer? ===

Microsoft has already started implementing parts of HTML5 in IE8.

HTML5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

== HTML5 syntax issues ==

=== Will HTML5 finally put an end to the XHTML as <code>text/html</code> debate? ===

Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''

=== What will the DOCTYPE be? ===

In HTML:

<code><!DOCTYPE html></code>

In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.

For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.

<code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>.

Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.

Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code><!DOCTYPE HTML></code> or <code><!doctype html></code>.

These alternatives were chosen because they meet the following criteria:

* They trigger standards mode in all current and all relevant legacy browsers.
* They are well-formed in XML and can appear in XHTML documents.
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.
* The first is short and memorable to encourage its use.
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.

=== Under what conditions should a DOCTYPE be used in XHTML? ===

Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:

# The document is intended to be a polyglot document that may be served as both HTML or XHTML.
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].

=== How are pre-HTML5 documents parsed? ===

All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by HTML5. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax of HTML5 therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed using the HTML5 parser.

Validators are allowed to have different code paths for previous levels of HTML.

=== If there is no DTD, how can I validate my page? ===

With an [http://validator.whatwg.org/ HTML5 validator].

=== What is an HTML Serialization? ===

The HTML serialization refers to the syntax of an HTML document defined in HTML5. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.

Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.

=== What is an XML (or XHTML) Serialization? ===

The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is “html” in the HTML namespace, the document is referred to as an XHTML document.

=== What MIME type does HTML5 use? ===

The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike XHTML1, XHTML5 ''must not'' be served as <code>text/html</code>.

Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.

=== Should I close empty elements with <code>/></code> or <code>></code>? ===

Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code><br /></code>, you only need to write <code><br></code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 to HTML5.

HTML5 also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.

=== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ===

No, HTML and XML have [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|many significant differences]], particularly parsing requirements, and you cannot process one using tools designed for the other. However, since HTML5 is defined in terms of the DOM, in most cases there are both HTML and XHTML serializations available that can represent the same document. There are, however, a few differences explained later that make it impossible to represent some HTML documents accurately as XHTML and vice versa.

If you wish to process an HTML document as XHTML, it requires that you and convert it into XHTML first; and vice versa for processing XHTML as HTML.

=== What is the namespace declaration? ===

In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn’t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].

=== Will there be support for namespaces in HTML? ===

HTML5 is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.

In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.

In conclusion, while HTML5 does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.

=== How do I specify the character encoding? ===

For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:

<meta charset="UTF-8">

The following restrictions apply to character encoding declarations:

* The character encoding name given must be the name of the character encoding used to serialize the file.
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.

Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.

For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".

To ease transition from HTML4 to HTML5, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.

<?xml version="1.0" encoding="UTF-8"?>

Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.

=== What are the differences between HTML and XHTML? ===

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===

Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.

Case sensitivity :
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).
Namespaces:
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)

=== Why does HTML5 legitimise tag soup? ===

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.

For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.

== HTML5 feature proposals ==

=== HTML5 should support <code>href</code> on any element! ===

The spec allows <a> to contain blocks. It doesn't support putting href="" on any element, though.

Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML5. The main reason this isn't in HTML5 is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element and a little script.
* It doesn’t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.

The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.

Wrapping <a> elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:
<pre>
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>
</pre>

=== HTML5 should support list headers! ===

You can give a header to a list using the <figure> and <legend> elements:

<pre>
<figure>
<legend>Apples</legend>
<ul>
<li>Granny Smith</li>
<li>Evil Apple of Knowledge</li>
<li>Apple, Inc</li>
</ul>
</figure>
</pre>

You can also label a group of lists using a definition list:

<pre>
<dl>
<dt>Dry:</dt>
<dd>
<ul>
<li>1c flour</li>
<li>1/4c sugar</li>
<li>1tsp baking soda</li>
</ul>
</dd>
<dt>Wet:</dt>
<dd>
<ul>
<li>1 egg </li>
<li>1/2c milk</li>
<li>1tsp vanilla extract</li>
</ul>
</dd>
</dl>
</pre>

These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near <li> elements.

=== HTML5 should support a way for anyone to invent new elements! ===

There are actually quite a number of ways for people to invent their own extensions to HTML:

* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)

There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.

We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.

=== HTML5 should group <dt>s and <dd>s together in <di>s! ===

This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.

=== Why are some presentational elements like <b>, <i> and <small> still included? ===

The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.

While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.

Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.

Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.

In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.

This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The <b> and <i> Elements]</cite>

Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.

==== But they are PRESENTATIONAL! ====

While <b>, <i> and <small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, <small> corresponds to the really quickly spoken part at the end of radio advertisements. The problem with elements like <font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers).

=== The <cite> element should allow names of people to be marked up ===

From what we've seen, <cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.

So, we can't really decide what the element should be based on past practice, like we usually do.

This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for <cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.

There are already many ways of marking up names already (e.g. the hCard Microformat, the microdata vCard vocabulary, <span> and class names, etc), if you really need it.

=== The <time> element should allow vague times ("March") and times from ancient history to be marked up ===

This has been discussed a number of times. For an overview of the topic, please see these e-mails:
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.

== Is there documentation of the reasoning behind various decisions? ==

Sort of. Often the only documentation is the archive of the mailing list or IRC channel at the time. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification even larger.

For a few cases that someone did take the time document, the information can be found at the following locations.

[WhyNoNameSpaces]

[WhyNoScriptImplements]

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

Not especially. There are people who for a number of reasons are unable to join the W3C group, and there are others who are unable to join the WHATWG group. The editor is in both groups and takes all input into account -- and there are far more places where input on HTML5 is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc).

=== Which group has authority in the event of a dispute? ===

The editor takes feedback from everyone into account and does not look at the source of those arguments for technical arguments.

=== What is the history of HTML? ===

Here are some documents that detail the history of HTML:
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki]
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#history0 The history section in HTML5 itself]

== Web Workers ==

Besides HTML5 the WHATWG works on [http://www.whatwg.org/specs/web-workers/current-work/ Web Workers]. It does this together with the W3C WebApps Working Group.

== Mailing List ==

=== Should I top-post or reply inline? ===

Please reply inline or make the reply self-contained.

Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.

That is, you should reply like this:

<pre>
Ian wrote:
> What do you want?

I want cats!

> When do you want it?

Now!
</pre>

You should definitely not reply like this (because this requires people to read your e-mail backwards):

<pre class="error" >
No

Ian wrote:
> Is this a good example of how to post e-mails?
</pre>

You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):

<pre class="error" >
This is a bad way to write e-mail.

Ian wrote:
> Is this a good way to write e-mail?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text
</pre>

You should also not reply like this (with no context at all), because the reader will not know what you are referring to:

<pre class="error" >
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.
</pre>

Quote enough original text or provide an introduction yourself.

If you use Outlook or Outlook Express, you can use either [http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook-QuoteFix] or [http://home.in.tum.de/~jain/software/oe-quotefix/ OE-QuoteFix]. These plugins fix several of Outlook's problems with sending properly formatted emails.
H

Video accessibility

2008-09-11T02:37:53Z

JimJJewett: /* Accessibility Use Cases */

There appears to be consensus among the [http://wcagsamurai.org/errata/errata.html WCAG Samurai] and [http://www.w3.org/TR/WCAG20/#media-equiv the current WGAC 2.0 draft] that the primary ways of making video with soundtrack accessible are to provide captioning for the deaf and audio description for the blind. (The WCAG 2.0 draft also mentions full-text alternative as an alternative to audio description.)

Presumably, the captioning and audio description need to be “closed” (off-by-default, available on request) as content providers might hesitate presenting captions to those who do hear the soundtrack or audio description to those who already see the video track.

==Closed Captioning==

Technically this is timed text presented in sync with the video track.

It is assumed to be in the same language as the main soundtrack. Content-wise, it is expected to mention semantically important non-verbal sounds and identify speakers when the video doesn't make it clear who is talking.

In terms of player app decisions, this track shouldn't be presented by default but it should play if the user has opted in (perhaps via a permanent setting) to showing captioning. Also, if the player app knows that audio output has been turned off either in the app or in the OS, it might make sense to turn on captioning in that case as well.

===Video Format Support===

====Ogg====

CMML has been put forward as the timed text format for Ogg. (How to mark as ''closed'' captions?)

====MP4====

3GPP Timed Text aka. MPEG-4 part 17 is the timed text format for MP4. (How to mark as ''closed'' captions?)

==Closed Audio Description==

Technically this is a second sound track presented in sync with the main sound track.

It is assumed to be in the same language as the main soundtrack.

In terms of player app decisions, this track shouldn't be presented by default but it should play if the user has opted in (perhaps via a permanent setting) to playing audio descriptions. Also, if the player app knows that a screen reader is in use, it might make sense to use that as a cue of turning on audio descriptions.

===Video Format Support===

====Ogg====

How to flag a second sound track (Speex?) as ''closed'' audio description?

====MP4====

How to flag a second sound track as ''closed'' audio description?

==Data Placement in the Web Context==

Should the above-mentioned tracks be muxed into the main video file (Pro: all tracks travel together; Con: off-by-default tracks take bandwidth)? Or should they be separate HTTP resources (Pro: bandwidth optimization; Con: Web-specific content assembly from many files may not survive downloading to disk, etc.) Also note that separate files makes it easier for a 3rd party to add tracks -- but these tracks may be commentary rather than captions, so this is both a pro and a con.

==Related Non-Accessibility Features==

There are technically similar non-accessibility (i.e. not related to addressing needs arising from a disability) features related to translation.

===Translation Subtitles===

A site in language A might want to embed a video with the soundtrack in language B but subtitles in language A. For example, a Finnish-language site embedding an English-language video would want to have Finnish subtitles. Unlike captions, these subtitles should be on by default and being able to suppress the subtitles is considered an additional nice-to-have feature.

There are also same-language subtitles (e.g. French subtitles with French-language soundtrack) for language learners. Unlike captions, same-language subtitles don't inform the reader about non-verbal sounds or identify speakers.

Subtitles need different track metadata so that they can be displayed by default. (Due to concerns about the reliability of subtitling technology, many content providers probably opt to burn the subtitles into the video track as part of the image data, even though this disturbs video compression.)

===Alternative Dubbed Sound Tracks===

Due to bandwidth concerns, Web content providers will probably opt to provide separate video files for dubbed languages.

==Selection Mechanisms==

These use cases are broken into two categories: Acessibility, and the broader Universality. Due to their nature and similarity to real accessibility use cases, it is sometimes useful to consider possible solutions to accessibility in the context of the more general universality issues as well.

===Accessibility Use Cases===

====Deaf or Hearing Impaired User Viewing a Video====

A user who is unable to hear due to physical disability chooses to watch a video. The video is an interview between 2 people, discussing a topic that the user is interested in. The video has been provided with associated closed captions and the user would like to have those turned on so that he may understand speech and other significant sounds within the video.

====A Blind User Listening to a Video's Soundtrack====

A blind user cannot see the video, but is still able to hear the audio, chooses to listen to the sound track of a video anyway. The video is a "webisode" (A web episode - like a TV episode, but on the web) of a drama series the user enjoys watching. The video conveys some important information visually in the video, which is not made apparent in the main sound track, such as what the characters are doing and where they are. But the video also contains an alternative or complimentary track for audio descriptions, which describes significant parts of the video. The user wishes to enable the audio descriptions to more easily comprehend the content of the video.

There are two varations of this use case:

# The computer that the user is using is primarily meant for his own use, and generally not shared with other non-disabled users, and it would be convenient if this was not required to be a manual selection each time.
# The computer is shared between the disabled user and other non-disabled people. The accessibility features used by the disabled user are turned when used by others, and it would be inconvenient if the audio descriptions were automatically selected for them too.

====A Deaf and Blind User is Unable to See or Hear the Video====

A deaf and blind user cannot see or hear the video, and primarily accesses content using a braille reader. The video is a tutorial and demonstration about how to perform a particular science experiment at home. The user wishes to understand the content of the video so that he can teach the experiment to his nephew. The user needs to read the full text description, which describes and transcribes significant aural and visual content in the video. He does not need the video to be loaded, but instead needs to be provided with easy access to the full text description.

====Author Embedding Third-Party Media, but Attempting to Keep the Web Page Accessible====

From the perspective of the end user, this could be any of the other use cases. The reason to call this case out separately is that there needs to be a way for a web page author to provide accessibility and/or fallback information even when the referenced media itself cannot be modified.

===Related Universality Use Cases===

====Sound Equipment is Unavailable, Muted, or has Low Volume====

A user who is unable to hear the audio in the video well because his computer lacks audio equipment, such as a sound card, headphones or speakers; or because the volume needs to be kept down low in the user's environment. The video has been provided with either closed captions or same-language subtitles. Similarly to a hearing impaired user, the user would like to have the ability to turn on captions or subtitles so they may more easily understand what is being said.

====A User Wants to Access a Transcript====

A user chooses not to watch a video, regardless of whether or not they are physically able. The video is of an election campaign speech and has been published with a transcript of the speech alongside. The user wishes to thoroughly review the speech and compare it with those from the other candidates. He accesses the transcript and prints it out, to enable him to read it and make notes or highlight important sections.

====A non-disabled user wants to read a full text description====

A video of a slide presentation has been published, but the user wishes to read the full text description instead. The description includes both a transcript of what the presenter said and images of the slides. The user chooses to read all or part of the full text description, instead of watching the whole video.

===Problems===

# A user who is deaf or hearing impaired needs a way to express his preference for captioning so that he is not required to manually enable them each time.
# A user without sound equipment on a particular device may also wish to express the preference for captioning to avoid manual selection each time.
# A user who is only temporarily unable to hear the audio due to low or muted volume needs a way to manually enable closed captions or same-language subtitle tracks on a per-video basis, if raising the volume is not practical.
# A blind user needs a way to express his preference for audio descriptions so that he is not required to manually select the descriptions each time.
# A user needs to have a way to manually enable or disable an alternative or complimentary audio track containing audio descriptions.
# A user, regardless of disability, needs a way to access a video transcript or full text description.
# A user needs a way to prevent their browser from automatically downloading video that they don't want or need.

===Proposed Solutions===

(to be completed)

Video accessibility

2008-09-11T02:30:00Z

JimJJewett: /* A Blind User Listing to a Video's Soundtrack */ typo

There appears to be consensus among the [http://wcagsamurai.org/errata/errata.html WCAG Samurai] and [http://www.w3.org/TR/WCAG20/#media-equiv the current WGAC 2.0 draft] that the primary ways of making video with soundtrack accessible are to provide captioning for the deaf and audio description for the blind. (The WCAG 2.0 draft also mentions full-text alternative as an alternative to audio description.)

Presumably, the captioning and audio description need to be “closed” (off-by-default, available on request) as content providers might hesitate presenting captions to those who do hear the soundtrack or audio description to those who already see the video track.

==Closed Captioning==

Technically this is timed text presented in sync with the video track.

It is assumed to be in the same language as the main soundtrack. Content-wise, it is expected to mention semantically important non-verbal sounds and identify speakers when the video doesn't make it clear who is talking.

In terms of player app decisions, this track shouldn't be presented by default but it should play if the user has opted in (perhaps via a permanent setting) to showing captioning. Also, if the player app knows that audio output has been turned off either in the app or in the OS, it might make sense to turn on captioning in that case as well.

===Video Format Support===

====Ogg====

CMML has been put forward as the timed text format for Ogg. (How to mark as ''closed'' captions?)

====MP4====

3GPP Timed Text aka. MPEG-4 part 17 is the timed text format for MP4. (How to mark as ''closed'' captions?)

==Closed Audio Description==

Technically this is a second sound track presented in sync with the main sound track.

It is assumed to be in the same language as the main soundtrack.

In terms of player app decisions, this track shouldn't be presented by default but it should play if the user has opted in (perhaps via a permanent setting) to playing audio descriptions. Also, if the player app knows that a screen reader is in use, it might make sense to use that as a cue of turning on audio descriptions.

===Video Format Support===

====Ogg====

How to flag a second sound track (Speex?) as ''closed'' audio description?

====MP4====

How to flag a second sound track as ''closed'' audio description?

==Data Placement in the Web Context==

Should the above-mentioned tracks be muxed into the main video file (Pro: all tracks travel together; Con: off-by-default tracks take bandwidth)? Or should they be separate HTTP resources (Pro: bandwidth optimization; Con: Web-specific content assembly from many files may not survive downloading to disk, etc.) Also note that separate files makes it easier for a 3rd party to add tracks -- but these tracks may be commentary rather than captions, so this is both a pro and a con.

==Related Non-Accessibility Features==

There are technically similar non-accessibility (i.e. not related to addressing needs arising from a disability) features related to translation.

===Translation Subtitles===

A site in language A might want to embed a video with the soundtrack in language B but subtitles in language A. For example, a Finnish-language site embedding an English-language video would want to have Finnish subtitles. Unlike captions, these subtitles should be on by default and being able to suppress the subtitles is considered an additional nice-to-have feature.

There are also same-language subtitles (e.g. French subtitles with French-language soundtrack) for language learners. Unlike captions, same-language subtitles don't inform the reader about non-verbal sounds or identify speakers.

Subtitles need different track metadata so that they can be displayed by default. (Due to concerns about the reliability of subtitling technology, many content providers probably opt to burn the subtitles into the video track as part of the image data, even though this disturbs video compression.)

===Alternative Dubbed Sound Tracks===

Due to bandwidth concerns, Web content providers will probably opt to provide separate video files for dubbed languages.

==Selection Mechanisms==

These use cases are broken into two categories: Acessibility, and the broader Universality. Due to their nature and similarity to real accessibility use cases, it is sometimes useful to consider possible solutions to accessibility in the context of the more general universality issues as well.

===Accessibility Use Cases===

====Deaf or Hearing Impaired User Viewing a Video====

A user who is unable to hear due to physical disability chooses to watch a video. The video is an interview between 2 people, discussing a topic that the user is interested in. The video has been provided with associated closed captions and the user would like to have those turned on so that he may understand speech and other significant sounds within the video.

====A Blind User Listening to a Video's Soundtrack====

A blind user cannot see the video, but is still able to hear the audio, chooses to listen to the sound track of a video anyway. The video is a "webisode" (A web episode - like a TV episode, but on the web) of a drama series the user enjoys watching. The video conveys some important information visually in the video, which is not made apparent in the main sound track, such as what the characters are doing and where they are. But the video also contains an alternative or complimentary track for audio descriptions, which describes significant parts of the video. The user wishes to enable the audio descriptions to more easily comprehend the content of the video.

There are two varations of this use case:

# The computer that the user is using is primarily meant for his own use, and generally not shared with other non-disabled users, and it would be convenient if this was not required to be a manual selection each time.
# The computer is shared between the disabled user and other non-disabled people. The accessibility features used by the disabled user are turned when used by others, and it would be inconvenient if the audio descriptions were automatically selected for them too.

====A Deaf and Blind User is Unable to See or Hear the Video====

A deaf and blind user cannot see or hear the video, and primarily accesses content using a braille reader. The video is a tutorial and demonstration about how to perform a particular science experiment at home. The user wishes to understand the content of the video so that he can teach the experiment to his nephew. The user needs to read the full text description, which describes and transcribes significant aural and visual content in the video. He does not need the video to be loaded, but instead needs to be provided with easy access to the full text description.

===Related Universality Use Cases===

====Sound Equipment is Unavailable, Muted, or has Low Volume====

A user who is unable to hear the audio in the video well because his computer lacks audio equipment, such as a sound card, headphones or speakers; or because the volume needs to be kept down low in the user's environment. The video has been provided with either closed captions or same-language subtitles. Similarly to a hearing impaired user, the user would like to have the ability to turn on captions or subtitles so they may more easily understand what is being said.

====A User Wants to Access a Transcript====

A user chooses not to watch a video, regardless of whether or not they are physically able. The video is of an election campaign speech and has been published with a transcript of the speech alongside. The user wishes to thoroughly review the speech and compare it with those from the other candidates. He accesses the transcript and prints it out, to enable him to read it and make notes or highlight important sections.

====A non-disabled user wants to read a full text description====

A video of a slide presentation has been published, but the user wishes to read the full text description instead. The description includes both a transcript of what the presenter said and images of the slides. The user chooses to read all or part of the full text description, instead of watching the whole video.

===Problems===

# A user who is deaf or hearing impaired needs a way to express his preference for captioning so that he is not required to manually enable them each time.
# A user without sound equipment on a particular device may also wish to express the preference for captioning to avoid manual selection each time.
# A user who is only temporarily unable to hear the audio due to low or muted volume needs a way to manually enable closed captions or same-language subtitle tracks on a per-video basis, if raising the volume is not practical.
# A blind user needs a way to express his preference for audio descriptions so that he is not required to manually select the descriptions each time.
# A user needs to have a way to manually enable or disable an alternative or complimentary audio track containing audio descriptions.
# A user, regardless of disability, needs a way to access a video transcript or full text description.
# A user needs a way to prevent their browser from automatically downloading video that they don't want or need.

===Proposed Solutions===

(to be completed)

Video accessibility

2008-09-11T02:28:42Z

JimJJewett: /* Deaf or Hearing Impaied User Viewing a Video */ typo

There appears to be consensus among the [http://wcagsamurai.org/errata/errata.html WCAG Samurai] and [http://www.w3.org/TR/WCAG20/#media-equiv the current WGAC 2.0 draft] that the primary ways of making video with soundtrack accessible are to provide captioning for the deaf and audio description for the blind. (The WCAG 2.0 draft also mentions full-text alternative as an alternative to audio description.)

Presumably, the captioning and audio description need to be “closed” (off-by-default, available on request) as content providers might hesitate presenting captions to those who do hear the soundtrack or audio description to those who already see the video track.

==Closed Captioning==

Technically this is timed text presented in sync with the video track.

It is assumed to be in the same language as the main soundtrack. Content-wise, it is expected to mention semantically important non-verbal sounds and identify speakers when the video doesn't make it clear who is talking.

In terms of player app decisions, this track shouldn't be presented by default but it should play if the user has opted in (perhaps via a permanent setting) to showing captioning. Also, if the player app knows that audio output has been turned off either in the app or in the OS, it might make sense to turn on captioning in that case as well.

===Video Format Support===

====Ogg====

CMML has been put forward as the timed text format for Ogg. (How to mark as ''closed'' captions?)

====MP4====

3GPP Timed Text aka. MPEG-4 part 17 is the timed text format for MP4. (How to mark as ''closed'' captions?)

==Closed Audio Description==

Technically this is a second sound track presented in sync with the main sound track.

It is assumed to be in the same language as the main soundtrack.

In terms of player app decisions, this track shouldn't be presented by default but it should play if the user has opted in (perhaps via a permanent setting) to playing audio descriptions. Also, if the player app knows that a screen reader is in use, it might make sense to use that as a cue of turning on audio descriptions.

===Video Format Support===

====Ogg====

How to flag a second sound track (Speex?) as ''closed'' audio description?

====MP4====

How to flag a second sound track as ''closed'' audio description?

==Data Placement in the Web Context==

Should the above-mentioned tracks be muxed into the main video file (Pro: all tracks travel together; Con: off-by-default tracks take bandwidth)? Or should they be separate HTTP resources (Pro: bandwidth optimization; Con: Web-specific content assembly from many files may not survive downloading to disk, etc.) Also note that separate files makes it easier for a 3rd party to add tracks -- but these tracks may be commentary rather than captions, so this is both a pro and a con.

==Related Non-Accessibility Features==

There are technically similar non-accessibility (i.e. not related to addressing needs arising from a disability) features related to translation.

===Translation Subtitles===

A site in language A might want to embed a video with the soundtrack in language B but subtitles in language A. For example, a Finnish-language site embedding an English-language video would want to have Finnish subtitles. Unlike captions, these subtitles should be on by default and being able to suppress the subtitles is considered an additional nice-to-have feature.

There are also same-language subtitles (e.g. French subtitles with French-language soundtrack) for language learners. Unlike captions, same-language subtitles don't inform the reader about non-verbal sounds or identify speakers.

Subtitles need different track metadata so that they can be displayed by default. (Due to concerns about the reliability of subtitling technology, many content providers probably opt to burn the subtitles into the video track as part of the image data, even though this disturbs video compression.)

===Alternative Dubbed Sound Tracks===

Due to bandwidth concerns, Web content providers will probably opt to provide separate video files for dubbed languages.

==Selection Mechanisms==

These use cases are broken into two categories: Acessibility, and the broader Universality. Due to their nature and similarity to real accessibility use cases, it is sometimes useful to consider possible solutions to accessibility in the context of the more general universality issues as well.

===Accessibility Use Cases===

====Deaf or Hearing Impaired User Viewing a Video====

A user who is unable to hear due to physical disability chooses to watch a video. The video is an interview between 2 people, discussing a topic that the user is interested in. The video has been provided with associated closed captions and the user would like to have those turned on so that he may understand speech and other significant sounds within the video.

====A Blind User Listing to a Video's Soundtrack====

A blind user cannot see the video, but is still able to hear the audio, chooses to listen to the sound track of a video anyway. The video is a "webisode" (A web episode - like a TV episode, but on the web) of a drama series the user enjoys watching. The video conveys some important information visually in the video, which is not made apparent in the main sound track, such as what the characters are doing and where they are. But the video also contains an alternative or complimentary track for audio descriptions, which describes significant parts of the video. The user wishes to enable the audio descriptions to more easily comprehend the content of the video.

There are two varations of this use case:

# The computer that the user is using is primarily meant for his own use, and generally not shared with other non-disabled users, and it would be convenient if this was not required to be a manual selection each time.
# The computer is shared between the disabled user and other non-disabled people. The accessibility features used by the disabled user are turned when used by others, and it would be inconvenient if the audio descriptions were automatically selected for them too.

====A Deaf and Blind User is Unable to See or Hear the Video====

A deaf and blind user cannot see or hear the video, and primarily accesses content using a braille reader. The video is a tutorial and demonstration about how to perform a particular science experiment at home. The user wishes to understand the content of the video so that he can teach the experiment to his nephew. The user needs to read the full text description, which describes and transcribes significant aural and visual content in the video. He does not need the video to be loaded, but instead needs to be provided with easy access to the full text description.

===Related Universality Use Cases===

====Sound Equipment is Unavailable, Muted, or has Low Volume====

A user who is unable to hear the audio in the video well because his computer lacks audio equipment, such as a sound card, headphones or speakers; or because the volume needs to be kept down low in the user's environment. The video has been provided with either closed captions or same-language subtitles. Similarly to a hearing impaired user, the user would like to have the ability to turn on captions or subtitles so they may more easily understand what is being said.

====A User Wants to Access a Transcript====

A user chooses not to watch a video, regardless of whether or not they are physically able. The video is of an election campaign speech and has been published with a transcript of the speech alongside. The user wishes to thoroughly review the speech and compare it with those from the other candidates. He accesses the transcript and prints it out, to enable him to read it and make notes or highlight important sections.

====A non-disabled user wants to read a full text description====

A video of a slide presentation has been published, but the user wishes to read the full text description instead. The description includes both a transcript of what the presenter said and images of the slides. The user chooses to read all or part of the full text description, instead of watching the whole video.

===Problems===

# A user who is deaf or hearing impaired needs a way to express his preference for captioning so that he is not required to manually enable them each time.
# A user without sound equipment on a particular device may also wish to express the preference for captioning to avoid manual selection each time.
# A user who is only temporarily unable to hear the audio due to low or muted volume needs a way to manually enable closed captions or same-language subtitle tracks on a per-video basis, if raising the volume is not practical.
# A blind user needs a way to express his preference for audio descriptions so that he is not required to manually select the descriptions each time.
# A user needs to have a way to manually enable or disable an alternative or complimentary audio track containing audio descriptions.
# A user, regardless of disability, needs a way to access a video transcript or full text description.
# A user needs a way to prevent their browser from automatically downloading video that they don't want or need.

===Proposed Solutions===

(to be completed)

Video accessibility

2008-09-11T02:27:17Z

JimJJewett: /* Data Placement in the Web Context */ 3rd party contrib

There appears to be consensus among the [http://wcagsamurai.org/errata/errata.html WCAG Samurai] and [http://www.w3.org/TR/WCAG20/#media-equiv the current WGAC 2.0 draft] that the primary ways of making video with soundtrack accessible are to provide captioning for the deaf and audio description for the blind. (The WCAG 2.0 draft also mentions full-text alternative as an alternative to audio description.)

Presumably, the captioning and audio description need to be “closed” (off-by-default, available on request) as content providers might hesitate presenting captions to those who do hear the soundtrack or audio description to those who already see the video track.

==Closed Captioning==

Technically this is timed text presented in sync with the video track.

It is assumed to be in the same language as the main soundtrack. Content-wise, it is expected to mention semantically important non-verbal sounds and identify speakers when the video doesn't make it clear who is talking.

In terms of player app decisions, this track shouldn't be presented by default but it should play if the user has opted in (perhaps via a permanent setting) to showing captioning. Also, if the player app knows that audio output has been turned off either in the app or in the OS, it might make sense to turn on captioning in that case as well.

===Video Format Support===

====Ogg====

CMML has been put forward as the timed text format for Ogg. (How to mark as ''closed'' captions?)

====MP4====

3GPP Timed Text aka. MPEG-4 part 17 is the timed text format for MP4. (How to mark as ''closed'' captions?)

==Closed Audio Description==

Technically this is a second sound track presented in sync with the main sound track.

It is assumed to be in the same language as the main soundtrack.

In terms of player app decisions, this track shouldn't be presented by default but it should play if the user has opted in (perhaps via a permanent setting) to playing audio descriptions. Also, if the player app knows that a screen reader is in use, it might make sense to use that as a cue of turning on audio descriptions.

===Video Format Support===

====Ogg====

How to flag a second sound track (Speex?) as ''closed'' audio description?

====MP4====

How to flag a second sound track as ''closed'' audio description?

==Data Placement in the Web Context==

Should the above-mentioned tracks be muxed into the main video file (Pro: all tracks travel together; Con: off-by-default tracks take bandwidth)? Or should they be separate HTTP resources (Pro: bandwidth optimization; Con: Web-specific content assembly from many files may not survive downloading to disk, etc.) Also note that separate files makes it easier for a 3rd party to add tracks -- but these tracks may be commentary rather than captions, so this is both a pro and a con.

==Related Non-Accessibility Features==

There are technically similar non-accessibility (i.e. not related to addressing needs arising from a disability) features related to translation.

===Translation Subtitles===

A site in language A might want to embed a video with the soundtrack in language B but subtitles in language A. For example, a Finnish-language site embedding an English-language video would want to have Finnish subtitles. Unlike captions, these subtitles should be on by default and being able to suppress the subtitles is considered an additional nice-to-have feature.

There are also same-language subtitles (e.g. French subtitles with French-language soundtrack) for language learners. Unlike captions, same-language subtitles don't inform the reader about non-verbal sounds or identify speakers.

Subtitles need different track metadata so that they can be displayed by default. (Due to concerns about the reliability of subtitling technology, many content providers probably opt to burn the subtitles into the video track as part of the image data, even though this disturbs video compression.)

===Alternative Dubbed Sound Tracks===

Due to bandwidth concerns, Web content providers will probably opt to provide separate video files for dubbed languages.

==Selection Mechanisms==

These use cases are broken into two categories: Acessibility, and the broader Universality. Due to their nature and similarity to real accessibility use cases, it is sometimes useful to consider possible solutions to accessibility in the context of the more general universality issues as well.

===Accessibility Use Cases===

====Deaf or Hearing Impaied User Viewing a Video====

A user who is unable to hear due to physical disability chooses to watch a video. The video is an interview between 2 people, discussing a topic that the user is interested in. The video has been provided with associated closed captions and the user would like to have those turned on so that he may understand speech and other significant sounds within the video.

====A Blind User Listing to a Video's Soundtrack====

A blind user cannot see the video, but is still able to hear the audio, chooses to listen to the sound track of a video anyway. The video is a "webisode" (A web episode - like a TV episode, but on the web) of a drama series the user enjoys watching. The video conveys some important information visually in the video, which is not made apparent in the main sound track, such as what the characters are doing and where they are. But the video also contains an alternative or complimentary track for audio descriptions, which describes significant parts of the video. The user wishes to enable the audio descriptions to more easily comprehend the content of the video.

There are two varations of this use case:

# The computer that the user is using is primarily meant for his own use, and generally not shared with other non-disabled users, and it would be convenient if this was not required to be a manual selection each time.
# The computer is shared between the disabled user and other non-disabled people. The accessibility features used by the disabled user are turned when used by others, and it would be inconvenient if the audio descriptions were automatically selected for them too.

====A Deaf and Blind User is Unable to See or Hear the Video====

A deaf and blind user cannot see or hear the video, and primarily accesses content using a braille reader. The video is a tutorial and demonstration about how to perform a particular science experiment at home. The user wishes to understand the content of the video so that he can teach the experiment to his nephew. The user needs to read the full text description, which describes and transcribes significant aural and visual content in the video. He does not need the video to be loaded, but instead needs to be provided with easy access to the full text description.

===Related Universality Use Cases===

====Sound Equipment is Unavailable, Muted, or has Low Volume====

A user who is unable to hear the audio in the video well because his computer lacks audio equipment, such as a sound card, headphones or speakers; or because the volume needs to be kept down low in the user's environment. The video has been provided with either closed captions or same-language subtitles. Similarly to a hearing impaired user, the user would like to have the ability to turn on captions or subtitles so they may more easily understand what is being said.

====A User Wants to Access a Transcript====

A user chooses not to watch a video, regardless of whether or not they are physically able. The video is of an election campaign speech and has been published with a transcript of the speech alongside. The user wishes to thoroughly review the speech and compare it with those from the other candidates. He accesses the transcript and prints it out, to enable him to read it and make notes or highlight important sections.

====A non-disabled user wants to read a full text description====

A video of a slide presentation has been published, but the user wishes to read the full text description instead. The description includes both a transcript of what the presenter said and images of the slides. The user chooses to read all or part of the full text description, instead of watching the whole video.

===Problems===

# A user who is deaf or hearing impaired needs a way to express his preference for captioning so that he is not required to manually enable them each time.
# A user without sound equipment on a particular device may also wish to express the preference for captioning to avoid manual selection each time.
# A user who is only temporarily unable to hear the audio due to low or muted volume needs a way to manually enable closed captions or same-language subtitle tracks on a per-video basis, if raising the volume is not practical.
# A blind user needs a way to express his preference for audio descriptions so that he is not required to manually select the descriptions each time.
# A user needs to have a way to manually enable or disable an alternative or complimentary audio track containing audio descriptions.
# A user, regardless of disability, needs a way to access a video transcript or full text description.
# A user needs a way to prevent their browser from automatically downloading video that they don't want or need.

===Proposed Solutions===

(to be completed)

Extensions

2008-04-03T01:21:28Z

JimJJewett: /* Error Handling */ specific case

'''Ways to arbitrarily extend text/html for new vocabularies'''

Please put ideas for what it should look like here, each in their own section.

Each example should explain in details (ideally with examples) how to handle:
* Syntax errors at the tokeniser level, the tree construction level, and the schema level.
* Existing content that happens to use elements or syntax that you are proposing have special processing rules.
* Pages that contain any special syntax after that syntax was copied and pasted by an ignorant Web author from a valid page written by a competent Web author aware of the new syntax.

See also SVG-specific proposals in [[Diagrams in HTML]].

== Proposal 1: xmlns strawman ==

When you hit an element with an xmlns="" attribute, switch to an XML parser until that parser has parsed the matching end tag.

<pre>
bla bla text/html bla bla <foo xmlns="http://example.com/foo"><this><must/>
be<valid>XML! </valid></this> must be.</foo> bla bla text/html
</pre>

Errors cause the entire page to stop parsing.

Existing pages are not handled.

Pages that copy-and-paste this syntax then use it incorrectly are not handled.

=== Reasons why we can't do this ===
* There are pages that already specify xmlns="" attributes that would break if the content were processed as XML. For example, [http://www.live.com/ http://www.live.com/].

Is there (much?) existing content with arbitrary namespaces, or could we enumerate a set of junk namespaces to ignore, and then do this for others?

Or could we at least do it for a whitelist of namespaces?

:* Probably, xmlns="" attribute, when used for HTML5 extensibility purposes, should be clearly marked as such, to disambiguate from legacy uses. For example, it could be explicitly declared at the root of the document:
<pre>
<html xmlns:xmlns="urn:html5:xmlns:for-example">
...
<foo xmlns="http://example.com/foo">

</foo>
...
</html>
</pre>

* Is it OK to switch parsing mode mid-document like this (and to effectively require an XML parser in every UA)?

== Proposal 2: Extensibility Element ==

This is a proposed generic extensibility point, for SVG and possibly MathML or other XML content, with the temporary placeholder name of <ext> (the real element name would be some token that doesn't clash with existing content). Inside you can use XML or another format. Naturally, any content placed in an <ext> element would have to be understood by the UA in order to render correctly, and more complex rules may need to be developed for specific kinds of interaction between the root document and the inline content, such as with script, CSS, etc. For some discussion, see the [http://krijnhoetmer.nl/irc-logs/whatwg/20080401#l-441 IRC logs].

<pre>
<p>Hello world.
<ext>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 10 10">
<circle x="5" y="5 r="5" stroke="green"/>
</svg>
</ext>
</p>
</pre>

We should define a content model for where the <ext> element can occur, and if there are implications for different locations (such as inside a table, a paragraph, the head, etc). The simplest thing, at least for SVG (and probably MathML), would be that it would have the same restrictions as an <img> element. Also, there should be a default block model for <ext> in CSS.

'''Please define this in enough detail that I can construct a tokeniser and tree constructor from the description. Ideally, just provide the actual tokeniser and tree constructor that you are proposing. [http://www.whatwg.org/specs/web-apps/current-work/#tokenisation This is what it looks like in the HTML5 spec] (sections 8.2.3 and 8.2.4). It's probably easiest to define it as a delta from what the spec has today.'''

Notes:

* This is similar to IE's "XML islands" with the <xml> element. It's believed that there are some conflicts with the <xml> element itself, since it creates a separate document that is tied to the <xml> element in the DOM, but more research is needed. See also [http://developer.mozilla.org/en/docs/Using_XML_Data_Islands_in_Mozilla Using XML Data Islands in Mozilla].

* The <ext> element could potentially be an implicit element, generated by the HTML5 parser on encountering a start tag of e.g. "<svg " or "<math ". That would save authors of having to type this extra element, but has a drawback in that it doesn't provide fallback content for legacy UAs. -Ed

* We could specify exactly what flavors of markup must be supported by a UA, and which may be supported by a UA. This would be rather restrictive, but could improve interoperability of UA features, and would ensure that the proper DOM interfaces are available. For example, SVG and MathML must be supported, and FooML may be supported (or something).

=== Error Handling ===

'''Pick one! Or separate the proposal into several proposals, for each different proposal, so that they can be evaluated. The proposals below are just brief notes, not detailed enough for me to know what you mean. -Hixie'''
Notes:
The main options seem to be:
# strict XML parsing (not favored by many)
# very permissive error handling (as in HTML5); this idea is controversial
and has many open issues, which should be detailed below
# moderate error handling, as detailed in SVG Tiny 1.2
# other ideas?

The chief risk with permissive error handling is that it would create
content that is not compatible across different UAs, including mobile
devices and authoring tools.

Proposal:
* Tree construction recovers from errors by closing the <svg> element, and not rendering any content after the error.
* Case folding is not supported within the main body of the <ext> element, though it would be within the <fallback> element.
* The tree builder would assign the appropriate namespace URI to the element and attribute nodes it creates.
* Unknown attributes and elements are ignored.
* Unquoted attribute values will be ignored (should the element also not be rendered?)
* If the "/>" is not found at the end of an element, all subsequent element will be placed as child elements of the element (and thus not rendered) until a matching closing tag is found, or until the a matching root tag is found, or until the "</ext>" element is found.
** If a matching closing tag is found, the element is closed, and subsequent elements are rendered as normal.
** If a matching closing root tag is found, the element is closed, the root tag is closed, and any subsequent elements are ignored if outside a root tag.
** If a matching closing <ext> tag is found, the element is closed, the root tag is closed, the <ext> tag is closed, and HTML processing continues as normal.

<font color="red">''Please explain the manner in which you find this aspect incomplete or lacking, with links to relevant sections of the HTML5 spec for reference, and I will try to fix any problems. -Shepazu''</font>

One question is how to find the matching tag. Which parsing mode is active after 2-open/1-close:

<ext><ext></ext>

Notes (not sure this fits in the above proposal):
* Tokenizer recovers from errors by ignoring subsequent content
between the error and the closing <ext> tag, closing the <svg>
element and <ext> element, and moving on with normal HTML
processing; for SVG, any element with errors is not rendered.

See the following emails by Henri Sivonen for comparison and contrast:
* [http://lists.w3.org/Archives/Public/public-html/2007Oct/0158.html Re: SVG in text/html (was: @role in SVG)]
* [http://lists.w3.org/Archives/Public/public-html/2008Apr/0065.html Re: several messages about New Vocabularies in text/html]

=== Embedded HTML ===

The case of content inside a <foreignObject> element could be subject to the parsing model of the root document. (Note that this is only a partial solution, and more thought and details are needed.)

For content outside <foreignObject>, it should follow the XML processing rules.

=== Fallback Behavior ===

This is an opportunity to get nice fallback behavior, as well.

Here's a possible suggestion, where the raster image would show in UAs that didn't support the <ext> syntax, and the SVG would show in those that did (and which support SVG). In UAs which support <ext> and not SVG, the fallback would also be the raster. The fallback content should be inside a wrapper element (<fallback>), so that you can have rich fallback options, such as an image map, a table, <canvas> and an accompanying <script> element, or whatever; in this case, I also include fallback CSS to hide textual content in title, desc, and text elements, but it may be desirable to leave this content as alternate text to the image, even including styling.

For MathML content, a conditional CSS override could allow for CSS styling of MathML elements for those that don't render MathML natively.

''Note: as stated before, the names of the <ext> and <fallback> elements are subject to change based on existing element names in the wild.''

<pre>
<html lang="en">
<head>
<title>HTML Extensibility Test</title>
</head>
<body>
<h1 id="test_of_extensibility">Test of Extensibility</h1>
<p>This is a test of an extensibility point in text/html, with a fallback mechanism.</p>
<ext>
<fallback>
<img src="anIsland.png" alt="..."/>
<style type='text/css'>
svg > * { display: none; }
</style>
</fallback>
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="100%" height="100%"
version="1.1">
<title>My Title</title>
<desc>schepers, 01-04-2008</desc>
<circle id="circle_1" cx="75" cy="25" r="20" fill="lime" />
<text id='text_1' x='10' y='25' font-size='18' fill='crimson'>This is some text.</text>
</svg>
</ext>
</body>
</html>
</pre>

=== Reasons why we can't do this ===

It's not clear what the processing model being proposed actually is. However, there is already one problem:

* The idea relies on not conflicting with legacy content. Unfortunately, whatever syntax we end up using, people will copy and paste it from documents that were written by competent authors that tested it against the new UAs, into documents written by authors who don't know about this, and who don't have the new UA, thus creating new "legacy documents" that use whatever syntax we come up with. Saying the risk is minimal doesn't mitigate this problem. It's a real problem, and we have to deal with it. <font color="red">''Such content clearly wouldn't work in the legacy UAs, and so the mistake will have no reason to propagate (the novice author will have no incentive to copy such content if it doesn't work in their UA); further, this is an issue with any new HTML5 syntax. Please explain in more detail how this is a problem. -Shepazu''</font>

Note also that the fallback idea doesn't work. Elements like <script>, <style>, <title>, <input>, <textarea> etc, get treated as HTML elements in legacy UAs. <font color="red">''Please expand on this; the <fallback> proposal relies on the fact that any content in the <fallback> element be treated as HTML, so it's not clear what the objection is. -Shepazu''</font>

Relying on CSS for hiding the text content doesn't work either, because CSS is optional and might not be enabled (or supported). <font color="red">''In this case, legacy browsers that don't support <fallback> and in which CSS (or optionally JS) is not enabled or supported would, unfortunately print the textnodes; this still doesn't break the page, however, and any page which relies on JS or CSS will always fail in such UAs; this is true of almost every Webapp. -Shepazu''</font>

(It doesn't much matter, though, because fallback isn't one of [[New Vocabularies|the things we're trying to address]] with this.) <font color="red">''This seems like an artificial constraint; any solution which solves another larger problem (even if that's not the problem being addressed) is not a bug, it's a feature. -Shepazu''</font>

== Proposal 3: XML5 ==

Microsoft has published a [http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=ie8whitepapers&ReleaseId=573 whitepaper] on the subject of ''Improved Namespace Support''. Salient features:

* Windows Internet Explorer 8 Beta 1 for Developers offers Web developers the opportunity to write standards-compliant HTML-based Web pages that support features (such as SVG, XUL, and MathML) in namespaces, ''provided that the client has installed appropriate handlers for those namespaces via binary behaviors''. (A binary behavior is a type of ActiveX control.) ''<ins>[[User:Tbroyer|Tbroyer]]: note that those ''behaviors'' don't change the way the markup is parsed into a DOM; at least for elements whose name contains a colon (haven't tested this in IE8, but this is the way it is since IE5.5)</ins>''
* Internet Explorer 8 does not support the XHTML namespace definition. Thus, default namespace declarations of XHTML are ignored (xmlns="http://www.w3.org/1999/xhtml"). ''<ins>[[User:Tbroyer|Tbroyer]]: this means that you cannot switch from a default namespace back to HTML (actually, this is true in IE8 in a more general fashion: once you've set a default namespace (i.e. once you've leaved "HTML"), you cannot switch to another; the whitepaper describes this as "Nesting of multiple default namespaces is not allowed; in other words, a default namespace declaration inside of another default namespace declaration will be ignored."</ins>''
* Internet Explorer 8 does not support default namespace declarations on any known elements such as HTML, SCRIPT, DIV, or STYLE. If default namespace declarations are encountered on these elements, the declaration is ignored (for purposes of existing Web page compatibility).

A few notes:

* While Microsoft's IE8 implementation as described by this whitepaper does not satisfy all of the requirements; the above list focuses on the parts that do.
* While Microsoft's implementation is based on ActiveX (''<ins>[[User:Tbroyer|Tbroyer]]: see above, ActiveX give you the behaviors associated with a given namespace URI, but doesn't change the parsing algorithm</ins>''), the situation could very well end up being similar to [http://www.w3.org/TR/XMLHttpRequest/ XMLHttpRequest] whereby the functionality was first exposed via ActiveX, other browser vendors adopted an alternate object model interface to this same functionality, and that interface was later adopted and standardized.
* While the white paper does not explicitly state this requirement, the approach works best if the simple name for the unknown (to HTML5) element which contains the default namespace declaration for which a binary behavior has been installed is not contained within the subtree. Both SVG and MathML have unique elements (<code>svg</code> and <code>math</code>, respectively) that satisfy this purpose. This gives proposal 3 some of the desirable characteristics of proposal 2 spelled out above.
* In order to meet the ''Resistance to errors (e.g. not brittle in the face of syntax errors)'' [[New Vocabularies|requirement]], something akin to [http://annevankesteren.nl/2007/10/xml5 Anne van Kesteren's XML5] would be required, an implementation of which can be seen on [http://code.google.com/p/xml5/ Google Code]. ''<ins>[[User:Tbroyer|Tbroyer]]: see also the [http://html5lib.googlecode.com/svn/branches/namespaces-in-text-html/python/ namespaces-in-text-html branch of html5lib]</ins>''

=== Reasons why we can't do this ===

I've no idea what IE8 beta 1 is supposed to do. The whitepaper doesn't describe the processing model, the error handling, or how to handle legacy content, and IE8 Beta 1 doesn't seem to implement the whitepaper's syntax at all.

Extensions

2008-04-03T01:16:22Z

JimJJewett: questions on xmlns suggestion

'''Ways to arbitrarily extend text/html for new vocabularies'''

Please put ideas for what it should look like here, each in their own section.

Each example should explain in details (ideally with examples) how to handle:
* Syntax errors at the tokeniser level, the tree construction level, and the schema level.
* Existing content that happens to use elements or syntax that you are proposing have special processing rules.
* Pages that contain any special syntax after that syntax was copied and pasted by an ignorant Web author from a valid page written by a competent Web author aware of the new syntax.

See also SVG-specific proposals in [[Diagrams in HTML]].

== Proposal 1: xmlns strawman ==

When you hit an element with an xmlns="" attribute, switch to an XML parser until that parser has parsed the matching end tag.

<pre>
bla bla text/html bla bla <foo xmlns="http://example.com/foo"><this><must/>
be<valid>XML! </valid></this> must be.</foo> bla bla text/html
</pre>

Errors cause the entire page to stop parsing.

Existing pages are not handled.

Pages that copy-and-paste this syntax then use it incorrectly are not handled.

=== Reasons why we can't do this ===
* There are pages that already specify xmlns="" attributes that would break if the content were processed as XML. For example, [http://www.live.com/ http://www.live.com/].

Is there (much?) existing content with arbitrary namespaces, or could we enumerate a set of junk namespaces to ignore, and then do this for others?

Or could we at least do it for a whitelist of namespaces?

:* Probably, xmlns="" attribute, when used for HTML5 extensibility purposes, should be clearly marked as such, to disambiguate from legacy uses. For example, it could be explicitly declared at the root of the document:
<pre>
<html xmlns:xmlns="urn:html5:xmlns:for-example">
...
<foo xmlns="http://example.com/foo">

</foo>
...
</html>
</pre>

* Is it OK to switch parsing mode mid-document like this (and to effectively require an XML parser in every UA)?

== Proposal 2: Extensibility Element ==

This is a proposed generic extensibility point, for SVG and possibly MathML or other XML content, with the temporary placeholder name of <ext> (the real element name would be some token that doesn't clash with existing content). Inside you can use XML or another format. Naturally, any content placed in an <ext> element would have to be understood by the UA in order to render correctly, and more complex rules may need to be developed for specific kinds of interaction between the root document and the inline content, such as with script, CSS, etc. For some discussion, see the [http://krijnhoetmer.nl/irc-logs/whatwg/20080401#l-441 IRC logs].

<pre>
<p>Hello world.
<ext>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 10 10">
<circle x="5" y="5 r="5" stroke="green"/>
</svg>
</ext>
</p>
</pre>

We should define a content model for where the <ext> element can occur, and if there are implications for different locations (such as inside a table, a paragraph, the head, etc). The simplest thing, at least for SVG (and probably MathML), would be that it would have the same restrictions as an <img> element. Also, there should be a default block model for <ext> in CSS.

'''Please define this in enough detail that I can construct a tokeniser and tree constructor from the description. Ideally, just provide the actual tokeniser and tree constructor that you are proposing. [http://www.whatwg.org/specs/web-apps/current-work/#tokenisation This is what it looks like in the HTML5 spec] (sections 8.2.3 and 8.2.4). It's probably easiest to define it as a delta from what the spec has today.'''

Notes:

* This is similar to IE's "XML islands" with the <xml> element. It's believed that there are some conflicts with the <xml> element itself, since it creates a separate document that is tied to the <xml> element in the DOM, but more research is needed. See also [http://developer.mozilla.org/en/docs/Using_XML_Data_Islands_in_Mozilla Using XML Data Islands in Mozilla].

* The <ext> element could potentially be an implicit element, generated by the HTML5 parser on encountering a start tag of e.g. "<svg " or "<math ". That would save authors of having to type this extra element, but has a drawback in that it doesn't provide fallback content for legacy UAs. -Ed

* We could specify exactly what flavors of markup must be supported by a UA, and which may be supported by a UA. This would be rather restrictive, but could improve interoperability of UA features, and would ensure that the proper DOM interfaces are available. For example, SVG and MathML must be supported, and FooML may be supported (or something).

=== Error Handling ===

'''Pick one! Or separate the proposal into several proposals, for each different proposal, so that they can be evaluated. The proposals below are just brief notes, not detailed enough for me to know what you mean. -Hixie'''
Notes:
The main options seem to be:
# strict XML parsing (not favored by many)
# very permissive error handling (as in HTML5); this idea is controversial
and has many open issues, which should be detailed below
# moderate error handling, as detailed in SVG Tiny 1.2
# other ideas?

The chief risk with permissive error handling is that it would create
content that is not compatible across different UAs, including mobile
devices and authoring tools.

Proposal:
* Tree construction recovers from errors by closing the <svg> element, and not rendering any content after the error.
* Case folding is not supported within the main body of the <ext> element, though it would be within the <fallback> element.
* The tree builder would assign the appropriate namespace URI to the element and attribute nodes it creates.
* Unknown attributes and elements are ignored.
* Unquoted attribute values will be ignored (should the element also not be rendered?)
* If the "/>" is not found at the end of an element, all subsequent element will be placed as child elements of the element (and thus not rendered) until a matching closing tag is found, or until the a matching root tag is found, or until the "</ext>" element is found.
** If a matching closing tag is found, the element is closed, and subsequent elements are rendered as normal.
** If a matching closing root tag is found, the element is closed, the root tag is closed, and any subsequent elements are ignored if outside a root tag.
** If a matching closing <ext> tag is found, the element is closed, the root tag is closed, the <ext> tag is closed, and HTML processing continues as normal.

<font color="red">''Please explain the manner in which you find this aspect incomplete or lacking, with links to relevant sections of the HTML5 spec for reference, and I will try to fix any problems. -Shepazu''</font>

Notes (not sure this fits in the above proposal):
* Tokenizer recovers from errors by ignoring subsequent content
between the error and the closing <ext> tag, closing the <svg>
element and <ext> element, and moving on with normal HTML
processing; for SVG, any element with errors is not rendered.

See the following emails by Henri Sivonen for comparison and contrast:
* [http://lists.w3.org/Archives/Public/public-html/2007Oct/0158.html Re: SVG in text/html (was: @role in SVG)]
* [http://lists.w3.org/Archives/Public/public-html/2008Apr/0065.html Re: several messages about New Vocabularies in text/html]

=== Embedded HTML ===

The case of content inside a <foreignObject> element could be subject to the parsing model of the root document. (Note that this is only a partial solution, and more thought and details are needed.)

For content outside <foreignObject>, it should follow the XML processing rules.

=== Fallback Behavior ===

This is an opportunity to get nice fallback behavior, as well.

Here's a possible suggestion, where the raster image would show in UAs that didn't support the <ext> syntax, and the SVG would show in those that did (and which support SVG). In UAs which support <ext> and not SVG, the fallback would also be the raster. The fallback content should be inside a wrapper element (<fallback>), so that you can have rich fallback options, such as an image map, a table, <canvas> and an accompanying <script> element, or whatever; in this case, I also include fallback CSS to hide textual content in title, desc, and text elements, but it may be desirable to leave this content as alternate text to the image, even including styling.

For MathML content, a conditional CSS override could allow for CSS styling of MathML elements for those that don't render MathML natively.

''Note: as stated before, the names of the <ext> and <fallback> elements are subject to change based on existing element names in the wild.''

<pre>
<html lang="en">
<head>
<title>HTML Extensibility Test</title>
</head>
<body>
<h1 id="test_of_extensibility">Test of Extensibility</h1>
<p>This is a test of an extensibility point in text/html, with a fallback mechanism.</p>
<ext>
<fallback>
<img src="anIsland.png" alt="..."/>
<style type='text/css'>
svg > * { display: none; }
</style>
</fallback>
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="100%" height="100%"
version="1.1">
<title>My Title</title>
<desc>schepers, 01-04-2008</desc>
<circle id="circle_1" cx="75" cy="25" r="20" fill="lime" />
<text id='text_1' x='10' y='25' font-size='18' fill='crimson'>This is some text.</text>
</svg>
</ext>
</body>
</html>
</pre>

=== Reasons why we can't do this ===

It's not clear what the processing model being proposed actually is. However, there is already one problem:

* The idea relies on not conflicting with legacy content. Unfortunately, whatever syntax we end up using, people will copy and paste it from documents that were written by competent authors that tested it against the new UAs, into documents written by authors who don't know about this, and who don't have the new UA, thus creating new "legacy documents" that use whatever syntax we come up with. Saying the risk is minimal doesn't mitigate this problem. It's a real problem, and we have to deal with it. <font color="red">''Such content clearly wouldn't work in the legacy UAs, and so the mistake will have no reason to propagate (the novice author will have no incentive to copy such content if it doesn't work in their UA); further, this is an issue with any new HTML5 syntax. Please explain in more detail how this is a problem. -Shepazu''</font>

Note also that the fallback idea doesn't work. Elements like <script>, <style>, <title>, <input>, <textarea> etc, get treated as HTML elements in legacy UAs. <font color="red">''Please expand on this; the <fallback> proposal relies on the fact that any content in the <fallback> element be treated as HTML, so it's not clear what the objection is. -Shepazu''</font>

Relying on CSS for hiding the text content doesn't work either, because CSS is optional and might not be enabled (or supported). <font color="red">''In this case, legacy browsers that don't support <fallback> and in which CSS (or optionally JS) is not enabled or supported would, unfortunately print the textnodes; this still doesn't break the page, however, and any page which relies on JS or CSS will always fail in such UAs; this is true of almost every Webapp. -Shepazu''</font>

(It doesn't much matter, though, because fallback isn't one of [[New Vocabularies|the things we're trying to address]] with this.) <font color="red">''This seems like an artificial constraint; any solution which solves another larger problem (even if that's not the problem being addressed) is not a bug, it's a feature. -Shepazu''</font>

== Proposal 3: XML5 ==

Microsoft has published a [http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=ie8whitepapers&ReleaseId=573 whitepaper] on the subject of ''Improved Namespace Support''. Salient features:

* Windows Internet Explorer 8 Beta 1 for Developers offers Web developers the opportunity to write standards-compliant HTML-based Web pages that support features (such as SVG, XUL, and MathML) in namespaces, ''provided that the client has installed appropriate handlers for those namespaces via binary behaviors''. (A binary behavior is a type of ActiveX control.) ''<ins>[[User:Tbroyer|Tbroyer]]: note that those ''behaviors'' don't change the way the markup is parsed into a DOM; at least for elements whose name contains a colon (haven't tested this in IE8, but this is the way it is since IE5.5)</ins>''
* Internet Explorer 8 does not support the XHTML namespace definition. Thus, default namespace declarations of XHTML are ignored (xmlns="http://www.w3.org/1999/xhtml"). ''<ins>[[User:Tbroyer|Tbroyer]]: this means that you cannot switch from a default namespace back to HTML (actually, this is true in IE8 in a more general fashion: once you've set a default namespace (i.e. once you've leaved "HTML"), you cannot switch to another; the whitepaper describes this as "Nesting of multiple default namespaces is not allowed; in other words, a default namespace declaration inside of another default namespace declaration will be ignored."</ins>''
* Internet Explorer 8 does not support default namespace declarations on any known elements such as HTML, SCRIPT, DIV, or STYLE. If default namespace declarations are encountered on these elements, the declaration is ignored (for purposes of existing Web page compatibility).

A few notes:

* While Microsoft's IE8 implementation as described by this whitepaper does not satisfy all of the requirements; the above list focuses on the parts that do.
* While Microsoft's implementation is based on ActiveX (''<ins>[[User:Tbroyer|Tbroyer]]: see above, ActiveX give you the behaviors associated with a given namespace URI, but doesn't change the parsing algorithm</ins>''), the situation could very well end up being similar to [http://www.w3.org/TR/XMLHttpRequest/ XMLHttpRequest] whereby the functionality was first exposed via ActiveX, other browser vendors adopted an alternate object model interface to this same functionality, and that interface was later adopted and standardized.
* While the white paper does not explicitly state this requirement, the approach works best if the simple name for the unknown (to HTML5) element which contains the default namespace declaration for which a binary behavior has been installed is not contained within the subtree. Both SVG and MathML have unique elements (<code>svg</code> and <code>math</code>, respectively) that satisfy this purpose. This gives proposal 3 some of the desirable characteristics of proposal 2 spelled out above.
* In order to meet the ''Resistance to errors (e.g. not brittle in the face of syntax errors)'' [[New Vocabularies|requirement]], something akin to [http://annevankesteren.nl/2007/10/xml5 Anne van Kesteren's XML5] would be required, an implementation of which can be seen on [http://code.google.com/p/xml5/ Google Code]. ''<ins>[[User:Tbroyer|Tbroyer]]: see also the [http://html5lib.googlecode.com/svn/branches/namespaces-in-text-html/python/ namespaces-in-text-html branch of html5lib]</ins>''

=== Reasons why we can't do this ===

I've no idea what IE8 beta 1 is supposed to do. The whitepaper doesn't describe the processing model, the error handling, or how to handle legacy content, and IE8 Beta 1 doesn't seem to implement the whitepaper's syntax at all.