This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.
- 1 General Rationale
- 2 Specific Elements
- 3 HTML parsing
- 4 Failed proposals
- 5 Other Pages
- 6 References
One Vendor, One Veto
Part of the the goal of the WHATWG is to document how web browsers actually handle HTML. As such browser vendors already have veto power - by not following the standard. The W3C and WHATWG do not have any enforcement power and can only write what browsers are willing to implement. Not removing features from the HTML standard that at least one browser vendor has stated they are unwilling to implement causes the HTML spec to not accurately document reality.. The veto isn't a power that we grant browsers, it's a right that they earn on their own by virtue of having users. The minimum market share for a veto is somewhere around 1%.
Using elements where scripts "work"
the <plaintext> element is a obsolete precursor to the <pre> element.  It is is now in the HTML5 spec as a method of stopping all further html token parsing. It lacks an end tag and just emits the rest of the page as plain text. It throws a parse error upon reaching the end of the document as it is not considered a valid element (and it is missing an end-tag).
<image> element is treated as an alternate (but invalid) name for <img>. This is because some sites (around 0.2%) make this mistake. It is already treated as an image by most major browsers.
Meter and Progress (are not the same thing)
<meter> is not just a special case of <progress>. The meter element represents a scalar measurement within a known range, such as storage quota usage, a relative popularity rating or relevance indicator. The control allows for the indication of high and low ranges, or minimum, maximum and optimal levels.
The progress element, on the other hand, represents the completion progress of a task. This could be a real time indicator for background processing task (e.g. using Web Workers or a file upload). Progress elmements can also be in the indeterminate state, indicating that something is in progress, but it's completion progress is unknown.
The default rendering for a meter element could look something like the following:
Whereas, the default rendering for the progress element could look like this:
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:
See Re: <progress> draft for details.
B, I, EM, STRONG, and MARK
<em> is meant to indicate that some text is emphasized. <strong> is meant to confer importance upon text. <b> is meant for text that is stylistically offset from the rest of the text. Finally <i> is used to indicate that some text is meant to be read in an alternate mood.
Cats are <em>cute</em> animals.
could mean that cats are specifically cute.
Cats are <strong>cute</strong> animals.
could mean that the word cute is in some way important
Cats are <b>cute</b> animals.
could mean that the word cute is a new word (perhaps in a language lesson) but is not important
Cats are <i>cute</i> animals.
could mean that the word cute is meant to be read in a different tone (sarcastically for example)
Cats are <mark>cute</mark> animals.
means that the sentence is to be read normally but the work "cute" should be highlighted or marked in some way. This could be used for search terms on the page or alterations to an original text.
IMG tag & alt text
On certain types of pages adding alt text is impossible (like sites that the user could upload images but does not supply a description). Because of this the alt attribute is optional  A longdesc attribute is not needed 
The text area defaults to soft wrapping of the text area. The attribute @wrap can have one of the following values: soft, hard, or off.. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. 
hgroup and other heading elements
The point of <hgroup> is to hide the subtitle from the outlining algorithm.
The <details> element is needed to provide an accessible way of reflecting a common application widget in HTML-based applications without requiring authors to use extensive scripting, ARIA, and platform-specific CSS to get the same effect.
The HTML parser has the following behavior difference in quirks mode:
- A start tag whose tag name is "table"
- If the Document is not set to quirks mode, and the stack of open elements has a p element in scope, then act as if an end tag with the tag name "p" had been seen.
ignored white space before head
White space before the
<head> tag is ignored. The main reason is that, given the markup
<!DOCTYPE html> <html> <head> <title>Sample page</title> ...,
some people expect
to return the
An "advert" tag for advertisements
There is no advert tag because if users had an easy method of plainly disabling all ads from downloading or appearing content authors would cease to use the tag.
sandbox attribute on the html element
Various proposals have come up with the idea of being able to determine of a certain feature is available. These fail for a variety of reasons: Part of the problem is that browser vendors will be economical with the truth. Marketing people always have an over-optimistic view of the compliance of their product, and will always give themselves the benefit of the doubt in borderline cases. Also, changing the compliance statement, to remove false claims that are exposed, is likely to a very low priority for the developers. With regard to CSS feature compliance: Remember that CSS provides hints and implementations don't have to accept those hints, and hardware may sometimes prevent their being implemented. Some other reasons can be found in the footnotes.
- Why no namespaces
- Why no script implements
- Why not reuse legend or another mini-header element.
- Rationale for a variety of elements
- XHTML2 versus HTML5
- <meta http-equiv=content-language>
- earlier page started with the same purpose.
- rationale for some new HTML5 elements
- WHATWG FAQ
- http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for <video> and <audio></a>
- http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto
- Email from Ian Hickson; comment in spec source
- [whatwg] several messages about the tree construction stage of HTML parsing