This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Copying discussion from mailing list which didn't get any feedback (http://lists.w3.org/Archives/Public/public-html/2010Feb/0597.html): "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." 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? 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?
> 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. It can. Historically, for example, PNG support in IE for a while matched this definition. I believe SVG in Mozilla can match this definition (e.g. if used from <embed>, IIRC). > "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? A user agent (typically this would be a browser) can designate (that is, appoint, state that it is the case that) content handlers (that is, code that handles specific kinds of content) to be plugins (i.e. being selectable when the user agent is searching for an applicable plugin for some content of a relevant specific kind, and causing the content of that kind to be rendered in a browsing context as part of a Document's rendering, but not actually introducing a child browsing content nor having any corresponding Node objects in the Document's DOM). > 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"?). I don't think it's needed anywhere else, but yes, if it were, helper app is the normal term for this. > 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". Not any code, no. Typically a browser will not designate its JPEG handler as being a plugin. You can tell if a browser has so designated its content handler by trying to display a JPEG in <embed>. > I fail to understand the comment about <embed>, unless it's mean to > apply to <object> as well. <object> will is not limited to plugins. <embed> is. Assuming the browser has any inline JPEG support at all, the <object> element will render JPEGs whether or not its JPEG handler is designated a plugin. > 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? The text above is non-normative (it doesn't have any conformance criteria), so it doesn't imply anything. It's just giving a vague description of the intent of the flag. In any case, <img>, <audio>, and <video> can never invoke plugins as defined by HTML. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: No change appears to have been requested.
FWIW, I think Opera, Firefox and WebKit support JPEG, PNG and SVG in <embed> without a plugin.
(In reply to comment #1) > > 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. > > It can. Historically, for example, PNG support in IE for a while matched this > definition. I believe SVG in Mozilla can match this definition (e.g. if used > from <embed>, IIRC). Reminder: the definition is: "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." So, if the code handling JPG neither acts as a child browsing context, nor introduces Node objects, than it is a plugin, right? > > "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? > > A user agent (typically this would be a browser) can designate (that is, > appoint, state that it is the case that) content handlers (that is, code that > handles specific kinds of content) to be plugins (i.e. being selectable when > the user agent is searching for an applicable plugin for some content of a > relevant specific kind, and causing the content of that kind to be rendered in > a browsing context as part of a Document's rendering, but not actually > introducing a child browsing content nor having any corresponding Node objects > in the Document's DOM). Can somebody translate this into English for me? > ... > > 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". > > Not any code, no. Typically a browser will not designate its JPEG handler as > being a plugin. You can tell if a browser has so designated its content handler > by trying to display a JPEG in <embed>. In which case you need to change the definition of "plugin" to say so. > ... > > 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? > > The text above is non-normative (it doesn't have any conformance criteria), so > it doesn't imply anything. It's just giving a vague description of the intent > of the flag. Sorry? It totally is normative. Are you saying that UAs are free to ignore this statement? Please clarify. > In any case, <img>, <audio>, and <video> can never invoke plugins as defined by > HTML. In which case the definition of "plugin" needs to state this. BTW: it would be cool if we could have a *discussion* on this on the HTML WG mailing list, that's what it's for. Feel free to follow up over there.
> In which case you need to change the definition of "plugin" to say so. Done. > > > 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? > > > > The text above is non-normative (it doesn't have any conformance criteria), so > > it doesn't imply anything. It's just giving a vague description of the intent > > of the flag. > > Sorry? It totally is normative. Are you saying that UAs are free to ignore this > statement? Please clarify. The statement doesn't say anything. There's no conformance requirement there. It makes no difference if user agents ignore or don't ignore that statement. > > In any case, <img>, <audio>, and <video> can never invoke plugins as defined by > > HTML. > > In which case the definition of "plugin" needs to state this. Why? It seems self-evident, since those sections don't reference the term "plugin". EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: see above
Checked in as WHATWG revision r4996. Check-in comment: Try to clarify the meaning of 'plugin' once more. http://html5.org/tools/web-apps-tracker?from=4995&to=4996
(In reply to comment #4) > > In which case you need to change the definition of "plugin" to say so. > > Done. The only change that might be relevant that I see is that you know say: "... refers to a user-agent defined set..." So the decision whether something is a plugin or not depends on the user agent? > > > > 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? > > > > > > The text above is non-normative (it doesn't have any conformance criteria), so > > > it doesn't imply anything. It's just giving a vague description of the intent > > > of the flag. > > > > Sorry? It totally is normative. Are you saying that UAs are free to ignore this > > statement? Please clarify. > > The statement doesn't say anything. There's no conformance requirement there. > It makes no difference if user agents ignore or don't ignore that statement. If the statement "doesn't say anything" why is it there in the first place? But anyway, there are other statements which state more concrete requirements on handling sandboxed plugins, so the original issue (we need a precise definition of "plugin") doesn't magically go away. > > > In any case, <img>, <audio>, and <video> can never invoke plugins as defined by > > > HTML. > > > > In which case the definition of "plugin" needs to state this. > > Why? It seems self-evident, since those sections don't reference the term > "plugin". I don't see at all how this is self-evident. If Chrome started to display FLV video files using the Adobe-supplied plugin code, would that be a plugin invocation?
(In reply to comment #6) > (In reply to comment #4) > > > In which case you need to change the definition of "plugin" to say so. > > > > Done. > > The only change that might be relevant that I see is that you know say: > > "... refers to a user-agent defined set..." > > So the decision whether something is a plugin or not depends on the user agent? In part, yes (the "something" has to fit the other criteria also). > > > > > "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." > > > > The statement doesn't say anything. There's no conformance requirement there. > > It makes no difference if user agents ignore or don't ignore that statement. > > If the statement "doesn't say anything" why is it there in the first place? It introduces the flag's purpose. > But anyway, there are other statements which state more concrete requirements > on handling sandboxed plugins, so the original issue (we need a precise > definition of "plugin") doesn't magically go away. As far as I can tell, it is well-defined. Is there a specific Web page (e.g. a sample test file) that you can use to show me what it is that is undefined? > > > > In any case, <img>, <audio>, and <video> can never invoke plugins as defined by > > > > HTML. > > > > > > In which case the definition of "plugin" needs to state this. > > > > Why? It seems self-evident, since those sections don't reference the term > > "plugin". > > I don't see at all how this is self-evident. > > If Chrome started to display FLV video files using the Adobe-supplied plugin > code, would that be a plugin invocation? In <video>? No. I don't see why the provenance of the code would be relevant. That would just be a codec. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: See above.