Skip to content
Permalink
Browse files

[] (0) Add warnings about media elements and track and how to determi…

…ne the type and how we don't know what hte solution is.

Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=11984

git-svn-id: http://svn.whatwg.org/webapps@6826 340c8d12-0b0e-0410-8428-c7bf67bfef74
  • Loading branch information...
Hixie committed Nov 12, 2011
1 parent 314eb0b commit f4f177a986859f2187b806471b7df829154bfe2c
Showing with 117 additions and 62 deletions.
  1. +39 −20 complete.html
  2. +39 −20 index
  3. +39 −22 source
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>
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>
<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
<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
59 index
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>
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>
<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
<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
61 source
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
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>
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
<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

0 comments on commit f4f177a

Please sign in to comment.
You can’t perform that action at this time.