https://wiki.whatwg.org/api.php?action=feedcontributions&user=Variable&feedformat=atomWHATWG Wiki - User contributions [en]2024-03-29T05:55:24ZUser contributionsMediaWiki 1.39.3https://wiki.whatwg.org/index.php?title=Rationale&diff=5530Rationale2010-10-23T14:23:17Z<p>Variable: /* General Rationale */ add section about modifying existing semantics</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
=== It isn't just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won't use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
=== Experimenting with features ===<br />
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref><br />
<br />
=== Versioning the spec ===<br />
Most authors don't care about whether or not an implementation supports an entire, full specification; they just want to know "Can I use this feature in this browser?" So saying that all major implementations support much of CSS 2 to a high degree of correctness is useless for knowing if, say, the author can use display: run-in. In other words, the feature tables are what web authors would actually use in real life.<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23306.html</ref><br />
<br />
<!--=== HTML5 the spec vs HTML5 the buzzword ===<br />
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23299.html<br />
--><br />
<br />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML4 users would expect. Semantic markup isn't very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated dd as enclosing a term being defined, for the purposes of searching for definitions (or excluding defining occurrences from results), it would not find many definitions, and it would misclassify things.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-October/000668.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Doctype ===<br />
Since HTML5 has moved to an unversioned model the doctype does not a have version number. It is necessary for legacy browsers that will switch to standards mode only when a doctype is present.<br />
<br />
=== Plaintext ===<br />
The &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
means that the sentence is to be read normally but the word "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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
<!--<br />
=== br and linebreaks ===<br />
--><br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
=== custom HTML elements ===<br />
Custom elements make it impossible for search engines, developers, and browsers to understand the semantics of a page.<ref>http://html5doctor.com/your-questions-13/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+html5doctor+%28HTML5doctor%29</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5507Rationale2010-09-30T18:43:58Z<p>Variable: *sigh* spam</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
=== It isn't just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won't use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
=== Experimenting with features ===<br />
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref><br />
<br />
=== Versioning the spec ===<br />
Most authors don't care about whether or not an implementation supports an entire, full specification; they just want to know "Can I use this feature in this browser?" So saying that all major implementations support much of CSS 2 to a high degree of correctness is useless for knowing if, say, the author can use display: run-in. In other words, the feature tables are what web authors would actually use in real life.<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23306.html</ref><br />
<br />
<!--=== HTML5 the spec vs HTML5 the buzzword ===<br />
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23299.html<br />
--><br />
<br />
== Specific Elements ==<br />
<br />
=== Doctype ===<br />
Since HTML5 has moved to an unversioned model the doctype does not a have version number. It is necessary for legacy browsers that will switch to standards mode only when a doctype is present.<br />
<br />
=== Plaintext ===<br />
The &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
means that the sentence is to be read normally but the word "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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
<!--<br />
=== br and linebreaks ===<br />
--><br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
=== custom HTML elements ===<br />
Custom elements make it impossible for search engines, developers, and browsers to understand the semantics of a page.<ref>http://html5doctor.com/your-questions-13/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+html5doctor+%28HTML5doctor%29</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5504Rationale2010-09-28T14:45:43Z<p>Variable: /* custom HTML elements */ missing end ref tag</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
=== It isn't just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won't use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
=== Experimenting with features ===<br />
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref><br />
<br />
=== Versioning the spec ===<br />
Most authors don't care about whether or not an implementation supports an entire, full specification; they just want to know "Can I use this feature in this browser?" So saying that all major implementations support much of CSS 2 to a high degree of correctness is useless for knowing if, say, the author can use display: run-in. In other words, the feature tables are what web authors would actually use in real life.<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23306.html</ref><br />
<br />
<!--=== HTML5 the spec vs HTML5 the buzzword ===<br />
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23299.html<br />
--><br />
<br />
== Specific Elements ==<br />
<br />
=== Doctype ===<br />
Since HTML5 has moved to an unversioned model the doctype does not a have version number. It is necessary for legacy browsers that will switch to standards mode only when a doctype is present.<br />
<br />
=== Plaintext ===<br />
The &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
means that the sentence is to be read normally but the word "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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
<!--<br />
=== br and linebreaks ===<br />
--><br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
=== custom HTML elements ===<br />
Custom elements make it impossible for search engines, developers, and browsers to understand the semantics of a page.<ref>http://html5doctor.com/your-questions-13/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+html5doctor+%28HTML5doctor%29</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5503Rationale2010-09-28T14:43:05Z<p>Variable: add custom HTML elements text + reference</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
=== It isn't just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won't use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
=== Experimenting with features ===<br />
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref><br />
<br />
=== Versioning the spec ===<br />
Most authors don't care about whether or not an implementation supports an entire, full specification; they just want to know "Can I use this feature in this browser?" So saying that all major implementations support much of CSS 2 to a high degree of correctness is useless for knowing if, say, the author can use display: run-in. In other words, the feature tables are what web authors would actually use in real life.<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23306.html</ref><br />
<br />
<!--=== HTML5 the spec vs HTML5 the buzzword ===<br />
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23299.html<br />
--><br />
<br />
== Specific Elements ==<br />
<br />
=== Doctype ===<br />
Since HTML5 has moved to an unversioned model the doctype does not a have version number. It is necessary for legacy browsers that will switch to standards mode only when a doctype is present.<br />
<br />
=== Plaintext ===<br />
The &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
means that the sentence is to be read normally but the word "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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
<!--<br />
=== br and linebreaks ===<br />
--><br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
=== custom HTML elements ===<br />
Custom elements make it impossible for search engines, developers, and browsers to understand the semantics of a page.<ref>http://html5doctor.com/your-questions-13/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+html5doctor+%28HTML5doctor%29<ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5480Rationale2010-09-08T02:13:27Z<p>Variable: /* Versioning the spec */ remove minor bit of text that only made sense in the email</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
=== It isn't just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won't use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
=== Experimenting with features ===<br />
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref><br />
<br />
=== Versioning the spec ===<br />
Most authors don't care about whether or not an implementation supports an entire, full specification; they just want to know "Can I use this feature in this browser?" So saying that all major implementations support much of CSS 2 to a high degree of correctness is useless for knowing if, say, the author can use display: run-in. In other words, the feature tables are what web authors would actually use in real life.<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23306.html</ref><br />
<br />
<!--=== HTML5 the spec vs HTML5 the buzzword ===<br />
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23299.html<br />
--><br />
<br />
== Specific Elements ==<br />
<br />
=== Doctype ===<br />
Since HTML5 has moved to an unversioned model the doctype does not a have version number. It is necessary for legacy browsers that will switch to standards mode only when a doctype is present.<br />
<br />
=== Plaintext ===<br />
The &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
means that the sentence is to be read normally but the word "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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
<!--<br />
=== br and linebreaks ===<br />
--><br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5479Rationale2010-09-08T02:12:48Z<p>Variable: add spec versioning. yes this is a blatent copy/paste. I couldn't think of a better way to write this.</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
=== It isn't just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won't use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
=== Experimenting with features ===<br />
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref><br />
<br />
=== Versioning the spec ===<br />
Most authors don't care about whether or not an implementation supports an entire, full specification; they just want to know "Can I use this feature in this browser?" So saying that all major implementations support much of CSS 2 to a high degree of correctness is useless for knowing if, say, the author can use display: run-in. In other words, the feature tables that you think are indicative of a problem are what web authors would actually use in real life.<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23306.html</ref><br />
<br />
<!--=== HTML5 the spec vs HTML5 the buzzword ===<br />
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23299.html<br />
--><br />
<br />
== Specific Elements ==<br />
<br />
=== Doctype ===<br />
Since HTML5 has moved to an unversioned model the doctype does not a have version number. It is necessary for legacy browsers that will switch to standards mode only when a doctype is present.<br />
<br />
=== Plaintext ===<br />
The &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
means that the sentence is to be read normally but the word "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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
<!--<br />
=== br and linebreaks ===<br />
--><br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5449Rationale2010-08-29T15:26:25Z<p>Variable: explain why doctype has no version and add a note-to-self about HTML5</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
=== It isn't just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won't use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
=== Experimenting with features ===<br />
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref><br />
<br />
<!--=== HTML5 the spec vs HTML5 the buzzword ===<br />
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23299.html<br />
--><br />
<br />
== Specific Elements ==<br />
<br />
=== Doctype ===<br />
Since HTML5 has moved to an unversioned model the doctype does not a have version number. It is necessary for legacy browsers that will switch to standards mode only when a doctype is present.<br />
<br />
=== Plaintext ===<br />
The &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
means that the sentence is to be read normally but the word "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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
<!--<br />
=== br and linebreaks ===<br />
--><br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5446Rationale2010-08-27T01:24:30Z<p>Variable: add note on experimental features. requires better references</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
=== It isn't just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won't use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
=== experimenting with features ===<br />
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
<!--<br />
=== br and linebreaks ===<br />
--><br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5445Rationale2010-08-27T01:05:44Z<p>Variable: </p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
=== It isn't just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won't use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
<!--<br />
=== br and linebreaks ===<br />
--><br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5444Rationale2010-08-27T01:04:50Z<p>Variable: add note to self to add discussion about br</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
=== It isn't just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won't use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5395Rationale2010-08-20T17:17:41Z<p>Variable: add paragraph about HTML users that are not browsers</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
=== It isn't just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won't use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5381Rationale2010-08-17T14:15:23Z<p>Variable: I want to write a paragraph for this before I make it live</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
5. "It isn't just browsers" - explain why sometimes elements and features are needed even when browsers won't use them. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can.<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5374Rationale2010-08-16T18:50:30Z<p>Variable: add note to self</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
5. "It isn't just browsers" - explain why sometimes elements and features are needed even when browsers won't use them. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can.<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5263Rationale2010-08-08T20:36:02Z<p>Variable: /* textarea */ add another reference for textarea</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
5. "It isn't just browsers" - explain why sometimes elements and features are needed even when browsers won't use them. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can.<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5123Rationale2010-08-02T00:30:33Z<p>Variable: added some info about defer and async.</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
5. "It isn't just browsers" - explain why sometimes elements and features are needed even when browsers won't use them. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can.<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5122Rationale2010-08-01T17:17:50Z<p>Variable: add yet another URL as a reference</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
5. "It isn't just browsers" - explain why sometimes elements and features are needed even when browsers won't use them. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can.<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5107Rationale2010-07-28T00:04:15Z<p>Variable: add note to self</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
5. "It isn't just browsers" - explain why sometimes elements and features are needed even when browsers won't use them. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can.<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5091Rationale2010-07-20T23:54:54Z<p>Variable: added beta text for one of the ML posts</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
5. "It isn't just browsers" - explain why sometimes elements and features are needed even when browsers won't use them. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can.<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5034Rationale2010-07-11T15:39:48Z<p>Variable: /* Other Pages */ added link to WHATWG FAQ. Section 5 specifically has lots of relevant materiel</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
5. "It isn't just browsers" - explain why sometimes elements and features are needed even when browsers won't use them. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can.<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5033Rationale2010-07-11T05:08:06Z<p>Variable: /* The "advert" tag */ change title for "advert" tag</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
5. "It isn't just browsers" - explain why sometimes elements and features are needed even when browsers won't use them. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can.<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5032Rationale2010-07-11T04:54:49Z<p>Variable: /* details element */</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
5. "It isn't just browsers" - explain why sometimes elements and features are needed even when browsers won't use them. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can.<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== The "advert" tag ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5031Rationale2010-07-11T04:52:03Z<p>Variable: added link to new page of rationale. added reference to new page</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
5. "It isn't just browsers" - explain why sometimes elements and features are needed even when browsers won't use them. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can.<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== The "advert" tag ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5030Rationale2010-07-11T04:46:24Z<p>Variable: </p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
5. "It isn't just browsers" - explain why sometimes elements and features are needed even when browsers won't use them. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can.<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== The "advert" tag ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5029Rationale2010-07-11T04:41:58Z<p>Variable: Added section that explains why a Javascript solution is not always a good objection to a new element</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== The "advert" tag ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5028Rationale2010-07-11T04:19:29Z<p>Variable: /* feature queries */</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== The "advert" tag ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5027Rationale2010-07-11T04:16:52Z<p>Variable: /* feature queries */ fixed formatting</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== The "advert" tag ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
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:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5026Rationale2010-07-11T04:16:23Z<p>Variable: added explanation for the mark element</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
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.<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== The "advert" tag ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
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:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref><ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5025Rationale2010-07-09T16:00:08Z<p>Variable: added hgroup section</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. add "mark" to the em/i/b/strong section<br />
5. Explain all the different uses of the header, hgroup, .... elements<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== The "advert" tag ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
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:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref><ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5024Rationale2010-07-09T15:38:28Z<p>Variable: added some more notes and information to the feature request section</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. add "mark" to the em/i/b/strong section<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== The "advert" tag ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
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:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref><ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5021Rationale2010-07-09T03:18:15Z<p>Variable: added feature queries section</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Why no feature queries<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== The "advert" tag ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
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:<br />
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.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5013Rationale2010-07-01T16:00:41Z<p>Variable: added some more info for the OVOV policy</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
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%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== The "advert" tag ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5007Rationale2010-06-29T19:37:24Z<p>Variable: </p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== The "advert" tag ===<br />
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.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5003Rationale2010-06-28T17:43:51Z<p>Variable: /* The "advert" tag */</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Failed proposals ==<br />
=== The "advert" tag ===<br />
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 <!-- I only found this mentioned in passing on an unrelated post on the mailing. I'm still looking for the original source --><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5002Rationale2010-06-28T17:40:59Z<p>Variable: /* Other Pages */ making text into link</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== The "advert" tag ==<br />
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 <!-- I only found this mentioned in passing on an unrelated post on the mailing. I'm still looking for the original source --><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=5001Rationale2010-06-28T17:40:01Z<p>Variable: added rationale for why there is no sandbox feature for html5</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== The "advert" tag ==<br />
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 <!-- I only found this mentioned in passing on an unrelated post on the mailing. I'm still looking for the original source --><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering] - earlier page started with the same purpose. <br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4996Rationale2010-06-27T02:34:36Z<p>Variable: notes to self</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. reasons for no sandbox on "html"<br />
3. Why the WHATWG version is unversioned and called HTML5...<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== The "advert" tag ==<br />
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 <!-- I only found this mentioned in passing on an unrelated post on the mailing. I'm still looking for the original source --><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering] - earlier page started with the same purpose. <br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4922Rationale2010-06-10T17:27:03Z<p>Variable: /* textarea */</p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
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.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== The "advert" tag ==<br />
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 <!-- I only found this mentioned in passing on an unrelated post on the mailing. I'm still looking for the original source --><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering] - earlier page started with the same purpose. <br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4921Rationale2010-06-10T17:25:29Z<p>Variable: /* textarea */</p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
The text area defaults to wordwrap soft. The attribute @wrap can have one of the following values: soft, hard, or off.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref> "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== The "advert" tag ==<br />
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 <!-- I only found this mentioned in passing on an unrelated post on the mailing. I'm still looking for the original source --><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering] - earlier page started with the same purpose. <br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4920Rationale2010-06-10T17:23:56Z<p>Variable: </p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
The text area defaults to wordwrap ____. The attribute @wrap can have one of the following values: ____.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref> "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== The "advert" tag ==<br />
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 <!-- I only found this mentioned in passing on an unrelated post on the mailing. I'm still looking for the original source --><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering] - earlier page started with the same purpose. <br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4916Rationale2010-06-07T14:42:24Z<p>Variable: </p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== The "advert" tag ==<br />
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 <!-- I only found this mentioned in passing on an unrelated post on the mailing. I'm still looking for the original source --><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering] - earlier page started with the same purpose. <br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4901Rationale2010-05-23T10:30:58Z<p>Variable: /* Specific Elements */ need to confirm longdesc ...</p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering] - earlier page started with the same purpose. <br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4900Rationale2010-05-20T21:31:09Z<p>Variable: </p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering] - earlier page started with the same purpose. <br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4896Rationale2010-05-14T14:28:51Z<p>Variable: </p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
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 <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>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.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4890Rationale2010-05-10T21:12:38Z<p>Variable: /* Why the complications for script elements */ change of title to fit page format</p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
- temporary stub -<ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><br />
<br />
=== script - rules for parsing ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4885Rationale2010-05-10T16:48:47Z<p>Variable: merge notes and "Other Pages"</p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hixie</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
- temporary stub -<ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><br />
<br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4884Rationale2010-05-10T16:45:38Z<p>Variable: temporary</p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hixie</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
=== IMG tag & alt text ===<br />
- temporary stub -<ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><br />
<br />
== Notes ==<br />
* <code>&lt;meta http-equiv=content-language></code>: http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html<br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4883Rationale2010-05-10T13:53:00Z<p>Variable: /* B, I, EM, and STRONG */</p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hixie</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
== Notes ==<br />
* <code>&lt;meta http-equiv=content-language></code>: http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html<br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4882Rationale2010-05-10T13:40:37Z<p>Variable: /* B, U, EM, and STRONG */ add the b/i/em/strong stuff</p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hixie</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats; are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
<br />
== Notes ==<br />
* <code>&lt;meta http-equiv=content-language></code>: http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html<br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4881Rationale2010-05-10T13:39:29Z<p>Variable: /* B, U, EM, and STRONG */</p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hixie</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, U, EM, and STRONG ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats; are &lt;i&gt;cute&lt;/i&gt; animals.<br />
means that the word cute is meant to be read in a different tone (for example sarcasm)<br />
<br />
== Notes ==<br />
* <code>&lt;meta http-equiv=content-language></code>: http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html<br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
<br />
== References ==<br />
<references/></div>Variablehttps://wiki.whatwg.org/index.php?title=Rationale&diff=4865Rationale2010-05-06T16:22:50Z<p>Variable: add stub</p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
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.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> 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).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hixie</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. 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.<br />
<br />
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.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, U, EM, and STRONG ===<br />
-- temporary stub --<br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2_versus_HTML5]]<br />
<br />
== References ==<br />
<references/></div>Variable