[e] (0) apply wg decision

Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=10202 git-svn-id: http://svn.whatwg.org/webapps@5994 340c8d12-0b0e-0410-8428-c7bf67bfef74
whatwg · Apr 12, 2011 · 5fa120b39e5ea1ea6f5175d4c1f9ad5568c971aa · 5fa120b
1 parent b083760
commit 5fa120b39e5ea1ea6f5175d4c1f9ad5568c971aa
Unified Split

Showing with 69 additions and 21 deletions.

+22 −7 complete.html

+22 −7 index

+25 −7 source
diff --git a/complete.html b/complete.html

  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>
diff --git a/index b/index

  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>
diff --git a/source b/source

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