On Thu, 22 Jul 2010 22:40:44 +0200, Maciej Stachowiak <[email protected]>
wrote:
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.
Right, it certainly isn't useful, I'm just pointing out that this is what
happens if one adds text/plain to the list of "maybe" codecs rather than
ignoring Content-Type altogether, which is the only thing you can do
within the bounds of the current spec to get text/plain to play. The only
3 serious options I know are still the ones I outlined in my earlier email.
--
Philip Jägenstedt
Core Developer
Opera Software
