[html5] r6826 - [] (0) Add warnings about media elements and track and how to determine the type [...]

whatwg at whatwg.org whatwg at whatwg.org
Fri Nov 11 16:22:16 PST 2011


Author: ianh
Date: 2011-11-11 16:22:15 -0800 (Fri, 11 Nov 2011)
New Revision: 6826

Modified:
   complete.html
   index
   source
Log:
[] (0) Add warnings about media elements and track and how to determine the type and how we don't know what hte solution is.
Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=11984

Modified: complete.html
===================================================================
--- complete.html	2011-11-11 19:45:09 UTC (rev 6825)
+++ complete.html	2011-11-12 00:22:15 UTC (rev 6826)
@@ -27542,6 +27542,19 @@
     switching to a streaming protocol. The user agent must consider a
     resource erroneous only if it has given up trying to fetch it.</p>
 
+    <p class=critical>This specification does not currently say
+    whether or how to check the MIME types of the media resources, or
+    whether or how to perform file type sniffing using the actual file
+    data. Implementors differ in their intentions on this matter and
+    it is therefore unclear what the right solution is. In the absence
+    of any requirement here, the HTTP specification's strict
+    requirement to follow the Content-Type header prevails
+    ("Content-Type specifies the media type of the underlying data."
+    ... "If and only if the media type is not given by a Content-Type
+    field, the recipient MAY attempt to guess the media type via
+    inspection of its content and/or the name extension(s) of the URI
+    used to identify the resource.").</p>
+
     <p>The <a href=#networking-task-source>networking task source</a> <a href=#concept-task title=concept-task>tasks</a> to process the data as it is
     being fetched must, when appropriate, include the relevant
     substeps from the following list:</p>
@@ -27550,13 +27563,6 @@
      to network errors, causing the user agent to give up trying to
      fetch the resource</dt>
 
-     <dt>If the <a href=#media-resource>media resource</a> is found to have <a href=#content-type title=Content-Type>Content-Type metadata</a> that, when
-     parsed as a <a href=#mime-type>MIME type</a> (including any codecs
-     described by the <code title="">codecs</code> parameter, if the
-     parameter is defined for that type), represents <a href=#a-type-that-the-user-agent-knows-it-cannot-render>a type that
-     the user agent knows it cannot render</a> (even if the actual
-     <a href=#media-data>media data</a> is in a supported format)</dt>
-
      <dt>If the <a href=#media-data>media data</a> can be fetched but is found by
      inspection to be in an unsupported format, or can otherwise not
      be rendered at all</dt>
@@ -31376,9 +31382,10 @@
     <p>If <var title="">URL</var> is not the empty string, perform a
     <a href=#potentially-cors-enabled-fetch>potentially CORS-enabled fetch</a> of <var title="">URL</var>, with the <i>mode</i> being the state of the
     <a href=#media-element>media element</a>'s <code title=attr-media-crossorigin><a href=#attr-media-crossorigin>crossorigin</a></code> content
-    attribute, the <i title="">origin</i> being the <a href=#origin>origin</a> of the
-    <a href=#media-element>media element</a>'s <code><a href=#document>Document</a></code>, and the
-    <i>default origin behaviour</i> set to <i>fail</i>.</p>
+    attribute, the <i title="">origin</i> being the
+    <a href=#origin>origin</a> of the <a href=#media-element>media element</a>'s
+    <code><a href=#document>Document</a></code>, and the <i>default origin behaviour</i> set
+    to <i>fail</i>.</p>
 
     <p>The resource obtained in this fashion, if any, contains the
     text track data. If any data is obtained, it is by definition
@@ -31388,17 +31395,29 @@
     <p>The <a href=#concept-task title=concept-task>tasks</a> <a href=#queue-a-task title="queue
     a task">queued</a> by the <a href=#fetch title=fetch>fetching
     algorithm</a> on the <a href=#networking-task-source>networking task source</a> to
-    process the data as it is being fetched must <a href=#content-type-sniffing-0 title="Content-Type sniffing">determine the sniffed type of a the
-    resource</a>. If the sniffed type of the resource is not a
-    supported text track format, the load will fail, as described
-    below. Otherwise, the resource's data must be passed to the
-    appropriate parser
-<!--TTVTT-->
-    (e.g. the <a href=#webvtt-parser>WebVTT parser</a> if the file starts with the "<code title="">WEBVTT</code>" signature)
-<!--TTVTT-->
-    as it is received, with the <a href=#text-track-list-of-cues>text track list of cues</a>
-    being used for that parser's output.</p>
+    process the data as it is being fetched must <!--<span
+    title="Content-Type sniffing">-->determine the <!--sniffed--> type
+    of a the resource<!--</span>-->. If the <!--sniffed--> type of the
+    resource is not a supported text track format, the load will fail,
+    as described below. Otherwise, the resource's data must be passed
+    to the appropriate parser (e.g. the <a href=#webvtt-parser>WebVTT parser</a><!--
+    if the file starts with the "<code title="">WEBVTT</code>"
+    signature-->) as it is received, with the <a href=#text-track-list-of-cues>text track list of
+    cues</a> being used for that parser's output.</p>
 
+    <p class=critical>This specification does not currently say
+    whether or how to check the MIME types of text tracks, or whether
+    or how to perform file type sniffing using the actual file data.
+    Implementors differ in their intentions on this matter and it is
+    therefore unclear what the right solution is. In the absence of
+    any requirement here, the HTTP specification's strict requirement
+    to follow the Content-Type header prevails ("Content-Type
+    specifies the media type of the underlying data." ... "If and only
+    if the media type is not given by a Content-Type field, the
+    recipient MAY attempt to guess the media type via inspection of
+    its content and/or the name extension(s) of the URI used to
+    identify the resource.").</p>
+
     <p>If the <a href=#fetch title=fetch>fetching algorithm</a> fails for
     any reason (network error, the server returns an error code, a
     cross-origin check fails, etc), if <var title="">URL</var> is the

Modified: index
===================================================================
--- index	2011-11-11 19:45:09 UTC (rev 6825)
+++ index	2011-11-12 00:22:15 UTC (rev 6826)
@@ -27542,6 +27542,19 @@
     switching to a streaming protocol. The user agent must consider a
     resource erroneous only if it has given up trying to fetch it.</p>
 
+    <p class=critical>This specification does not currently say
+    whether or how to check the MIME types of the media resources, or
+    whether or how to perform file type sniffing using the actual file
+    data. Implementors differ in their intentions on this matter and
+    it is therefore unclear what the right solution is. In the absence
+    of any requirement here, the HTTP specification's strict
+    requirement to follow the Content-Type header prevails
+    ("Content-Type specifies the media type of the underlying data."
+    ... "If and only if the media type is not given by a Content-Type
+    field, the recipient MAY attempt to guess the media type via
+    inspection of its content and/or the name extension(s) of the URI
+    used to identify the resource.").</p>
+
     <p>The <a href=#networking-task-source>networking task source</a> <a href=#concept-task title=concept-task>tasks</a> to process the data as it is
     being fetched must, when appropriate, include the relevant
     substeps from the following list:</p>
@@ -27550,13 +27563,6 @@
      to network errors, causing the user agent to give up trying to
      fetch the resource</dt>
 
-     <dt>If the <a href=#media-resource>media resource</a> is found to have <a href=#content-type title=Content-Type>Content-Type metadata</a> that, when
-     parsed as a <a href=#mime-type>MIME type</a> (including any codecs
-     described by the <code title="">codecs</code> parameter, if the
-     parameter is defined for that type), represents <a href=#a-type-that-the-user-agent-knows-it-cannot-render>a type that
-     the user agent knows it cannot render</a> (even if the actual
-     <a href=#media-data>media data</a> is in a supported format)</dt>
-
      <dt>If the <a href=#media-data>media data</a> can be fetched but is found by
      inspection to be in an unsupported format, or can otherwise not
      be rendered at all</dt>
@@ -31376,9 +31382,10 @@
     <p>If <var title="">URL</var> is not the empty string, perform a
     <a href=#potentially-cors-enabled-fetch>potentially CORS-enabled fetch</a> of <var title="">URL</var>, with the <i>mode</i> being the state of the
     <a href=#media-element>media element</a>'s <code title=attr-media-crossorigin><a href=#attr-media-crossorigin>crossorigin</a></code> content
-    attribute, the <i title="">origin</i> being the <a href=#origin>origin</a> of the
-    <a href=#media-element>media element</a>'s <code><a href=#document>Document</a></code>, and the
-    <i>default origin behaviour</i> set to <i>fail</i>.</p>
+    attribute, the <i title="">origin</i> being the
+    <a href=#origin>origin</a> of the <a href=#media-element>media element</a>'s
+    <code><a href=#document>Document</a></code>, and the <i>default origin behaviour</i> set
+    to <i>fail</i>.</p>
 
     <p>The resource obtained in this fashion, if any, contains the
     text track data. If any data is obtained, it is by definition
@@ -31388,17 +31395,29 @@
     <p>The <a href=#concept-task title=concept-task>tasks</a> <a href=#queue-a-task title="queue
     a task">queued</a> by the <a href=#fetch title=fetch>fetching
     algorithm</a> on the <a href=#networking-task-source>networking task source</a> to
-    process the data as it is being fetched must <a href=#content-type-sniffing-0 title="Content-Type sniffing">determine the sniffed type of a the
-    resource</a>. If the sniffed type of the resource is not a
-    supported text track format, the load will fail, as described
-    below. Otherwise, the resource's data must be passed to the
-    appropriate parser
-<!--TTVTT-->
-    (e.g. the <a href=#webvtt-parser>WebVTT parser</a> if the file starts with the "<code title="">WEBVTT</code>" signature)
-<!--TTVTT-->
-    as it is received, with the <a href=#text-track-list-of-cues>text track list of cues</a>
-    being used for that parser's output.</p>
+    process the data as it is being fetched must <!--<span
+    title="Content-Type sniffing">-->determine the <!--sniffed--> type
+    of a the resource<!--</span>-->. If the <!--sniffed--> type of the
+    resource is not a supported text track format, the load will fail,
+    as described below. Otherwise, the resource's data must be passed
+    to the appropriate parser (e.g. the <a href=#webvtt-parser>WebVTT parser</a><!--
+    if the file starts with the "<code title="">WEBVTT</code>"
+    signature-->) as it is received, with the <a href=#text-track-list-of-cues>text track list of
+    cues</a> being used for that parser's output.</p>
 
+    <p class=critical>This specification does not currently say
+    whether or how to check the MIME types of text tracks, or whether
+    or how to perform file type sniffing using the actual file data.
+    Implementors differ in their intentions on this matter and it is
+    therefore unclear what the right solution is. In the absence of
+    any requirement here, the HTTP specification's strict requirement
+    to follow the Content-Type header prevails ("Content-Type
+    specifies the media type of the underlying data." ... "If and only
+    if the media type is not given by a Content-Type field, the
+    recipient MAY attempt to guess the media type via inspection of
+    its content and/or the name extension(s) of the URI used to
+    identify the resource.").</p>
+
     <p>If the <a href=#fetch title=fetch>fetching algorithm</a> fails for
     any reason (network error, the server returns an error code, a
     cross-origin check fails, etc), if <var title="">URL</var> is the

Modified: source
===================================================================
--- source	2011-11-11 19:45:09 UTC (rev 6825)
+++ source	2011-11-12 00:22:15 UTC (rev 6826)
@@ -29733,6 +29733,19 @@
     switching to a streaming protocol. The user agent must consider a
     resource erroneous only if it has given up trying to fetch it.</p>
 
+    <p class="critical">This specification does not currently say
+    whether or how to check the MIME types of the media resources, or
+    whether or how to perform file type sniffing using the actual file
+    data. Implementors differ in their intentions on this matter and
+    it is therefore unclear what the right solution is. In the absence
+    of any requirement here, the HTTP specification's strict
+    requirement to follow the Content-Type header prevails
+    ("Content-Type specifies the media type of the underlying data."
+    ... "If and only if the media type is not given by a Content-Type
+    field, the recipient MAY attempt to guess the media type via
+    inspection of its content and/or the name extension(s) of the URI
+    used to identify the resource.").</p>
+
     <p>The <span>networking task source</span> <span
     title="concept-task">tasks</span> to process the data as it is
     being fetched must, when appropriate, include the relevant
@@ -29744,14 +29757,6 @@
      to network errors, causing the user agent to give up trying to
      fetch the resource</dt>
 
-     <dt>If the <span>media resource</span> is found to have <span
-     title="Content-Type">Content-Type metadata</span> that, when
-     parsed as a <span>MIME type</span> (including any codecs
-     described by the <code title="">codecs</code> parameter, if the
-     parameter is defined for that type), represents <span>a type that
-     the user agent knows it cannot render</span> (even if the actual
-     <span>media data</span> is in a supported format)</dt>
-
      <dt>If the <span>media data</span> can be fetched but is found by
      inspection to be in an unsupported format, or can otherwise not
      be rendered at all</dt>
@@ -34213,9 +34218,10 @@
     title="">URL</var>, with the <i>mode</i> being the state of the
     <span>media element</span>'s <code
     title="attr-media-crossorigin">crossorigin</code> content
-    attribute, the <i title="">origin</i> being the <span>origin</span> of the
-    <span>media element</span>'s <code>Document</code>, and the
-    <i>default origin behaviour</i> set to <i>fail</i>.</p>
+    attribute, the <i title="">origin</i> being the
+    <span>origin</span> of the <span>media element</span>'s
+    <code>Document</code>, and the <i>default origin behaviour</i> set
+    to <i>fail</i>.</p>
 
     <p>The resource obtained in this fashion, if any, contains the
     text track data. If any data is obtained, it is by definition
@@ -34225,18 +34231,29 @@
     <p>The <span title="concept-task">tasks</span> <span title="queue
     a task">queued</span> by the <span title="fetch">fetching
     algorithm</span> on the <span>networking task source</span> to
-    process the data as it is being fetched must <span
-    title="Content-Type sniffing">determine the sniffed type of a the
-    resource</span>. If the sniffed type of the resource is not a
-    supported text track format, the load will fail, as described
-    below. Otherwise, the resource's data must be passed to the
-    appropriate parser
-<!--END w3c-html--><!--TTVTT-->
-    (e.g. the <span>WebVTT parser</span> if the file starts with the "<code title="">WEBVTT</code>" signature)
-<!--START w3c-html--><!--TTVTT-->
-    as it is received, with the <span>text track list of cues</span>
-    being used for that parser's output.</p>
+    process the data as it is being fetched must <!--<span
+    title="Content-Type sniffing">-->determine the <!--sniffed--> type
+    of a the resource<!--</span>-->. If the <!--sniffed--> type of the
+    resource is not a supported text track format, the load will fail,
+    as described below. Otherwise, the resource's data must be passed
+    to the appropriate parser (e.g. the <span>WebVTT parser</span><!--
+    if the file starts with the "<code title="">WEBVTT</code>"
+    signature-->) as it is received, with the <span>text track list of
+    cues</span> being used for that parser's output.</p>
 
+    <p class="critical">This specification does not currently say
+    whether or how to check the MIME types of text tracks, or whether
+    or how to perform file type sniffing using the actual file data.
+    Implementors differ in their intentions on this matter and it is
+    therefore unclear what the right solution is. In the absence of
+    any requirement here, the HTTP specification's strict requirement
+    to follow the Content-Type header prevails ("Content-Type
+    specifies the media type of the underlying data." ... "If and only
+    if the media type is not given by a Content-Type field, the
+    recipient MAY attempt to guess the media type via inspection of
+    its content and/or the name extension(s) of the URI used to
+    identify the resource.").</p>
+
     <p>If the <span title="fetch">fetching algorithm</span> fails for
     any reason (network error, the server returns an error code, a
     cross-origin check fails, etc), if <var title="">URL</var> is the




More information about the Commit-Watchers mailing list