[whatwg] <object> behavior
bzbarsky at MIT.EDU
Mon Sep 14 05:42:10 PDT 2009
Ian Hickson wrote:
> On Sun, 6 Sep 2009, Boris Zbarsky wrote:
>> 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 thought by you, but apparently I misunderstood the point you had been
> making! I've changed HTML5 to not instantiate plugins when their element
> is not in the document, and to uninstantiate any that are removed from the
Ah. I must have been unclear. We (Gecko) consider it a bug that a
display:none <object> in a document doesn't instantiate the plug-in. I
don't think we have an opinion yet on <object>s that are not in
documents at all; I suspect making those instantiate would be
suboptimal, but that's really just a gut feeling with no data to back it up.
> I didn't realise that the list of types the UA supported and the list of
> types plugins supported could overlap.
>> 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
> Yes. This is the same as happens if you navigate straight to such a file,
> as far as I can tell. Why would we not want that?
One difference is that in this case in addition to the text/plain
content-type header (which we know is untrustworthy) there is also an
out-of-band @type attribute saying text/plain, which presumably
represents the author's wishes.
Since the whole point of text/plain sniffing is a workaround around a
known issue where content is reliably mis-marked as text/plain, and
since in this case there is a source of MIME information that's more
reliable than that, it's not clear to me why we want to continue sniffing.
Of course if there is no @type there is no problem; I'm specifically
concerned about the @type="text/plain" case here.
My concern about text/plain data being sniffed as text/html by your
current algorithm (even with the changes you've made) seems to remain
unaddressed. That's a critical issue, no?
More information about the whatwg