[whatwg] <object> behavior

[Boris Zbarsky]

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 
> document.

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.
> 
> Fixed.

Indeed.  Thanks!

>> 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 
>> intentional?
> 
> 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?

-Boris