[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