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

[whatwg] <video> application/octet-stream

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 21 Jul 2010 14:10:54 -0400
Message-ID: <4C47382E.7060900@mit.edu>
On 7/21/10 9:10 AM, Nils Dagsson Moskopp wrote:
> While the robustness principle is indeed a good start, this is a
> situation where we are mostly starting with a clean slate.

Maciej's point was that Safari doesn't feel like it's starting with a 
clean slate.

> Lets not forget that the broken situation is one that is not commonly
> encountered with<video>, only with distinct proprietary plugins.
> Whoever can change the markup on the web site on this level, will, in
> most cases, be able to change the MIME type as well (adding one line
> to .htaccess for each type is not hard)

I believe this claim is false.  There are plenty of people who can 
change the HTML but not the web server configuration, even on a 
per-directory basis....

> so this is a minimal burden
> on site authors (or none at all for shared hosting, as soon as default
> MIME mapping for such media types has trickled into web server
> defaults).

You mean 7-8 years from now?  For example, Apache 2 has been out since 
2002, and yet Apache 1 is still fairly widely used...

> So, carrying this inconsistency over to a standards-based world would
> make MIME types essentially useless for media content, necessitating a
> partial download and sniffing code, like unixoid FILE(1).

Yep; we're already there.  The MIME type typically lists the container 
format only and then you have to either sniff or read format metadata in 
the container to figure out what you're _actually_ dealing with.

I don't like sniffing any more than the next guy, but the work needed to 
properly MIME label a modern media format (with the whole container and 
multiple streams thing) is ... excessive.  I doubt anyone's going to do 
it, so we're really talking about just labeling the container format, right?

-Boris
Received on Wednesday, 21 July 2010 11:10:54 UTC

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