On Jul 22, 2010, at 3:30 AM, Philip Jägenstedt wrote:
> On Thu, 22 Jul 2010 11:22:45 +0200, Henri Sivonen <[email protected]> wrote:
>
>> Chris Double wrote:
>>> As I mentioned in a previous email, the sniffing could result in a
>>> reasonable amount of data being consumed. I'm sure people who run
>>> sites that share HTML 5 video would appreciate browsers not consuming
>>> data bandwidth to sniff files that they've already specified as being
>>> something the browser doesn't support.
>>
>> I think the solution to this concern is to allow authors of
>> bandwidth-sensitive to specify the type attribute on <source> or the
>> Content-Type header on the HTTP response to say something other than
>> application/octet-stream or text/plain. For best performance, authors should
>> use the type attribute in multi-<source> cases anyway.
>
> Chrome and Safari ignore the MIME type altogether, in my opinion if we align
> with that we should do it full out, not just by adding text/plain to the
> whitelist, as that would either require (a) canPlayType("text/plain") to
> return "maybe" or (b) different code paths for checking the MIME type in
> Content-Type and for canPlayType.
>
I don't think canPlayType("text/plain") has to return "maybe". It's not useful
for a Web developer to test for the browser's ability to sniff to overcome a
bad MIME type. canPlayType should be thought of as testing whether the browser
could play a media resource that is "really" of a given type, rather than
labeled with that type over HTTP.
Regards,
Maciej
