[whatwg] <object> behavior
bzbarsky at MIT.EDU
Sun Sep 6 11:53:47 PDT 2009
Ian Hickson wrote:
>> 1. Its element must be attached to the document.
> I'm told this is considered a bug.
Told by whom, if I might ask?
> I've updated the spec to do the above, to the extent that I could work
> out what the expected result is.
This doesn't actually specify what Gecko implements. In particular, the
current spec text means that if I have a plug-in installed which
supports text/html and the <object> has type="text/html" then the data
should be rendered as text/html regardless of the server type, even
though it will be rendered by the browser itself, not by the plug-in.
This was explicitly something I wanted to avoid in the Gecko code, and
was called out that way in the bugs I referenced.
Was that difference intentional?
Another other difference is the way data-sniffing is applied. In Gecko,
data-sniffing is applied on the HTTP layer in this case, so that the
type considered in subsubstep 3 of your algorithm already takes
data-sniffing into account. In practical terms the difference is that
data-sniffing only occurs if the HTTP response from the server doesn't
deliver a Content-Type header (modulo the text/plain thing, of course).
If we assume that no plug-in has registered itself for
application/octet-stream, then the only cases that lead to a different
behavior between the two algorithms are those of the server sending
text/plain (for binary data) or application/octet-stream as the type.
Your algorithm leads to data-snifing in both cases, while no
data-sniffing is performed in Gecko for either case.
I'm not particularly happy performing data-sniffing in those cases,
particularly the text/plain case (since that can lead to such data being
handled as text/html by the UA, given how your spec text is written
As far as text/plain goes, the current spec text means that if I have a
PostScript file that includes some "binary" bytes in the first 512 bytes
and my web server sends text/plain for it and the <object> has a type
attribute with the value "text/plain" then the data will be treated as
application/postscript. That doesn't seem desirable to me. Is it
>> 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.
> I haven't specced this for <object> yet -- let me know exactly what the
> spec should say if you want this added also. I'd rather have as little
> dependence on extensions as possible.
What the Gecko code basically does is that if the type is
application/octet-stream after everything else has been done (so the
place where your current spec says "then change the resource type to be
unknown, so that the sniffing rules in the next step are invoked") then
we examine the extension of the URI. If that extension exists and if
there's a plug-in registered for that extension, then we set the
"resource type" (in your current draft's terms) to be the associated
MIME type reported by the plug-in. I'm not sure where this list of
(extension,type) pairs comes from, but it looks like the plug-in
provides it somehow (possibly even in that form, looking at
More information about the whatwg