[html5] r3138 - [e] (0) Elaborate on willful violations.
whatwg at whatwg.org
whatwg at whatwg.org
Tue May 26 03:30:10 PDT 2009
Author: ianh
Date: 2009-05-26 03:30:08 -0700 (Tue, 26 May 2009)
New Revision: 3138
Modified:
index
source
Log:
[e] (0) Elaborate on willful violations.
Modified: index
===================================================================
--- index 2009-05-26 10:15:31 UTC (rev 3137)
+++ index 2009-05-26 10:30:08 UTC (rev 3138)
@@ -4647,8 +4647,8 @@
</ol><!-- XXX we might want to define "server-based naming authority",
it's not clear RFC3986 does a good job of defining that anymore
(earlier URI specs did) --><p class=note>These parsing rules are a <a href=#willful-violation>willful
- violation</a> of RFC 3986 and RFC 3987 to handle legacy
- content. <a href=#refsRFC3986>[RFC3986]</a> <a href=#refsRFC3987>[RFC3987]</a></p>
+ violation</a> of RFC 3986 and RFC 3987 (which do not define error
+ handling), motivated by a desire to handle legacy content. <a href=#refsRFC3986>[RFC3986]</a> <a href=#refsRFC3987>[RFC3987]</a></p>
</div>
@@ -5347,8 +5347,10 @@
</dl></li>
- </ol><p class=note>The above algorithm is a <a href=#willful-violation>willful violation</a> of the
- HTTP specification. <a href=#refsHTTP>[HTTP]</a></p>
+ </ol><p class=note>The above algorithm is a <a href=#willful-violation>willful
+ violation</a> of the HTTP specification, which requires that the
+ Content-Type headers be honored, despite implementation experience
+ showing that this is not pratical in many cases. <a href=#refsHTTP>[HTTP]</a></p>
<h4 id=content-type-sniffing:-web-pages><span class=secno>2.7.2 </span>Content-Type sniffing: Web pages</h4>
@@ -5944,8 +5946,9 @@
<tr><td> x-x-big5 <td> Big5 <td>
<a href=#refsBIG5>[BIG5]</a> <!-- XXX ? -->
</table><p class=note>The requirement to treat certain encodings as other
- encodings according to the table above is a <a href=#willful-violation>willful violation</a> of the
- W3C Character Model specification. <a href=#refsCHARMOD>[CHARMOD]</a></p>
+ encodings according to the table above is a <a href=#willful-violation>willful
+ violation</a> of the W3C Character Model specification, motivated
+ by a desire for compatibility with legacy content. <a href=#refsCHARMOD>[CHARMOD]</a></p>
<hr><p>User agents must not support the CESU-8, UTF-7, BOCU-1 and SCSU
encodings. <a href=#refsCESU8>[CESU8]</a> <a href=#refsUTF7>[UTF7]</a> <a href=#refsBOCU1>[BOCU1]</a> <a href=#refsSCSU>[SCSU]</a></p>
@@ -36054,7 +36057,10 @@
<p>If <var title="">action</var> is the empty string, let <var title="">action</var> be <a href="#the-document's-address">the document's address</a>.</p>
- <p class=note>This step is a <a href=#willful-violation>willful violation</a> of RFC 3986. <a href=#refsRFC3986>[RFC3986]</a></p>
+ <p class=note>This step is a <a href=#willful-violation>willful violation</a> of
+ RFC 3986, which would require base URL processing here. This
+ violation is motivated by a desire for compatibility with legacy
+ content. <a href=#refsRFC3986>[RFC3986]</a></p>
<!-- Don't ask me why. But that's what IE does. It even treats
action="" differently from action=" " or action="#" (the latter
@@ -47188,9 +47194,12 @@
<code><a href=#window>Window</a></code> object, then in JavaScript, the <code title="">this</code> keyword in the global scope must return the
<code><a href=#window>Window</a></code> object's <code><a href=#windowproxy>WindowProxy</a></code> object.</p>
- <p class=note>This is a <a href=#willful-violation>willful violation</a> of the JavaScript
- specification current at the time of writing (ECMAScript edition
- 3). <a href=#refsECMA262>[ECMA262]</a></p>
+ <p class=note>This is a <a href=#willful-violation>willful violation</a> of the
+ JavaScript specification current at the time of writing
+ (ECMAScript edition 3). The JavaScript specification requires that
+ the code title="">this keyword in the global scope return
+ the global object, but this is not compatible with the security
+ design prevalent in implementations as specified herein. <a href=#refsECMA262>[ECMA262]</a></p>
</dd>
@@ -49515,12 +49524,13 @@
CARRIAGE RETURN (CR) U+000A LINE FEED (LF) pairs.</p>
<p class=note>This is a <a href=#willful-violation title="willful violation">willful
- double violation</a> of RFC2046. <a href=#refsRFC2046>[RFC2046]</a></p> <!-- 2046 (and 2045) says that
- charset="" is always allowed on text/*, but that harks back to the
- old days before UTF-8 was widely used; 2046 also says that newlines
- are always CRLF-delimited, which is not workable given the
- widespread use of editors that use either lone LFs or lone CRs as
- line break delimiters. -->
+ double violation</a> of RFC2046, which requires all <code title="">text/*</code> types to support an open-ended set of
+ character encodings and only allows CRLF line breaks. These
+ requirements, however, are outdated; UTF-8 is now widely used, such
+ that supporting other encodings is no longer necessary, and use of
+ CR, LF, and CRLF line breaks is commonly supported and indeed
+ sometimes CRLF is <em>not</em> supported by text editors. <a href=#refsRFC2046>[RFC2046]</a></p> <!-- also RFC 2045 for charset
+ -->
<p>The first line of an application cache manifest must consist of
the string "CACHE", a single U+0020 SPACE character, the string
Modified: source
===================================================================
--- source 2009-05-26 10:15:31 UTC (rev 3137)
+++ source 2009-05-26 10:30:08 UTC (rev 3138)
@@ -4231,8 +4231,9 @@
(earlier URI specs did) -->
<p class="note">These parsing rules are a <span>willful
- violation</span> of RFC 3986 and RFC 3987 to handle legacy
- content. <a href="#refsRFC3986">[RFC3986]</a> <a
+ violation</span> of RFC 3986 and RFC 3987 (which do not define error
+ handling), motivated by a desire to handle legacy content. <a
+ href="#refsRFC3986">[RFC3986]</a> <a
href="#refsRFC3987">[RFC3987]</a></p>
</div>
@@ -5038,8 +5039,11 @@
</ol>
- <p class="note">The above algorithm is a <span>willful violation</span> of the
- HTTP specification. <a href="#refsHTTP">[HTTP]</a></p>
+ <p class="note">The above algorithm is a <span>willful
+ violation</span> of the HTTP specification, which requires that the
+ Content-Type headers be honored, despite implementation experience
+ showing that this is not pratical in many cases. <a
+ href="#refsHTTP">[HTTP]</a></p>
<h4>Content-Type sniffing: Web pages</h4>
@@ -5796,8 +5800,9 @@
</table>
<p class="note">The requirement to treat certain encodings as other
- encodings according to the table above is a <span>willful violation</span> of the
- W3C Character Model specification. <a
+ encodings according to the table above is a <span>willful
+ violation</span> of the W3C Character Model specification, motivated
+ by a desire for compatibility with legacy content. <a
href="#refsCHARMOD">[CHARMOD]</a></p>
<hr>
@@ -40496,8 +40501,10 @@
<p>If <var title="">action</var> is the empty string, let <var
title="">action</var> be <span>the document's address</span>.</p>
- <p class="note">This step is a <span>willful violation</span> of RFC 3986. <a
- href="#refsRFC3986">[RFC3986]</a></p>
+ <p class="note">This step is a <span>willful violation</span> of
+ RFC 3986, which would require base URL processing here. This
+ violation is motivated by a desire for compatibility with legacy
+ content. <a href="#refsRFC3986">[RFC3986]</a></p>
<!-- Don't ask me why. But that's what IE does. It even treats
action="" differently from action=" " or action="#" (the latter
@@ -53763,9 +53770,13 @@
title="">this</code> keyword in the global scope must return the
<code>Window</code> object's <code>WindowProxy</code> object.</p>
- <p class="note">This is a <span>willful violation</span> of the JavaScript
- specification current at the time of writing (ECMAScript edition
- 3). <a href="#refsECMA262">[ECMA262]</a></p>
+ <p class="note">This is a <span>willful violation</span> of the
+ JavaScript specification current at the time of writing
+ (ECMAScript edition 3). The JavaScript specification requires that
+ the code title="">this</code> keyword in the global scope return
+ the global object, but this is not compatible with the security
+ design prevalent in implementations as specified herein. <a
+ href="#refsECMA262">[ECMA262]</a></p>
</dd>
@@ -56471,13 +56482,15 @@
CARRIAGE RETURN (CR) U+000A LINE FEED (LF) pairs.</p>
<p class="note">This is a <span title="willful violation">willful
- double violation</span> of RFC2046. <a
- href="#refsRFC2046">[RFC2046]</a></p> <!-- 2046 (and 2045) says that
- charset="" is always allowed on text/*, but that harks back to the
- old days before UTF-8 was widely used; 2046 also says that newlines
- are always CRLF-delimited, which is not workable given the
- widespread use of editors that use either lone LFs or lone CRs as
- line break delimiters. -->
+ double violation</span> of RFC2046, which requires all <code
+ title="">text/*</code> types to support an open-ended set of
+ character encodings and only allows CRLF line breaks. These
+ requirements, however, are outdated; UTF-8 is now widely used, such
+ that supporting other encodings is no longer necessary, and use of
+ CR, LF, and CRLF line breaks is commonly supported and indeed
+ sometimes CRLF is <em>not</em> supported by text editors. <a
+ href="#refsRFC2046">[RFC2046]</a></p> <!-- also RFC 2045 for charset
+ -->
<p>The first line of an application cache manifest must consist of
the string "CACHE", a single U+0020 SPACE character, the string
More information about the Commit-Watchers
mailing list