- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 17 Feb 2010 16:29:06 +0100
- To: "public-html@w3.org" <public-html@w3.org>
- CC: Leonard Rosenthol <lrosenth@adobe.com>, Adam Barth <w3c@adambarth.com>, Maciej Stachowiak <mjs@apple.com>
On 25.01.2010 15:19, Julian Reschke wrote: > ... > Looking into this I just realized that, to begin with, we may have to > fix the definition of plugin. It used to be non-critical, but now it's > referred to for iframe/@sandbox it is. > > From <http://dev.w3.org/html5/spec/Overview.html#plugins>: > > "The term plugin is used to mean any content handler for Web content > types that are either not supported by the user agent natively or that > do not expose a DOM, which supports rendering the content as part of the > user agent's interface." > > - "Web content type" appears to be undefined. Is it just a media type? > > - "do not expose a DOM": that seems to the content handler for JPGs a > plugin, right? > ... This was raised as <http://www.w3.org/Bugs/Public/show_bug.cgi?id=8828>; and we now have a new definition: "The term plugin is used to mean any content handler that supports displaying content as part of the user agent's rendering of a Document object, but that neither acts as a child browsing context of the Document nor introduces any Node objects to the Document's DOM. Typically such content handlers are provided by third parties, though a user agent can designate content handlers to be plugins." That's better, as it doesn't rely on undefined terminology. I'm still confused about whether the code that displays a JPG is a plugin or not. It seems to fall under the definition above. Also: "Typically such content handlers are provided by third parties, though a user agent can designate content handlers to be plugins." I have a hard time understanding what the 2nd part of this sentence means; can somebody help me with that? The text continues with: "One example of a plugin would be a PDF viewer that is instantiated in a browsing context when the user navigates to a PDF file. This would count as a plugin regardless of whether the party that implemented the PDF viewer component was the same as that which implemented the user agent itself. However, a PDF viewer application that launches separate from the user agent (as opposed to using the same interface) is not a plugin by this definition." That's good; it clarifies that a PDF viewer built into the UA (such as on Safari Mac) has the same status as Acrobat Reader. Looking at "...However, a PDF viewer application that launches separate from the user agent (as opposed to using the same interface) is not a plugin by this definition." ...we might want to consider to coin a term for this; it might be needed in other places ("helper application"?). Going back to Bugzilla; Ian writes in <http://www.w3.org/Bugs/Public/show_bug.cgi?id=8828#c5>: > It's possible for a plugin to support JPG types, yes. More common is for > browsers to natively support SVG or PDF yet have that support fall into the > "plugin" definition. Really the only effect is whether <embed> can display the > content or not. So this confirms that any code that displays a JPG falls under the definition of "plugin". I fail to understand the comment about <embed>, unless it's mean to apply to <object> as well. The whole thread was started because of "sandboxed" vs plugins. The definition of <iframe> currently says: "The sandboxed plugins browsing context flag This flag prevents content from instantiating plugins, whether using the embed element, the object element, the applet element, or through navigation of a nested browsing context." Does that imply that a plugin that was invoked through <img>, <audio> or <video> would be allowed to run? Best regards, Julian
Received on Wednesday, 17 February 2010 15:29:47 UTC