[whatwg] <object> behavior

[Ian Hickson]

On Mon, 14 Sep 2009, Boris Zbarsky wrote:
> 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.

Ah, ok. Yes, per spec display:none doesn't affect this.


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

What exactly are you proposing here?

 - Always honour type="" if it's a UA-supported type, ignoring server- 
   provided content-type?
 - Always honour type="" without sniffing if it matches the server- 
   provided content-type, even if normally that type would be sniffed?
 - Just honour type="text/plain" regardless of the server type, but for
   other UA-supported type=""s, use the server type?


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

I thought I had. Can you walk me through how anything labeled text/plain 
could get sniffed as text/html with the new text?


> That's a critical issue, no?

Yes.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'