- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 22 Jul 2010 13:40:44 -0700
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. Regards, Maciej
Received on Thursday, 22 July 2010 13:40:44 UTC