https://wiki.whatwg.org/api.php?action=feedcontributions&user=Yroc&feedformat=atomWHATWG Wiki - User contributions [en]2024-03-29T08:50:22ZUser contributionsMediaWiki 1.39.3https://wiki.whatwg.org/index.php?title=Rationale&diff=9965Rationale2015-07-16T18:26:00Z<p>Yroc: /* Already-implemented features */ General rewording for clarification</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [https://html.spec.whatwg.org//multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
In the past, the contents of the spec tended to be determined by browsers&rsquo; <i>de facto</i> feature set. After all, one of the main purposes of the spec is to describe reality (regardless of what the spec editor, members, and contributors think). Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec. That is to say, in the past, browsers tended to dictate what was in the spec, whereas today, it's the converse.<br />
<br />
Thus, the spec must include all already-implemented features . A feature may be moved to the obsolete section if there is consensus that the feature should not be used in new content.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything?<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-October/041037.html</ref> ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order):<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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&rsquo;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&rsquo;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&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; 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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>https://html.spec.whatwg.org//multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>https://html.spec.whatwg.org//multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>https://html.spec.whatwg.org//multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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>https://html.spec.whatwg.org//#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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 [https://html.spec.whatwg.org//multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [https://html.spec.whatwg.org//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 [https://html.spec.whatwg.org//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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There is: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrated by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a grouping-type element for description lists to represent individual name-value groups (e.g., a &ldquo;<code>dli</code>&rdquo; element)? It would make styling as well as adding microdata to individual groups much easier.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2013-October/001245.html</ref> ===<br />
<pre>On Sun, 30 Dec 2012, Brian Tremblay wrote:<br />
><br />
> I'm using <dl> markup for a restaurant menu, and have added product<br />
> microdata markup from schema.org. Because items in a <dl> are defined<br />
> implicitly -- <dt> element(s) followed by <dd> element(s) -- there's no<br />
> easy way to scope them individually. What I'm left doing is adding 2 id<br />
> attributes for each menu item, and using itemref:<br />
><br />
> http://tsmchughs.com/test/dessert<br />
<br />
That's one way to do it, yeah.<br />
<br />
<br />
> If we had a <dli> element, to scope each item in a description list, the<br />
> markup needed to add microdata (or microformats) would be much simpler.<br />
><br />
> [...]<br />
><br />
> Therefore, I think we need a <dli> element. This has come up in the<br />
> past. If I understand correctly, the editor has declined, saying that<br />
> the need for <dli> is only to make styling easier, so the problem should<br />
> be solved in css. But I think the problem here is not styling, it's<br />
> creating natural, discrete items in a description list, which might be<br />
> used for styling, or for microdata, or perhaps for other reasons which I<br />
> haven't thought of. Without <dli>, use of <dl> becomes much harder to<br />
> use even though it may be the best markup choice.<br />
<br />
You're right that this is a much better reason for adding a <dl> grouping<br />
element.<br />
<br />
Unfortunately, lack of use cases isn't the only reason we haven't added<br />
it. One of the other reasons is that it would require parser changes. For<br />
example, take this:<br />
<br />
<dl><br />
<di><br />
<dt>a<br />
<dd>b<br />
</di><br />
<di><br />
<dt>c<br />
<dd>d<br />
</di><br />
</dl><br />
<br />
This looks like it should work, but right now it gets parsed as:<br />
<br />
<dl><br />
<di><br />
<dt>a</dt><br />
<dd>b<br />
<di><br />
<dt>c</dt><br />
<dd>d</dd><br />
</di><br />
</dd><br />
</di><br />
</dl><br />
<br />
(Another reason is that it makes the processing model for <dl> more<br />
complicated for tools that want to process groups of items in <dl>s.)<br />
<br />
<br />
Still, you make a very good point, that for microdata, the lack of<br />
grouping here is a more serious issue than styling-system limitations.<br />
<br />
I guess it comes down to a question of how common microdata on <dl> groups<br />
is, vs how painful changing the parser and legacy tools would be. It's<br />
probably a close call (not much usage, but not a huge amount of pain).</pre><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
=== Why aren&rsquo;t authors allowed to make 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9434Rationale2014-01-22T23:45:03Z<p>Yroc: /* Why isn&rsquo;t there an element for user comments? (e.g., &lt;comment&gt;) */ grammar</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything?<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-October/041037.html</ref> ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order):<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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&rsquo;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&rsquo;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&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; 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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There is: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrated by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a grouping-type element for description lists to represent individual name-value groups (e.g., a &ldquo;<code>dli</code>&rdquo; element)? It would make styling as well as adding microdata to individual groups much easier.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2013-October/001245.html</ref> ===<br />
<pre>On Sun, 30 Dec 2012, Brian Tremblay wrote:<br />
><br />
> I'm using <dl> markup for a restaurant menu, and have added product<br />
> microdata markup from schema.org. Because items in a <dl> are defined<br />
> implicitly -- <dt> element(s) followed by <dd> element(s) -- there's no<br />
> easy way to scope them individually. What I'm left doing is adding 2 id<br />
> attributes for each menu item, and using itemref:<br />
><br />
> http://tsmchughs.com/test/dessert<br />
<br />
That's one way to do it, yeah.<br />
<br />
<br />
> If we had a <dli> element, to scope each item in a description list, the<br />
> markup needed to add microdata (or microformats) would be much simpler.<br />
><br />
> [...]<br />
><br />
> Therefore, I think we need a <dli> element. This has come up in the<br />
> past. If I understand correctly, the editor has declined, saying that<br />
> the need for <dli> is only to make styling easier, so the problem should<br />
> be solved in css. But I think the problem here is not styling, it's<br />
> creating natural, discrete items in a description list, which might be<br />
> used for styling, or for microdata, or perhaps for other reasons which I<br />
> haven't thought of. Without <dli>, use of <dl> becomes much harder to<br />
> use even though it may be the best markup choice.<br />
<br />
You're right that this is a much better reason for adding a <dl> grouping<br />
element.<br />
<br />
Unfortunately, lack of use cases isn't the only reason we haven't added<br />
it. One of the other reasons is that it would require parser changes. For<br />
example, take this:<br />
<br />
<dl><br />
<di><br />
<dt>a<br />
<dd>b<br />
</di><br />
<di><br />
<dt>c<br />
<dd>d<br />
</di><br />
</dl><br />
<br />
This looks like it should work, but right now it gets parsed as:<br />
<br />
<dl><br />
<di><br />
<dt>a</dt><br />
<dd>b<br />
<di><br />
<dt>c</dt><br />
<dd>d</dd><br />
</di><br />
</dd><br />
</di><br />
</dl><br />
<br />
(Another reason is that it makes the processing model for <dl> more<br />
complicated for tools that want to process groups of items in <dl>s.)<br />
<br />
<br />
Still, you make a very good point, that for microdata, the lack of<br />
grouping here is a more serious issue than styling-system limitations.<br />
<br />
I guess it comes down to a question of how common microdata on <dl> groups<br />
is, vs how painful changing the parser and legacy tools would be. It's<br />
probably a close call (not much usage, but not a huge amount of pain).</pre><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
=== Why aren&rsquo;t authors allowed to make 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9433Rationale2014-01-22T23:42:12Z<p>Yroc: /* Modifying existing semantics */ removed reference to specific HTML version (HTML 4 -> HTML)</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything?<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-October/041037.html</ref> ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order):<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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&rsquo;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&rsquo;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&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; 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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrated by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a grouping-type element for description lists to represent individual name-value groups (e.g., a &ldquo;<code>dli</code>&rdquo; element)? It would make styling as well as adding microdata to individual groups much easier.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2013-October/001245.html</ref> ===<br />
<pre>On Sun, 30 Dec 2012, Brian Tremblay wrote:<br />
><br />
> I'm using <dl> markup for a restaurant menu, and have added product<br />
> microdata markup from schema.org. Because items in a <dl> are defined<br />
> implicitly -- <dt> element(s) followed by <dd> element(s) -- there's no<br />
> easy way to scope them individually. What I'm left doing is adding 2 id<br />
> attributes for each menu item, and using itemref:<br />
><br />
> http://tsmchughs.com/test/dessert<br />
<br />
That's one way to do it, yeah.<br />
<br />
<br />
> If we had a <dli> element, to scope each item in a description list, the<br />
> markup needed to add microdata (or microformats) would be much simpler.<br />
><br />
> [...]<br />
><br />
> Therefore, I think we need a <dli> element. This has come up in the<br />
> past. If I understand correctly, the editor has declined, saying that<br />
> the need for <dli> is only to make styling easier, so the problem should<br />
> be solved in css. But I think the problem here is not styling, it's<br />
> creating natural, discrete items in a description list, which might be<br />
> used for styling, or for microdata, or perhaps for other reasons which I<br />
> haven't thought of. Without <dli>, use of <dl> becomes much harder to<br />
> use even though it may be the best markup choice.<br />
<br />
You're right that this is a much better reason for adding a <dl> grouping<br />
element.<br />
<br />
Unfortunately, lack of use cases isn't the only reason we haven't added<br />
it. One of the other reasons is that it would require parser changes. For<br />
example, take this:<br />
<br />
<dl><br />
<di><br />
<dt>a<br />
<dd>b<br />
</di><br />
<di><br />
<dt>c<br />
<dd>d<br />
</di><br />
</dl><br />
<br />
This looks like it should work, but right now it gets parsed as:<br />
<br />
<dl><br />
<di><br />
<dt>a</dt><br />
<dd>b<br />
<di><br />
<dt>c</dt><br />
<dd>d</dd><br />
</di><br />
</dd><br />
</di><br />
</dl><br />
<br />
(Another reason is that it makes the processing model for <dl> more<br />
complicated for tools that want to process groups of items in <dl>s.)<br />
<br />
<br />
Still, you make a very good point, that for microdata, the lack of<br />
grouping here is a more serious issue than styling-system limitations.<br />
<br />
I guess it comes down to a question of how common microdata on <dl> groups<br />
is, vs how painful changing the parser and legacy tools would be. It's<br />
probably a close call (not much usage, but not a huge amount of pain).</pre><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
=== Why aren&rsquo;t authors allowed to make 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9331Rationale2013-10-16T18:59:53Z<p>Yroc: /* Why isn&rsquo;t there a grouping-type element for description lists to represent individual name-value groups (e.g., a &ldquo;dli&rdquo; element)? It would make styling as well as adding microdata to individual groups much easier. */ Added referen</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything?<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-October/041037.html</ref> ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order):<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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&rsquo;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&rsquo;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&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; 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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrated by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a grouping-type element for description lists to represent individual name-value groups (e.g., a &ldquo;<code>dli</code>&rdquo; element)? It would make styling as well as adding microdata to individual groups much easier.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2013-October/001245.html</ref> ===<br />
<pre>On Sun, 30 Dec 2012, Brian Tremblay wrote:<br />
><br />
> I'm using <dl> markup for a restaurant menu, and have added product<br />
> microdata markup from schema.org. Because items in a <dl> are defined<br />
> implicitly -- <dt> element(s) followed by <dd> element(s) -- there's no<br />
> easy way to scope them individually. What I'm left doing is adding 2 id<br />
> attributes for each menu item, and using itemref:<br />
><br />
> http://tsmchughs.com/test/dessert<br />
<br />
That's one way to do it, yeah.<br />
<br />
<br />
> If we had a <dli> element, to scope each item in a description list, the<br />
> markup needed to add microdata (or microformats) would be much simpler.<br />
><br />
> [...]<br />
><br />
> Therefore, I think we need a <dli> element. This has come up in the<br />
> past. If I understand correctly, the editor has declined, saying that<br />
> the need for <dli> is only to make styling easier, so the problem should<br />
> be solved in css. But I think the problem here is not styling, it's<br />
> creating natural, discrete items in a description list, which might be<br />
> used for styling, or for microdata, or perhaps for other reasons which I<br />
> haven't thought of. Without <dli>, use of <dl> becomes much harder to<br />
> use even though it may be the best markup choice.<br />
<br />
You're right that this is a much better reason for adding a <dl> grouping<br />
element.<br />
<br />
Unfortunately, lack of use cases isn't the only reason we haven't added<br />
it. One of the other reasons is that it would require parser changes. For<br />
example, take this:<br />
<br />
<dl><br />
<di><br />
<dt>a<br />
<dd>b<br />
</di><br />
<di><br />
<dt>c<br />
<dd>d<br />
</di><br />
</dl><br />
<br />
This looks like it should work, but right now it gets parsed as:<br />
<br />
<dl><br />
<di><br />
<dt>a</dt><br />
<dd>b<br />
<di><br />
<dt>c</dt><br />
<dd>d</dd><br />
</di><br />
</dd><br />
</di><br />
</dl><br />
<br />
(Another reason is that it makes the processing model for <dl> more<br />
complicated for tools that want to process groups of items in <dl>s.)<br />
<br />
<br />
Still, you make a very good point, that for microdata, the lack of<br />
grouping here is a more serious issue than styling-system limitations.<br />
<br />
I guess it comes down to a question of how common microdata on <dl> groups<br />
is, vs how painful changing the parser and legacy tools would be. It's<br />
probably a close call (not much usage, but not a huge amount of pain).</pre><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
=== Why aren&rsquo;t authors allowed to make 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9330Rationale2013-10-16T18:54:47Z<p>Yroc: /* custom HTML elements */ Rephrased heading in the form of a question</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything?<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-October/041037.html</ref> ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order):<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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&rsquo;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&rsquo;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&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; 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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrated by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a grouping-type element for description lists to represent individual name-value groups (e.g., a &ldquo;<code>dli</code>&rdquo; element)? It would make styling as well as adding microdata to individual groups much easier. ===<br />
<pre>On Sun, 30 Dec 2012, Brian Tremblay wrote:<br />
><br />
> I'm using <dl> markup for a restaurant menu, and have added product<br />
> microdata markup from schema.org. Because items in a <dl> are defined<br />
> implicitly -- <dt> element(s) followed by <dd> element(s) -- there's no<br />
> easy way to scope them individually. What I'm left doing is adding 2 id<br />
> attributes for each menu item, and using itemref:<br />
><br />
> http://tsmchughs.com/test/dessert<br />
<br />
That's one way to do it, yeah.<br />
<br />
<br />
> If we had a <dli> element, to scope each item in a description list, the<br />
> markup needed to add microdata (or microformats) would be much simpler.<br />
><br />
> [...]<br />
><br />
> Therefore, I think we need a <dli> element. This has come up in the<br />
> past. If I understand correctly, the editor has declined, saying that<br />
> the need for <dli> is only to make styling easier, so the problem should<br />
> be solved in css. But I think the problem here is not styling, it's<br />
> creating natural, discrete items in a description list, which might be<br />
> used for styling, or for microdata, or perhaps for other reasons which I<br />
> haven't thought of. Without <dli>, use of <dl> becomes much harder to<br />
> use even though it may be the best markup choice.<br />
<br />
You're right that this is a much better reason for adding a <dl> grouping<br />
element.<br />
<br />
Unfortunately, lack of use cases isn't the only reason we haven't added<br />
it. One of the other reasons is that it would require parser changes. For<br />
example, take this:<br />
<br />
<dl><br />
<di><br />
<dt>a<br />
<dd>b<br />
</di><br />
<di><br />
<dt>c<br />
<dd>d<br />
</di><br />
</dl><br />
<br />
This looks like it should work, but right now it gets parsed as:<br />
<br />
<dl><br />
<di><br />
<dt>a</dt><br />
<dd>b<br />
<di><br />
<dt>c</dt><br />
<dd>d</dd><br />
</di><br />
</dd><br />
</di><br />
</dl><br />
<br />
(Another reason is that it makes the processing model for <dl> more<br />
complicated for tools that want to process groups of items in <dl>s.)<br />
<br />
<br />
Still, you make a very good point, that for microdata, the lack of<br />
grouping here is a more serious issue than styling-system limitations.<br />
<br />
I guess it comes down to a question of how common microdata on <dl> groups<br />
is, vs how painful changing the parser and legacy tools would be. It's<br />
probably a close call (not much usage, but not a huge amount of pain).</pre><br />
<br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
=== Why aren&rsquo;t authors allowed to make 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9329Rationale2013-10-16T18:50:08Z<p>Yroc: /* But comments are not articles */ grammatical correction</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything?<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-October/041037.html</ref> ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order):<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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&rsquo;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&rsquo;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&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; 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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrated by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a grouping-type element for description lists to represent individual name-value groups (e.g., a &ldquo;<code>dli</code>&rdquo; element)? It would make styling as well as adding microdata to individual groups much easier. ===<br />
<pre>On Sun, 30 Dec 2012, Brian Tremblay wrote:<br />
><br />
> I'm using <dl> markup for a restaurant menu, and have added product<br />
> microdata markup from schema.org. Because items in a <dl> are defined<br />
> implicitly -- <dt> element(s) followed by <dd> element(s) -- there's no<br />
> easy way to scope them individually. What I'm left doing is adding 2 id<br />
> attributes for each menu item, and using itemref:<br />
><br />
> http://tsmchughs.com/test/dessert<br />
<br />
That's one way to do it, yeah.<br />
<br />
<br />
> If we had a <dli> element, to scope each item in a description list, the<br />
> markup needed to add microdata (or microformats) would be much simpler.<br />
><br />
> [...]<br />
><br />
> Therefore, I think we need a <dli> element. This has come up in the<br />
> past. If I understand correctly, the editor has declined, saying that<br />
> the need for <dli> is only to make styling easier, so the problem should<br />
> be solved in css. But I think the problem here is not styling, it's<br />
> creating natural, discrete items in a description list, which might be<br />
> used for styling, or for microdata, or perhaps for other reasons which I<br />
> haven't thought of. Without <dli>, use of <dl> becomes much harder to<br />
> use even though it may be the best markup choice.<br />
<br />
You're right that this is a much better reason for adding a <dl> grouping<br />
element.<br />
<br />
Unfortunately, lack of use cases isn't the only reason we haven't added<br />
it. One of the other reasons is that it would require parser changes. For<br />
example, take this:<br />
<br />
<dl><br />
<di><br />
<dt>a<br />
<dd>b<br />
</di><br />
<di><br />
<dt>c<br />
<dd>d<br />
</di><br />
</dl><br />
<br />
This looks like it should work, but right now it gets parsed as:<br />
<br />
<dl><br />
<di><br />
<dt>a</dt><br />
<dd>b<br />
<di><br />
<dt>c</dt><br />
<dd>d</dd><br />
</di><br />
</dd><br />
</di><br />
</dl><br />
<br />
(Another reason is that it makes the processing model for <dl> more<br />
complicated for tools that want to process groups of items in <dl>s.)<br />
<br />
<br />
Still, you make a very good point, that for microdata, the lack of<br />
grouping here is a more serious issue than styling-system limitations.<br />
<br />
I guess it comes down to a question of how common microdata on <dl> groups<br />
is, vs how painful changing the parser and legacy tools would be. It's<br />
probably a close call (not much usage, but not a huge amount of pain).</pre><br />
<br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9328Rationale2013-10-16T18:47:06Z<p>Yroc: /* Rejected proposals */ Proposed dli 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 />
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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything?<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-October/041037.html</ref> ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order):<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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&rsquo;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&rsquo;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&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; 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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a grouping-type element for description lists to represent individual name-value groups (e.g., a &ldquo;<code>dli</code>&rdquo; element)? It would make styling as well as adding microdata to individual groups much easier. ===<br />
<pre>On Sun, 30 Dec 2012, Brian Tremblay wrote:<br />
><br />
> I'm using <dl> markup for a restaurant menu, and have added product<br />
> microdata markup from schema.org. Because items in a <dl> are defined<br />
> implicitly -- <dt> element(s) followed by <dd> element(s) -- there's no<br />
> easy way to scope them individually. What I'm left doing is adding 2 id<br />
> attributes for each menu item, and using itemref:<br />
><br />
> http://tsmchughs.com/test/dessert<br />
<br />
That's one way to do it, yeah.<br />
<br />
<br />
> If we had a <dli> element, to scope each item in a description list, the<br />
> markup needed to add microdata (or microformats) would be much simpler.<br />
><br />
> [...]<br />
><br />
> Therefore, I think we need a <dli> element. This has come up in the<br />
> past. If I understand correctly, the editor has declined, saying that<br />
> the need for <dli> is only to make styling easier, so the problem should<br />
> be solved in css. But I think the problem here is not styling, it's<br />
> creating natural, discrete items in a description list, which might be<br />
> used for styling, or for microdata, or perhaps for other reasons which I<br />
> haven't thought of. Without <dli>, use of <dl> becomes much harder to<br />
> use even though it may be the best markup choice.<br />
<br />
You're right that this is a much better reason for adding a <dl> grouping<br />
element.<br />
<br />
Unfortunately, lack of use cases isn't the only reason we haven't added<br />
it. One of the other reasons is that it would require parser changes. For<br />
example, take this:<br />
<br />
<dl><br />
<di><br />
<dt>a<br />
<dd>b<br />
</di><br />
<di><br />
<dt>c<br />
<dd>d<br />
</di><br />
</dl><br />
<br />
This looks like it should work, but right now it gets parsed as:<br />
<br />
<dl><br />
<di><br />
<dt>a</dt><br />
<dd>b<br />
<di><br />
<dt>c</dt><br />
<dd>d</dd><br />
</di><br />
</dd><br />
</di><br />
</dl><br />
<br />
(Another reason is that it makes the processing model for <dl> more<br />
complicated for tools that want to process groups of items in <dl>s.)<br />
<br />
<br />
Still, you make a very good point, that for microdata, the lack of<br />
grouping here is a more serious issue than styling-system limitations.<br />
<br />
I guess it comes down to a question of how common microdata on <dl> groups<br />
is, vs how painful changing the parser and legacy tools would be. It's<br />
probably a close call (not much usage, but not a huge amount of pain).</pre><br />
<br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9327Rationale2013-10-16T18:08:12Z<p>Yroc: /* Why is everything else around us developing so fast, but the web is so slow to adopt anything? */ Added 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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything?<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-October/041037.html</ref> ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order):<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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&rsquo;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&rsquo;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&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; 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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9324Rationale2013-10-12T20:13:54Z<p>Yroc: /* Why is everything else around us developing so fast, but the web is so slow to adopt anything? */ removed extraneous 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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything? ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order):<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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&rsquo;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&rsquo;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&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; 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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9323Rationale2013-10-12T20:12:58Z<p>Yroc: /* General Rationale */ New heading added "Why is everything else around us developing so fast, but the web is so slow to adopt anything?"</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything? ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order)<ref>:<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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&rsquo;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&rsquo;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&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; 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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9322Rationale2013-10-12T19:58:27Z<p>Yroc: /* Member and contributor feedback */ removal of extraneous word, "feedback" defined more specifically</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9321Rationale2013-10-12T19:46:23Z<p>Yroc: /* In overall terms, what determines what&rsquo;s in the spec? */ Added subheadings</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor also takes into account member and contributor feedback. If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9061Rationale2013-03-05T20:40:57Z<p>Yroc: /* Why isn&rsquo;t there a dedicated element for advertisements? (e.g., &lt;ad&gt;, or &lt;advert&gt;, or &lt;banner&gt;, or whatever) */ inserted missing closing </pre></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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
When adding features to the spec, the editor also takes into account member and contributor feedback. If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9060Rationale2013-03-05T20:34:36Z<p>Yroc: /* Why isn&rsquo;t there a dedicated element for advertisements? (e.g., &lt;ad&gt;, or &lt;advert&gt;, or &lt;banner&gt;, or whatever) */ Added dialog from newsgroup</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
When adding features to the spec, the editor also takes into account member and contributor feedback. If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.<br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9059Rationale2013-03-05T20:24:35Z<p>Yroc: /* Why isn&rsquo;t there a dedicated element for advertisements? (e.g., &lt;ad&gt;, or &lt;advert&gt;, or &lt;banner&gt;, or whatever) */ styling change</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
When adding features to the spec, the editor also takes into account member and contributor feedback. If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors:<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
<pre>>I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9058Rationale2013-03-05T20:23:47Z<p>Yroc: /* Why isn&rsquo;t there a dedicated element for advertisements? (e.g., &lt;ad&gt; or &lt;advert&gt;) */ Added relevant dialog from mailing list</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
When adding features to the spec, the editor also takes into account member and contributor feedback. If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors:<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
<pre>I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9057Rationale2013-03-05T20:14:41Z<p>Yroc: /* Why isn&rsquo;t there a dedicated element for advertisements? (e.g., &lt;ad&gt; or &lt;advert&gt;) */ Added relevant dialog from mailing list</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
When adding features to the spec, the editor also takes into account member and contributor feedback. If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
<pre>I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For<ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=FAQ&diff=9039FAQ2013-02-23T15:52:42Z<p>Yroc: /* How can I keep track of changes to the spec? */ grammer cleanup</p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is the HTML standard, which also includes Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events. Occasionally, specifications outside WHATWG space are discussed on the WHATWG mailing list; recent examples include a crypto API, HTML editing APIs, and the UndoManager specification.<br />
<br />
In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] or its alternatives will bring us.<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
=== Is participation free? === <br />
<br />
Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C HTML WG] by going through the slightly longer application process.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).<br />
<br />
This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.<br />
<br />
There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.<br />
<br />
Currently the editor is Ian Hickson.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or the editor of the [http://www.whatwg.org/specs/ relevant spec]; for HTML, that's ian@hixie.ch. All feedback on the HTML spec will receive a reply in due course.<br />
<br />
'''If you want feedback to be dealt with faster than "eventually", e.g. because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editor know''' by either e-mailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (For HTML, Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}Is there a process for removing bad ideas from a specification? ===<br />
<br />
There are several processes by which we trim weeds from the specifications.<br />
<br />
* Occasionally, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.<br />
<br />
* Anyone can ask for a feature to be removed; such feedback is considered like all other feedback and is based on the merits of the arguments put forward.<br />
<br />
* If browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential or fundamentally wrong or damaging, then, after due consideration, features will be removed.<br />
<br />
Removing features is a critical part of spec development.<br />
<br />
=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}Is there a process for adding new features to a specification? ===<br />
<br />
The process is rather informal, but basically boils down to this:<br />
<br />
# Forget about the particular solution you have in mind! Solution time is later!<br />
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html<br />
# Get more people involved. Send your use cases and their requirements to [http://www.whatwg.org/mailing-list#specs whatwg@whatwg.org]. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.<br />
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)<br />
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, again to [http://www.whatwg.org/mailing-list#specs whatwg@whatwg.org]. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!<br />
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).<br />
# Ask the spec's editor to put that solution in the spec. Likely your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.<br />
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.<br />
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.<br />
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).<br />
<br />
If the idea survives the above design process, the spec will be eventually updated to reflect the new design. Implementations will then be updated to reflect the new design (if they aren't, that indicates the new design is not good, and it will be reworked or removed). The spec will be updated to fix the many problems discovered by authors and implementors, over a period of several years, as more authors and implementors are exposed to the design. Eventually, a number of provably interoperable implementations are deployed. At this point development of the feature is somewhat frozen.<br />
<br />
Writing a comprehensive test suite is also an important step, which can even start before implementations start being written to the spec. We don't yet have a good story with respect to test suites, sadly. If you want to help us out, let the mailing list know! Be aware, though, it's a lot of work.<br />
<br />
=== Should I send new proposed text when I have a suggestion? ===<br />
<br />
Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.<br />
<br />
=== What does "Living Standard" mean? ===<br />
<br />
The WHATWG specifications are described as Living Standards. This means that they are standards that are continuously updated as they receive feedback, either from Web designers, browser vendors, tool vendors, or indeed any other interested party. It also means that new features get added to them over time, at a rate intended to keep the specifications a little ahead of the implementations but not so far ahead that the implementations give up.<br />
<br />
Despite the continuous maintenance, or maybe we should say ''as part'' of the continuing maintenance, a significant effort is placed on getting the specifications and the implementations to converge — the parts of the specification that are mature and stable are not changed willy nilly. Maintenance means that the days where the specifications are brought down from the mountain and remain forever locked, even if it turns out that all the browsers do something else, or even if it turns out that the specification left some detail out and the browsers all disagree on how to implement it, are gone. Instead, we now make sure to update the specifications to be detailed enough that all the implementations (not just browsers, of course) can do the same thing. Instead of ignoring what the browsers do, we fix the spec to match what the browsers do. Instead of leaving the specification ambiguous, we fix the the specification to define how things work.<br />
<br />
=== Does that mean the specification can change at any time? ===<br />
<br />
The specification does not change arbitrarily: we are extremely careful! As parts of the specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specification is never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
You can see which parts of the spec are stable and which are not from the status annotations in the left margin.<br />
<br />
In practice, implementations all follow the latest specification drafts anyway, not the so-called "finished" snapshots. The problem with following a snapshot is that you end up following something that is ''known to be wrong''. That's obviously not the way to get interoperability! This has in fact been a real problem at the W3C, where mistakes are found and fixed in the editors' drafts of specifications, but implementors who aren't fully engaged in the process go and implement obsolete snapshots instead, including those bugs, without realising the problems, and resulting in differences between the browsers.<br />
<br />
=== Will future browsers have any idea what older HTML documents mean? ===<br />
<br />
Browsers do not implement HTML+, HTML2, HTML3.2 HTML4, HTML4.01, etc, as separate versions. They all just have a single implementation that covers all these versions at once. That is what the WHATWG HTML specification defines: how to write a browser (or other implementation) that handles ''all previous versions of HTML'', as well as all the latest features.<br />
<br />
One of the main goals of the HTML specification and the WHATWG effort as a whole is to make it possible for archeologists hundreds of years from now to write a browser and view HTML content, regardless of when it was written. Making sure that we handle all documents is one of our most important goals. Not having versions does not preclude this; indeed it makes it significantly easier.<br />
<br />
=== How are developers to determine when certain parts of their pages will become invalid? ===<br />
<br />
It shouldn't matter if and when old pages become invalid.<br />
<br />
Validity (more often referred to as document conformance in the WHATWG) is a quality assurance tool to help authors avoid mistakes. We don't make things non-conforming (invalid) for the sake of it, we use conformance as a guide for developers to help them avoid bad practices or mistakes (like typos). So there's not really any need to worry about whether old pages are conforming or not, it's only helpful when you're writing a new page, and it's always most helpful to have the latest advice. It wouldn't be useful to check for compliance against last week's rules, for instance. After all, we fixed mistakes in those rules this week!<br />
<br />
== HTML5 ==<br />
<br />
=== What is HTML5? === <br />
<br />
[http://www.whatwg.org/specs/web-apps/current-work/ HTML] is the main focus of the WHATWG community. HTML5 is a snapshot of HTML, which is being worked on by the WHATWG community and also the W3C HTML Working Group.<br />
<br />
HTML5 is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML and XML (XHTML) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.<br />
<br />
Going forward, the WHATWG is just working on "HTML", without worrying about version numbers. When people talk about HTML5 in the context of the WHATWG, they usually mean just "the latest work on HTML", not necessarily a specific version. For more details, see the section called [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How can I keep track of changes to the spec? === <br />
<br />
There are a number of ways to track changes to the spec:<br />
<br />
* The Twitter feed: http://twitter.com/WHATWG (non-editorial changes only)<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon are maintaining a document that gives a high-level overview of changes to HTML over the last decade or so, as well as occasionally listing changes between versions a few months apart: http://dev.w3.org/html5/html4-differences/<br />
<br />
* The W3C provide a Web view of their CVS mirror of the HTML5 spec: http://dev.w3.org/cvsweb/html5/spec/Overview.html<br />
<br />
* The W3C provide diff-marked HTML versions for each change that affect the W3C copy of the spec by e-mail: http://lists.w3.org/Archives/Public/public-html-diffs/latest<br />
<br />
=== What are the various versions of the spec? ===<br />
<br />
All active work at WHATWG is gathered in the HTML Standard. It is available in two forms: [http://www.whatwg.org/specs/web-apps/current-work/ single-page] (''very large'') and '''[http://whatwg.org/C multi-page]'''.<br />
<br />
Different parts of this specification are also published at the W3C as smaller snapshots.<br />
<br />
The following table lists in the individual specifications included:<br />
<br />
{| class="wikitable" border=1 cellpadding=3 cellspacing=0<br />
|-<br />
!<br />
! Sections of the WHATWG specification<br />
! Corresponding W3C specifications<br />
|-<br />
! HTML, DOM HTML, and XHTML<br />
| [http://www.whatwg.org/specs/web-apps/current-work/ Single-page], [http://whatwg.org/C multi-page]<br />
| Subset as [http://dev.w3.org/html5/spec/Overview.html single-page], [http://dev.w3.org/html5/spec/ multi-page] (HTML WG)<br />
|-<br />
! Microdata<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata Microdata]<br />
| [http://dev.w3.org/html5/md/ Microdata] (HTML WG)<br />
|-<br />
! Canvas 2D Context<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext The 2D Context]<br />
| [http://dev.w3.org/html5/2dcontext/ 2D Context] (HTML WG)<br />
|-<br />
! window.postMessage()<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages Cross-document messaging]<br />
|rowspan=2| [http://dev.w3.org/html5/postmsg/ HTML5 Web Messaging] (WebApps WG)<br />
|-<br />
! MessagePort<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#channel-messaging Channel messaging]<br />
|-<br />
! Web Workers<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html Web Workers]<br />
| [http://dev.w3.org/html5/workers/ Web Workers] (WebApps WG)<br />
|-<br />
! Web Storage<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.html Web Storage]<br />
| [http://dev.w3.org/html5/webstorage/ Web Storage] (WebApps WG)<br />
|-<br />
! Web Sockets API<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html Web Sockets]<br />
| [http://dev.w3.org/html5/websockets/ Web Sockets API] (WebApps WG)<br />
|-<br />
! Server-Sent Events<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#server-sent-events Server-sent Events]<br />
| [http://dev.w3.org/html5/eventsource/ Server-sent Events] (WebApps WG)<br />
|}<br />
<br />
Web SQL Database no longer exists. The Web Socket Protocol specification is now done entirely by the IETF. The PeerConnection API has been taken over by the W3C.<br />
<br />
All of the above are generated from one [http://www.whatwg.org/specs/web-apps/current-work/source source document].<br />
<br />
=== Are there versions of the specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [http://developers.whatwg.org/ http://developers.whatwg.org/]<br />
<br />
=== When will we be able to start using these new features? ===<br />
<br />
You can use some of them now. Others might take a few more years to get widely implemented. Here are some sites to help you work out what you can use:<br />
<br />
* http://diveintohtml5.info/<br />
* http://caniuse.com/<br />
* http://html5doctor.com/<br />
* https://developer.mozilla.org/<br />
* http://dev.opera.com/articles/html/<br />
<br />
If you know of any more (or if you have some yourself) then add them to the list! If there are some on the list that aren't very useful compared to the rest, then remove them!<br />
<br />
=== When will HTML5 be finished? ===<br />
<br />
The WHATWG is now using a Living Standard development model, so this question is no longer really pertinent. See above, under "[[FAQ#What_is_HTML.3F|What is HTML5?]]". The real question is, when can you use new features? For an answer to 'that' question, see "[[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]".<br />
<br />
Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. &lt;canvas&gt;). But other sections are still being actively worked on and changed regularly, or not even written yet.<br />
<br />
'''You can see annotations in the margins showing the estimated stability of each section.'''<br />
<br />
The possible states are:<br />
<br />
* ''Idea; yet to be specified'' -- the section is a placeholder.<br />
* ''First draft'' -- An early stage.<br />
* ''Working draft'' -- An early stage, but more mature than just "first draft".<br />
* ''Last call for comments'' -- The section is nearly done, but there may be feedback still to be processed. Send feedback sooner rather than later, or it might be too late.<br />
* ''Awaiting implementation feedback'' -- The section is basically done, but might change in response to feedback from implementors. Major changes are unlikely past this point unless it is found that the feature, as specified, really doesn't work well.<br />
* ''Implemented and widely deployed'' -- the feature is specified and complete. Once a section is interoperably implemented, it&#8217;s quite stable and unlikely to change significantly. Any changes to such a section would most likely only be editorial in nature, particularly if the feature is already in widespread use.<br />
<br />
There are also two special states:<br />
<br />
* ''Being edited right now'' -- the section is in high flux and is actively being edited. Contact Hixie on [[IRC]] if you have immediate feedback. (This state is not used often.)<br />
* ''Being considered for removal'' -- for one reason or another, the section is being considered for removal. Send feedback soon to help with the decision.<br />
<br />
The point to all this is that you shouldn&#8217;t place too much weight on the status of the specification as a whole. You need to consider the stability and maturity level of each section individually.<br />
<br />
=== What's this I hear about 2022? ===<br />
<br />
Before the WHATWG transitioned to an unversioned model for HTML, when we were still working on HTML5 and still thought in terms of snapshot drafts reaching milestones as a whole rather than on a per-section basis, the editor estimated that we'd reach Last Call in October 2009, Candidate Recommendation in the year 2012, and Recommendation in the year 2022 or later. This would be approximately 18-20 years of development, since beginning in mid-2004, which is on par with the amount of work that other specs of similar size and similar maturity receive to get to the same level of quality. For instance, it's in line with the timeline of CSS2/2.1. Compared to HTML4's timetable it may seem long, but consider: work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now. For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you&#8217;ll begin to understand why the time frame seems so long.<br />
<br />
Now that we've moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.<br />
<br />
=== What about Microsoft and Internet Explorer? === <br />
<br />
Microsoft has already started implementing parts of HTML5 in IE8 and is adding more to IE9.<br />
<br />
HTML5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.<br />
<br />
=== Is design rationale documented? ===<br />
<br />
Sort of. Often the documentation can be found in the mailing list or IRC channel archives. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification huge.<br />
<br />
For a few cases that someone did take the time document, the information can be found at the following locations:<br />
<br />
* [[Rationale]] — a page that documents some reasons behind decisions in the spec, originally written and maintained by Variable. If anyone wants to help him out, try to grab someone on [[IRC]] (e.g. Hixie), we're always looking for more contributors and this is a good place to start.<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend]] or another ''mini-header'' element.<br />
<br />
Also see ''HTML feature proposals'' below.<br />
<br />
== HTML syntax issues ==<br />
<br />
=== Will HTML finally put an end to the XHTML as <code>text/html</code> debate? === <br />
<br />
Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''<br />
<br />
=== What will the DOCTYPE be? === <br />
<br />
In HTML:<br />
<br />
<code>&lt;!DOCTYPE html&gt;</code><br />
<br />
In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.<br />
<br />
For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.<br />
<br />
<code>&lt;!DOCTYPE html SYSTEM "about:legacy-compat"&gt;</code><br />
<br />
Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.<br />
<br />
Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code>&lt;!DOCTYPE HTML&gt;</code> or <code>&lt;!doctype html&gt;</code>.<br />
<br />
These alternatives were chosen because they meet the following criteria:<br />
<br />
* They trigger standards mode in all current and all relevant legacy browsers.<br />
* They are well-formed in XML and can appear in XHTML documents.<br />
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.<br />
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.<br />
* The first is short and memorable to encourage its use.<br />
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.<br />
<br />
=== Under what conditions should a DOCTYPE be used in XHTML? ===<br />
<br />
Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:<br />
<br />
# The document is intended to be a polyglot document that may be served as both HTML or XHTML.<br />
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)<br />
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].<br />
<br />
Fundamentally, this is an XML issue, and is not specific to XHTML.<br />
<br />
=== How are documents from HTML4 and earlier versions parsed? ===<br />
<br />
All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.<br />
<br />
Validators are allowed to have different code paths for previous levels of HTML.<br />
<br />
=== If there is no DTD, how can I validate my page? === <br />
<br />
With an [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== Where's the harm in adding— ===<br />
<br />
Every feature we add to the Web platform has a cost:<br />
<br />
* Implementation: someone has to write code for it in each browser<br />
* Testing: someone has to write the tests to check the features is working<br />
* QA: someone has to regularly run the tests to make sure the feature doesn't regress<br />
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features<br />
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so<br />
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature<br />
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain<br />
* Spec writing: someone has to write the spec for the feature and ensure it's maintained<br />
* Bug fixing: when bugs are found in the spec or implementations, they have to be maintained<br />
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)<br />
<br />
== WHATWG and the W3C HTML WG ==<br />
<br />
=== Are there plans to merge the groups? ===<br />
<br />
No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.<br />
<br />
On the WHATWG side, Hixie, the editor, reads the feedback sent to both groups and takes all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, Hixie does not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)<br />
<br />
=== Which group has authority in the event of a dispute? ===<br />
<br />
The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; see the "[http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-do-the-whatwg-and-w3c-specifications-differ? How do the WHATWG and W3C specifications differ?]" introduction section in the WHATWG HTML spec for a list of known differences.<br />
<br />
=== Isn't it bad that the specs have forked? ===<br />
<br />
Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.<br />
<br />
The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.<br />
<br />
=== What is the history of HTML? ===<br />
<br />
Here are some documents that detail the history of HTML:<br />
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#history0 The history section in the HTML standard itself]<br />
<br />
== Using HTML ==<br />
<br />
=== Do you have any hints on how to use &lt;section> and &lt;article> and so on? ===<br />
<br />
Some hopefully helpful hints:<br />
<br />
* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>, and if it's not in the table of contents and doesn't have an &lt;h1>, it should probably not be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>.<br />
* You can still use &lt;div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.<br />
* Generally, &lt;section>s should start with an &lt;h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an &lt;h1> would be inappropriate, you probably want &lt;div> rather than &lt;section>.<br />
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using &lt;article>, and each comment could be big enough that it has separate &lt;section>s, and so on.<br />
<br />
== Mailing List ==<br />
<br />
=== +1 ===<br />
<br />
Please note that content-free agreement (such as +1s) have no effect on <br />
the WHATWG list and are therefore discouraged. Editors of specs discussed <br />
in the WHATWG only consider the quality of the arguments presented, and <br />
not the volume of agreement.<br />
<br />
You should therefore only post to the list if you have a substantive new point<br />
to make, for example if you have seen a flaw in an argument presented so far,<br />
or have a new idea to contribute, or have some information that has not yet<br />
been brought to the table.<br />
<br />
=== Making Outlook quote e-mail messages properly ===<br />
If you use Outlook or Outlook Express, you can use either [http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook-QuoteFix] or [http://home.in.tum.de/~jain/software/oe-quotefix/ OE-QuoteFix]. These plugins fix several of Outlook's problems with sending properly formatted emails.<br />
<br />
=== Should I top-post or reply inline? ===<br />
<br />
'''Please reply inline or make the reply self-contained, and trim extraneous quotes from previous e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9038Rationale2013-02-22T05:32:41Z<p>Yroc: /* Why should the spec suggest any one specific method for marking up comments? */ added an in page 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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
When adding features to the spec, the editor also takes into account member and contributor feedback. If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=9000Rationale2013-02-17T23:37:38Z<p>Yroc: /* Why should the spec suggest any one specific method for marking up comments? */ Added 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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
When adding features to the spec, the editor also takes into account member and contributor feedback. If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8999Rationale2013-02-17T23:29:29Z<p>Yroc: /* A &ldquo;&lt;comment&gt;&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) */ Added new 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. 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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
When adding features to the spec, the editor also takes into account member and contributor feedback. If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8998Rationale2013-02-17T23:19:43Z<p>Yroc: /* A &ldquo;&lt;comment&gt;&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) */ Several new sections added</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
When adding features to the spec, the editor also takes into account member and contributor feedback. If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrating by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8997Rationale2013-02-17T22:36:24Z<p>Yroc: /* But comments are not articles */ filled out 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. 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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
When adding features to the spec, the editor also takes into account member and contributor feedback. If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are related, for example, &ldquo;is in response to&rdquo;).<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8996Rationale2013-02-17T19:01:09Z<p>Yroc: /* Why isn&rsquo;t there a dedicated element for user comments? (e.g., &lt;comment&gt;) */ Renamed heading</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
When adding features to the spec, the editor also takes into account member and contributor feedback. If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There already <em>is</em> an element for user comments: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8995Rationale2013-02-17T14:00:21Z<p>Yroc: /* General Rationale */ Added new section "In overall terms, what determines what's in the spec?"</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should be dropped.<br />
<br />
When adding features to the spec, the editor also takes into account member and contributor feedback. If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== Why isn&rsquo;t there a dedicated element for user comments? (e.g., <code>&lt;comment&gt;</code>) ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8991Rationale2013-02-15T15:34:20Z<p>Yroc: /* The blockquote element */ markup correction</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== Why isn&rsquo;t there a dedicated element for user comments? (e.g., <code>&lt;comment&gt;</code>) ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8990Rationale2013-02-15T15:33:39Z<p>Yroc: /* Grouping content */ reformatted heading in form of a question</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element?<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== Why isn&rsquo;t there a dedicated element for user comments? (e.g., <code>&lt;comment&gt;</code>) ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8987Rationale2013-02-13T17:46:39Z<p>Yroc: /* General Rationale */ Added new section "Why stick to 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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== Why isn&rsquo;t there a dedicated element for user comments? (e.g., <code>&lt;comment&gt;</code>) ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8986Rationale2013-02-13T17:17:38Z<p>Yroc: /* General Rationale */ Added new section "Purpose of defining elements semantically"</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== Why isn&rsquo;t there a dedicated element for user comments? (e.g., <code>&lt;comment&gt;</code>) ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8985Rationale2013-02-13T14:44:55Z<p>Yroc: /* DOCTYPE (Document Type Declaration) */ minor style change</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== Why isn&rsquo;t there a dedicated element for user comments? (e.g., <code>&lt;comment&gt;</code>) ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8969Rationale2013-02-04T21:25:26Z<p>Yroc: /* Document metadata */ Added subsection "Inclusion of keyword</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== Why isn&rsquo;t there a dedicated element for user comments? (e.g., <code>&lt;comment&gt;</code>) ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8968Rationale2013-02-04T20:52:37Z<p>Yroc: /* Document metadata */ Added subsection "Inclusion of application-name..."</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== Why isn&rsquo;t there a dedicated element for user comments? (e.g., <code>&lt;comment&gt;</code>) ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8967Rationale2013-02-04T20:30:09Z<p>Yroc: /* Specific Elements */ Added "Document metadata" and "meta charset" sections</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element"</ref><br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== Why isn&rsquo;t there a dedicated element for user comments? (e.g., <code>&lt;comment&gt;</code>) ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8965Rationale2013-02-02T19:07:55Z<p>Yroc: /* Why isn&rsquo;t there a sandbox attribute on the html element */ Added question mark to heading</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== Why isn&rsquo;t there a dedicated element for user comments? (e.g., <code>&lt;comment&gt;</code>) ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8964Rationale2013-02-02T19:07:05Z<p>Yroc: /* sandbox attribute on the html element */ Altered heading</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== Why isn&rsquo;t there a dedicated element for user comments? (e.g., <code>&lt;comment&gt;</code>) ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8963Rationale2013-02-02T19:05:58Z<p>Yroc: /* A dedicated element for advertisements */ Altered heading</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== Why isn&rsquo;t there a dedicated element for user comments? (e.g., <code>&lt;comment&gt;</code>) ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code> or <code>&lt;advert&gt;</code>) ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, <code>&lt;advert&gt;</code>, etc.) because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8962Rationale2013-02-02T18:57:03Z<p>Yroc: /* Why isn&rsquo;t there a dedicated element for user comments? (e.g., comment) */ style change in heading</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== Why isn&rsquo;t there a dedicated element for user comments? (e.g., <code>&lt;comment&gt;</code>) ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== A dedicated element for advertisements ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors).<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8961Rationale2013-02-02T18:56:03Z<p>Yroc: /* A dedicated element for user comments */ Altered headline</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== Why isn&rsquo;t there a dedicated element for user comments? (e.g., <code>comment</code>) ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== A dedicated element for advertisements ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors).<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8960Rationale2013-02-02T17:56:48Z<p>Yroc: Added todo</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 />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A dedicated element for user comments ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== A dedicated element for advertisements ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors).<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8959Rationale2013-02-02T17:54:50Z<p>Yroc: /* Modifying existing semantics */ Punctuation cleanup</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 />
11. Fix obsolete image links in Meter and Progress section<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML 4 users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, 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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A dedicated element for user comments ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== A dedicated element for advertisements ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors).<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8957Rationale2013-02-02T15:18:37Z<p>Yroc: /* General Rationale */ Removed extraneous line break</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 />
11. Fix obsolete image links in Meter and Progress section<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== 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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A dedicated element for user comments ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== A dedicated element for advertisements ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors).<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8956Rationale2013-02-02T15:14:19Z<p>Yroc: /* meter and progress (are not the same thing) */ Removed broken image links</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 />
11. Fix obsolete image links in Meter and Progress section<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A dedicated element for user comments ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== A dedicated element for advertisements ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors).<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8955Rationale2013-02-02T15:11:51Z<p>Yroc: /* b, i, em, strong, and mark */ Section removed -- does not provide any rationale information</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 />
11. Fix obsolete image links in Meter and Progress section<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a <code>meter</code> 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 <code>progress</code> 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 />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A dedicated element for user comments ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== A dedicated element for advertisements ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors).<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8954Rationale2013-02-02T01:13:47Z<p>Yroc: Added external link to spec</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 />
11. Fix obsolete image links in Meter and Progress section<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
==== <code>b</code>, <code>i</code>, <code>em</code>, <code>strong</code>, and <code>mark</code> ====<br />
<code>em</code> is meant to indicate that some text is emphasized. <code>strong</code> is meant to confer importance upon text. <code>b</code> is meant for text that is stylistically offset from the rest of the text. Finally <code>i</code> 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 &ldquo;cute&rdquo; 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 />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a <code>meter</code> 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 <code>progress</code> 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 />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A dedicated element for user comments ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== A dedicated element for advertisements ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors).<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8953Rationale2013-02-02T01:05:43Z<p>Yroc: Reworded intro paragraph</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 />
11. Fix obsolete image links in Meter and Progress section<br />
--><br />
This rationale document serves as a supplement to WHATWG&rsquo;s HTML Living Standard specification. It is a work-in-progress.<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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
==== <code>b</code>, <code>i</code>, <code>em</code>, <code>strong</code>, and <code>mark</code> ====<br />
<code>em</code> is meant to indicate that some text is emphasized. <code>strong</code> is meant to confer importance upon text. <code>b</code> is meant for text that is stylistically offset from the rest of the text. Finally <code>i</code> 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 &ldquo;cute&rdquo; 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 />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a <code>meter</code> 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 <code>progress</code> 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 />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A dedicated element for user comments ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== A dedicated element for advertisements ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors).<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8952Rationale2013-02-01T12:14:56Z<p>Yroc: /* DOCTYPE */ Grammar cleanup</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 />
11. Fix obsolete image links in Meter and Progress 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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== <code>DOCTYPE</code> (Document Type Declaration) ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
==== <code>b</code>, <code>i</code>, <code>em</code>, <code>strong</code>, and <code>mark</code> ====<br />
<code>em</code> is meant to indicate that some text is emphasized. <code>strong</code> is meant to confer importance upon text. <code>b</code> is meant for text that is stylistically offset from the rest of the text. Finally <code>i</code> 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 &ldquo;cute&rdquo; 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 />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a <code>meter</code> 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 <code>progress</code> 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 />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A dedicated element for user comments ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== A dedicated element for advertisements ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors).<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8951Rationale2013-02-01T12:10:32Z<p>Yroc: /* A dedicated element for advertisements */ Added 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 />
11. Fix obsolete image links in Meter and Progress 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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== <code>DOCTYPE</code> ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. It is necessary for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
==== <code>b</code>, <code>i</code>, <code>em</code>, <code>strong</code>, and <code>mark</code> ====<br />
<code>em</code> is meant to indicate that some text is emphasized. <code>strong</code> is meant to confer importance upon text. <code>b</code> is meant for text that is stylistically offset from the rest of the text. Finally <code>i</code> 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 &ldquo;cute&rdquo; 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 />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a <code>meter</code> 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 <code>progress</code> 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 />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A dedicated element for user comments ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== A dedicated element for advertisements ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors).<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref><br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8950Rationale2013-02-01T12:08:32Z<p>Yroc: /* Unadopted proposals */ "Unadopted" -> Rejected</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 />
11. Fix obsolete image links in Meter and Progress 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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== <code>DOCTYPE</code> ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. It is necessary for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
==== <code>b</code>, <code>i</code>, <code>em</code>, <code>strong</code>, and <code>mark</code> ====<br />
<code>em</code> is meant to indicate that some text is emphasized. <code>strong</code> is meant to confer importance upon text. <code>b</code> is meant for text that is stylistically offset from the rest of the text. Finally <code>i</code> 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 &ldquo;cute&rdquo; 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 />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a <code>meter</code> 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 <code>progress</code> 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 />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Rejected proposals ==<br />
=== A dedicated element for user comments ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== A dedicated element for advertisements ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors).<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8949Rationale2013-02-01T00:22:25Z<p>Yroc: /* A dedicated element for user comments */ Grammar cleanup</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 />
11. Fix obsolete image links in Meter and Progress 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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== <code>DOCTYPE</code> ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. It is necessary for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
==== <code>b</code>, <code>i</code>, <code>em</code>, <code>strong</code>, and <code>mark</code> ====<br />
<code>em</code> is meant to indicate that some text is emphasized. <code>strong</code> is meant to confer importance upon text. <code>b</code> is meant for text that is stylistically offset from the rest of the text. Finally <code>i</code> 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 &ldquo;cute&rdquo; 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 />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a <code>meter</code> 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 <code>progress</code> 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 />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Unadopted proposals ==<br />
=== A dedicated element for user comments ===<br />
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All the content types mentioned above <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested <code>article</code> elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
=== A dedicated element for advertisements ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors).<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yrochttps://wiki.whatwg.org/index.php?title=Rationale&diff=8948Rationale2013-02-01T00:16:25Z<p>Yroc: /* Failed proposals */ Changed heading name</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 />
11. Fix obsolete image links in Meter and Progress 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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== <code>DOCTYPE</code> ===<br />
Since HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. It is necessary for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Sections ===<br />
<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
<br />
==== <code>blockquote</code> ====<br />
Attributions and inline citations do not belong inside the <code>blockquote</code> element because the specification does not consider them to be part of the block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
==== <code>b</code>, <code>i</code>, <code>em</code>, <code>strong</code>, and <code>mark</code> ====<br />
<code>em</code> is meant to indicate that some text is emphasized. <code>strong</code> is meant to confer importance upon text. <code>b</code> is meant for text that is stylistically offset from the rest of the text. Finally <code>i</code> 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 &ldquo;cute&rdquo; 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 />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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 />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a <code>meter</code> 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 <code>progress</code> 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 />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
== Unadopted proposals ==<br />
=== A dedicated element for user comments ===<br />
There is no dedicated element for marking up user comment, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested <code>article</code>s instead.<br />
<br />
Several arguments have been put forth in favor adding a <code>comment</code> element to the spec <ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>. Arguments and counterarguments run as follows:<br />
<br />
<b>Argument:</b> Comments are not articles according to the commonly understood (dictionary) definition of &ldquo;article.&rdquo; Articles are relatively &ldquo;long&rdquo; pieces of writing, and they are not responses to what others have written. It&rsquo;s clear that comments are not articles.<br />
<br />
<b>Counterargument:</b> The element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition&rsquo;s length and whether or not it&rsquo;s authored by a site&rsquo;s owner/staff or by it&rsquo;s readers is completely irrelevant.<br />
<br />
<b>Argument:</b> Comments are not articles according to the specification&rsquo;s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They are dependent on the context of what they are responding to. For example, &ldquo;LOL&rdquo; or &ldquo;Yeah, especially when talking about your lobbyist friends!&rdquo; are, on their own, unintelligible.<br />
<br />
<b>Counterargument:</b> The definition of <code>article</code> does not require that a piece of writing be fully intelligible on its own. The terms &ldquo;complete,&rdquo; &ldquo;self-contained,&rdquo; and &ldquo;independent&rdquo; are really meant to convey the idea of separateness. Comments are separate from what they are commenting on&mdash;they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently reused and syndicated). It&rsquo;s largely a matter of the author&rsquo;s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.<br />
<br />
<b>Argument:</b> Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.<br />
<br />
<b>Counterargument:</b> All of content types mentioned <em>are</em> in fact articles according to the spec&rsquo;s definition.<br />
<br />
<b>Argument:</b> Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.<br />
<br />
<b>Counterargument:</b> There&rsquo;s no compelling argument that a separate element would make this meaningfully easier than than nested elements.<br />
<br />
<b>Argument:</b> Comments sometimes appear in a different region of the page than the item that they are referencing, hence the markup for comments should not have to be contained within the markup of the item.<br />
<br />
<b>Counterargument:</b> No evidence has been brought forward that this is a significant authorship issue.<br />
<br />
=== A dedicated element for advertisements ===<br />
There is no dedicated advertisement element (<code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors).<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The <code>aside</code> element is probably the closest semantic fit for advertisements.<br />
<br />
=== <code>sandbox</code> attribute on the <code>html</code> 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 if 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 />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Yroc