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
