[whatwg] <object> behavior
bzbarsky at MIT.EDU
Mon Aug 31 06:25:23 PDT 2009
Ian Hickson wrote:
> On Tue, 25 Aug 2009, Andrew Oakley wrote:
>> So if we had a type attribute of application/x-shockwave-flash, and a
>> Content-Type header of image/png we would use the flash plugin.
>> Following the HTML5 spec we would use the image renderer.
> Ah, yes, that's intentional (doing otherwise violates HTTP1.1). Is this
> something you're forced into for compatibility?
Yes. Initially we implemented preferring the HTTP content-type header
to the type attribute in
<https://bugzilla.mozilla.org/show_bug.cgi?id=1156>. This caused a
variety of compatibility issues:
1) Various sites serving plug-in data as text/plain or
application/octet-stream. This was resolved by using the regular "is
this text actually binary?" sniffer and dispatching based on type hint
(in practice the type attribute at the time, but see below) if we have
sniffed binary or application/octet-stream. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=389677>, which lists two
sites that hit this. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=390891> for another
example of this problem.
2) A number of sites, including for example all the Apple keynote
videos, just plain served plug-ins with the wrong server-provided MIME
type which was not either text/plain or application/octet-stream. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=416867>). Note that we
did some debugging here and found that Opera had the same compatibility
issues we did on the Apple videos; Safari did not because it was mapping
a limited set of ActiveX classids to its internal MIME type dispatch and
thus using the outer <object>, not the inner one. As a result of this
issue, we introduced our current behavior of preferring @type if it's a
type we handle via a plug-in.
3) A number of sites not only send a bogus server-provided type (e.g.
application/octet-stream) but also use a bogus type attribute
(specifically, application/plugin-mimetype; I suspect this is a relic of
Netscape's devedge documentation using that as an example placeholder).
See <https://bugzilla.mozilla.org/show_bug.cgi?id=393756>. The URI
extension is used to get the type to really use in those cases in
Gecko... If desired, I could probably dig through and figure out the
exact conditions that trigger this case.
P.S. For <embed> things are different but still quite interesting, of
course... In particular, one has to use the URI extension there, not
just the @type.
More information about the whatwg