Rationale - Revision history

J9t: Corrected misc issues

2019-10-20T19:03:42Z

Corrected misc issues

← Older revision		Revision as of 19:03, 20 October 2019
Line 17:		Line 17:

	=== In overall terms, what determines what’s in the spec? ===		=== In overall terms, what determines what’s in the spec? ===

	==== Already-implemented features ====		==== Already-implemented features ====
	In the past, the contents of the spec tended to be determined by browsers’ <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’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.		In the past, the contents of the spec tended to be determined by browsers’ <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’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.

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

	==== Member and contributor feedback ====		==== Member and contributor feedback ====
Line 26:		Line 27:

	=== One vendor, one veto ===		=== One vendor, one veto ===
	Part of the the goal of the WHATWG is to document how web browsers actually handle HTML. As such, browser vendors already have veto power—by not following the standard. The W3C and WHATWG do not have any enforcement power and can only write what browsers are willing to implement. Not removing features from the HTML standard that at least one browser vendor has stated they are unwilling to implement causes the HTML spec to not accurately document reality.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for <video> and <audio></a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn’t a power that we grant browsers; it’s a right that they earn on their own by virtue of having users. The minimum market share for a veto is somewhere around 1%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref>		Part of the the goal of the WHATWG is to document how web browsers actually handle HTML. As such, browser vendors already have veto power—by not following the standard. The W3C and WHATWG do not have any enforcement power and can only write what browsers are willing to implement. Not removing features from the HTML standard that at least one browser vendor has stated they are unwilling to implement causes the HTML spec to not accurately document reality.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for <video> and <audio></a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref> The veto isn’t a power that we grant browsers; it’s a right that they earn on their own by virtue of having users. The minimum market share for a veto is somewhere around 1%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref>

	=== 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> ===		=== 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> ===
Line 116:		Line 117:

	== Specific Elements ==		== Specific Elements ==

	=== The DOCTYPE (Document Type Declaration) ===		=== The DOCTYPE (Document Type Declaration) ===
	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.		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.

	=== Document metadata ===		=== Document metadata ===

	==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====		==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====
	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>		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>
Line 130:		Line 133:

	=== Sections ===		=== Sections ===

	==== <code>hgroup</code> and other heading elements ====		==== <code>hgroup</code> and other heading elements ====
	The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.		The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.
Line 137:		Line 141:

	=== Grouping content ===		=== Grouping content ===

	==== The <code>blockquote</code> element ====		==== The <code>blockquote</code> element ====

	===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====		===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====
	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.		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.
Line 146:		Line 152:

	==== On the status of <code>image</code> ====		==== On the status of <code>image</code> ====

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

Line 183:		Line 188:
	See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html		See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html

	==== @~~DEFER~~ and @~~ASYNC~~ ====		==== @defer and @async ====
	~~ASYNC~~ tells the browsers to run the script with its following content at the ~~SAME~~ time(namely, asynchronously).		async tells the browsers to run the script with its following content at the '''same''' time(namely, asynchronously).
	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>

	~~=== quirks mode ===~~		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>

			=== Quirks mode ===
	The HTML parser has [https://html.spec.whatwg.org//multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:		The HTML parser has [https://html.spec.whatwg.org//multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:

Line 196:		Line 201:
	Why? See http://hsivonen.iki.fi/last-html-quirk/		Why? See http://hsivonen.iki.fi/last-html-quirk/

	=== ~~ignored~~ white space before head ===		=== Ignored white space before head ===

	White space before the <code><head></code> tag is ignored. The main reason is that, given the markup		White space before the <code><head></code> tag is ignored. The main reason is that, given the markup

Line 227:		Line 231:

	== Rejected proposals ==		== Rejected proposals ==
	~~===~~ A “<code><comment></code>” 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.) ===		A “<code><comment></code>” 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.) ===

	==== Why isn’t there an element for user comments? (e.g., <code><comment></code>) ====		==== Why isn’t there an element for user comments? (e.g., <code><comment></code>) ====
Line 313:		Line 317:
	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>		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>

	=== ~~feature~~ queries ===		=== Feature queries ===
	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:		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:
	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>		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>

Zcorpan: Update rationale for custom elements

2017-08-24T08:46:32Z

Update rationale for custom elements

← Older revision		Revision as of 08:46, 24 August 2017
Line 322:		Line 322:

	=== Why aren’t authors allowed to make custom HTML elements? ===		=== Why aren’t authors allowed to make custom HTML elements? ===
	~~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>
			It is now allowed, see https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements

			Be aware however that using custom elements when standard elements could have been used 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>

	<!--		<!--

Zcorpan: Fix wiki markup

2017-08-24T08:42:40Z

Fix wiki markup

← Older revision		Revision as of 08:42, 24 August 2017
Line 308:		Line 308:
	=== Why isn’t there a grouping-type element for description lists to represent individual name-value groups (e.g., a “<code>dli</code>” 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> ===		=== Why isn’t there a grouping-type element for description lists to represent individual name-value groups (e.g., a “<code>dli</code>” 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> ===

	There is; it is now allowed to use `<div>` in `<dl>`. See https://github.com/whatwg/html/issues/1937		There is; it is now allowed to use <code><div></code> in <code><dl></code>. See https://github.com/whatwg/html/issues/1937

	=== Why isn’t there a <code>sandbox</code> attribute on the <code>html</code> element? ===		=== Why isn’t there a <code>sandbox</code> attribute on the <code>html</code> element? ===

Zcorpan: Update rationale for grouping-type element for dl

2017-08-24T08:38:03Z

Update rationale for grouping-type element for dl

@@ Line 307: / Line 307: @@
 === 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> ===
-That's one way to do it, yeah.
+There is; it is now allowed to use `<div>` in `<dl>`. See https://github.com/whatwg/html/issues/1937
 === Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===

Yroc: /* Already-implemented features */ General rewording for clarification

2015-07-16T18:26:00Z

Already-implemented features: General rewording for clarification

← Older revision		Revision as of 18:26, 16 July 2015
Line 18:		Line 18:
	=== In overall terms, what determines what’s in the spec? ===		=== In overall terms, what determines what’s in the spec? ===
	==== Already-implemented features ====		==== Already-implemented features ====
	~~The~~ contents of the spec ~~is largely~~ determined by ~~what~~’~~s already been implemented in browsers~~. Historically, vendors competed with one another by implementing features without regard to any specification. It’s a relatively recent phenomenon that vendors compete by their conformance to the spec.		In the past, the contents of the spec tended to be determined by browsers’ <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’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.

	~~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 not be used in new content.		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.

	==== Member and contributor feedback ====		==== Member and contributor feedback ====

Zcorpan: Fix links to the HTML spec

2015-04-02T07:16:27Z

Fix links to the HTML spec

Zcorpan: /* Already-implemented features */

2015-04-02T06:59:53Z

Already-implemented features

← Older revision		Revision as of 06:59, 2 April 2015
Line 20:		Line 20:
	The contents of the spec is largely determined by what’s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It’s a relatively recent phenomenon that vendors compete by their conformance to the spec.		The contents of the spec is largely determined by what’s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It’s a relatively recent phenomenon that vendors compete by their conformance to the spec.

	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~~.		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 not be used in new content.

	==== Member and contributor feedback ====		==== Member and contributor feedback ====

Yroc: /* Why isn’t there an element for user comments? (e.g., <comment>) */ grammar

2014-01-22T23:45:03Z

Why isn’t there an element for user comments? (e.g., <comment>): grammar

← Older revision		Revision as of 23:45, 22 January 2014
Line 230:		Line 230:

	==== Why isn’t there an element for user comments? (e.g., <code><comment></code>) ====		==== Why isn’t there an element for user comments? (e.g., <code><comment></code>) ====
	There ~~already <em>~~is~~</em> an element for user comments~~: <code>article</code>.		There is: <code>article</code>.

	==== But comments are not articles ====		==== But comments are not articles ====

Yroc: /* Modifying existing semantics */ removed reference to specific HTML version (HTML 4 -> HTML)

2014-01-22T23:42:12Z

Modifying existing semantics: removed reference to specific HTML version (HTML 4 -> HTML)

← Older revision		Revision as of 23:42, 22 January 2014
Line 61:		Line 61:
	-->		-->
	=== Modifying existing semantics ===		=== Modifying existing semantics ===
	Some elements have different semantics than what HTML 4 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 <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>		Some elements have different semantics than what HTML 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 <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>

	=== What is the purpose of defining elements semantically? ===		=== What is the purpose of defining elements semantically? ===

Yroc: /* Why isn’t there a grouping-type element for description lists to represent individual name-value groups (e.g., a “dli” element)? It would make styling as well as adding microdata to individual groups much easier. */ Added referen

2013-10-16T18:59:53Z

Why isn’t there a grouping-type element for description lists to represent individual name-value groups (e.g., a “dli” element)? It would make styling as well as adding microdata to individual groups much easier.: Added referen

← Older revision		Revision as of 18:59, 16 October 2013
Line 306:		Line 306:
	recommend using that.</pre>		recommend using that.</pre>

	=== Why isn’t there a grouping-type element for description lists to represent individual name-value groups (e.g., a “<code>dli</code>” element)? It would make styling as well as adding microdata to individual groups much easier. ===		=== Why isn’t there a grouping-type element for description lists to represent individual name-value groups (e.g., a “<code>dli</code>” 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> ===
	<pre>On Sun, 30 Dec 2012, Brian Tremblay wrote:		<pre>On Sun, 30 Dec 2012, Brian Tremblay wrote:
	>		>
Line 376:		Line 376:
	is, vs how painful changing the parser and legacy tools would be. It's		is, vs how painful changing the parser and legacy tools would be. It's
	probably a close call (not much usage, but not a huge amount of pain).</pre>		probably a close call (not much usage, but not a huge amount of pain).</pre>


	=== Why isn’t there a <code>sandbox</code> attribute on the <code>html</code> element? ===		=== Why isn’t there a <code>sandbox</code> attribute on the <code>html</code> element? ===

← Older revision		Revision as of 07:16, 2 April 2015
Line 12:		Line 12:
	11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)		11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)
	-->		-->
	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.		This rationale document is supplemental to the WHATWG [https://html.spec.whatwg.org//multipage/ HTML Living Standard] specification. It is a work-in-progress.

	== General Rationale ==		== General Rationale ==
Line 64:		Line 64:

	=== What is the purpose of defining elements semantically? ===		=== What is the purpose of defining elements semantically? ===
	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>		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>

	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.		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.
Line 121:		Line 121:
	=== Document metadata ===		=== Document metadata ===
	==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====		==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====
	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>		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>

	==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====		==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====
	User agents may want to use the Web application name in UI in preference to the page’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>		User agents may want to use the Web application name in UI in preference to the page’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>

	==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====		==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====
Line 157:		Line 157:
	==== <code>textarea</code> ====		==== <code>textarea</code> ====

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

	==== <code>meter</code> and <code>progress</code> (are not the same thing) ====		==== <code>meter</code> and <code>progress</code> (are not the same thing) ====
Line 179:		Line 179:
	=== script element ===		=== script element ===

	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]?		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]?

	See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html		See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html
Line 189:		Line 189:
	=== quirks mode ===		=== quirks mode ===

	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:		The HTML parser has [https://html.spec.whatwg.org//multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:

	<blockquote><dl><dt>A start tag whose tag name is "table"		<blockquote><dl><dt>A start tag whose tag name is "table"