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

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

--- Comment #32 from Philip Jägenstedt <philipj@opera.com> 2011-10-26 08:53:46 UTC ---
(In reply to comment #31)

> Currently, what Anne has said and what Philip has said conflict (comment 27 and
> comment 29). If we do what <img> does, then we have to explicitly list all the
> types we _don't_ want to sniff, which would include the TTML type. But that
> doesn't seem to be what Philip is suggesting; if I understand correctly, that's
> more a matter of just having a list of formats that we sniff for regardless of
> the type when used with <track>, and then falling back on the default; for
> navigation, though, the sniffing would work as now, with just one more row in
> the MIMESNIFF table.

Hmm, I hadn't noticed that special case of image sniffing and note that there
is nothing similar for sniffing video (although that section is fiction until
bug 11984 is resolved). Is there a particular reason for special-casing
"image/svg+xml" that would apply to TTML as well? If not, my suggestion in
comment 21 stands.

> I guess the remaining question is, if we fallback to the Content-Type, and a 
> file is labeled as text/vtt but doesn't have the WEBVTT signature, should we
> still try to parse it as WEBVTT, or should we not recognise it? (I guess if we
> say that if the signature is missing we still fire onerror, it becomes a
> non-issue. See bug 14294.)

We should still try to parse it and it will fail. The whole assumption here is
that this bug together with bug 14294 will allow implementations that only
support WebVTT to ignore Content-Type and just try to parse it.

-- 
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 Wednesday, 26 October 2011 08:53:51 UTC