W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2010

[whatwg] <video> application/octet-stream

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 22 Jul 2010 13:40:44 -0700
Message-ID: <15A95FAE-6D02-4E05-B079-94C6674BA3BF@apple.com>

On Jul 22, 2010, at 3:30 AM, Philip J?genstedt wrote:

> On Thu, 22 Jul 2010 11:22:45 +0200, Henri Sivonen <hsivonen at iki.fi> 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.

Received on Thursday, 22 July 2010 13:40:44 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:25 UTC