[Bug 13995] Don't check Content-Type for <track>

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

--- Comment #1 from Philip Jägenstedt <philipj@opera.com> 2011-09-01 11:55:21 UTC ---
"The tasks queued by the fetching algorithm on the networking task source to
process the data as it is being fetched must examine the resource's Content
Type metadata, once it is available, if it ever is. If no Content Type metadata
is ever available, or if the type is not recognised as a text track format,
then the resource's format must be assumed to be unsupported (this causes the
load to fail, as described below). If a type is obtained, and represents a
supported text track format, then the resource's data must be passed to the
appropriate parser  (e.g. the WebVTT parser if the Content Type metadata is
text/vtt)  as it is received, with the text track list of cues being used for
that parser's output."

We don't want to implement this, given the experience with <video>, see
http://www.w3.org/html/wg/wiki/ChangeProposals/NoVideoContentType#Issues_for_Authors

WebVTT already has the WEBVTT header magic to differentiate it from other
formats if we should ever support such in <track>.

The main consequence of doing this check is that <track> will appear broken to
all authors when they first test it. Even if they figure out how to set
Content-Type, it'll mostly be a waste of time and not provide any real
benefits.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 1 September 2011 11:55:23 UTC