[html5] r5994 - [e] (0) apply wg decision Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=10202
whatwg at whatwg.org
whatwg at whatwg.org
Tue Apr 12 15:13:48 PDT 2011
Author: ianh
Date: 2011-04-12 15:13:47 -0700 (Tue, 12 Apr 2011)
New Revision: 5994
Modified:
complete.html
index
source
Log:
[e] (0) apply wg decision
Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=10202
Modified: complete.html
===================================================================
--- complete.html 2011-04-12 21:58:42 UTC (rev 5993)
+++ complete.html 2011-04-12 22:13:47 UTC (rev 5994)
@@ -25988,14 +25988,29 @@
when it is used to label a potential <a href=#media-resource>media
resource</a>.</p>
- <p class=note>In the absence of a <!-- pretty crazy -->
- specification to the contrary, the <a href=#mime-type>MIME type</a>
- "<code>application/octet-stream</code>" when used <em>with</em>
- parameters, e.g.
- "<code>application/octet-stream;codecs=theora</code>", <em>is</em>
- <a href=#a-type-that-the-user-agent-knows-it-cannot-render>a type that the user agent knows it cannot render</a>,
- since that parameter is not defined for that type.</p>
+ <p class=note>
+
+ Only the <a href=#mime-type>MIME type</a> <!-- the WG decision started with the next bit, which is not in the style of the spec -->
+
+ "<code>application/octet-stream</code>"
+
+ with no parameters
+
+ is special-cased here; if any parameter appears with it, it
+
+ will <!-- the WG decision that led to this text had a "should", but this is a non-normative section -->
+ be treated just like any other <a href=#mime-type>MIME type</a>.
+ This is a deviation from the rule <!-- in RFC 2046, section 1,
+ paragraph 3 --> that unknown <a href=#mime-type>MIME type</a> parameters
+ should be ignored.
+
+ <!-- but not really a "willful violation" since it's not that the
+ types are not being ignored, just that before the type is handled as
+ a type, there's a special case for a particular set of strings -->
+
+ </p>
+
<dl class=domintro><dt><var title="">media</var> . <code title=dom-navigator-canPlayType><a href=#dom-navigator-canplaytype>canPlayType</a></code>(<var title="">type</var>)</dt>
<dd>
Modified: index
===================================================================
--- index 2011-04-12 21:58:42 UTC (rev 5993)
+++ index 2011-04-12 22:13:47 UTC (rev 5994)
@@ -25976,14 +25976,29 @@
when it is used to label a potential <a href=#media-resource>media
resource</a>.</p>
- <p class=note>In the absence of a <!-- pretty crazy -->
- specification to the contrary, the <a href=#mime-type>MIME type</a>
- "<code>application/octet-stream</code>" when used <em>with</em>
- parameters, e.g.
- "<code>application/octet-stream;codecs=theora</code>", <em>is</em>
- <a href=#a-type-that-the-user-agent-knows-it-cannot-render>a type that the user agent knows it cannot render</a>,
- since that parameter is not defined for that type.</p>
+ <p class=note>
+
+ Only the <a href=#mime-type>MIME type</a> <!-- the WG decision started with the next bit, which is not in the style of the spec -->
+
+ "<code>application/octet-stream</code>"
+
+ with no parameters
+
+ is special-cased here; if any parameter appears with it, it
+
+ will <!-- the WG decision that led to this text had a "should", but this is a non-normative section -->
+ be treated just like any other <a href=#mime-type>MIME type</a>.
+ This is a deviation from the rule <!-- in RFC 2046, section 1,
+ paragraph 3 --> that unknown <a href=#mime-type>MIME type</a> parameters
+ should be ignored.
+
+ <!-- but not really a "willful violation" since it's not that the
+ types are not being ignored, just that before the type is handled as
+ a type, there's a special case for a particular set of strings -->
+
+ </p>
+
<dl class=domintro><dt><var title="">media</var> . <code title=dom-navigator-canPlayType><a href=#dom-navigator-canplaytype>canPlayType</a></code>(<var title="">type</var>)</dt>
<dd>
Modified: source
===================================================================
--- source 2011-04-12 21:58:42 UTC (rev 5993)
+++ source 2011-04-12 22:13:47 UTC (rev 5994)
@@ -27968,14 +27968,32 @@
when it is used to label a potential <span>media
resource</span>.</p>
- <p class="note">In the absence of a <!-- pretty crazy -->
- specification to the contrary, the <span>MIME type</span>
- "<code>application/octet-stream</code>" when used <em>with</em>
- parameters, e.g.
- "<code>application/octet-stream;codecs=theora</code>", <em>is</em>
- <span>a type that the user agent knows it cannot render</span>,
- since that parameter is not defined for that type.</p>
+ <p class="note">
+ <!--END w3c-html-->
+ Only the <span>MIME type</span> <!-- the WG decision started with the next bit, which is not in the style of the spec -->
+ <!--START w3c-html-->
+ "<code>application/octet-stream</code>"
+ <!--END w3c-html-->
+ with no parameters
+ <!--START w3c-html-->
+ is special-cased here; if any parameter appears with it, it
+ <!--END w3c-html-->
+ will <!-- the WG decision that led to this text had a "should", but this is a non-normative section -->
+ <!--START w3c-html--><!--END html--><!--END complete--><!--END epub--><!--END dev-html-->
+ should
+ <!--START html--><!--START complete--><!--START epub--><!--START dev-html-->
+ be treated just like any other <span>MIME type</span>.
+ This is a deviation from the rule <!-- in RFC 2046, section 1,
+ paragraph 3 --> that unknown <span>MIME type</span> parameters
+ should be ignored.
+
+ <!-- but not really a "willful violation" since it's not that the
+ types are not being ignored, just that before the type is handled as
+ a type, there's a special case for a particular set of strings -->
+
+ </p>
+
<dl class="domintro">
<dt><var title="">media</var> . <code title="dom-navigator-canPlayType">canPlayType</code>(<var title="">type</var>)</dt>
More information about the Commit-Watchers
mailing list