[whatwg] <object> behavior
ian at hixie.ch
Tue Sep 15 05:23:53 PDT 2009
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
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
> 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-
- 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
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?
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg