[Bug 9221] still unclear definition of "plugin"

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9221


Julian Reschke <julian.reschke@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |




--- Comment #3 from Julian Reschke <julian.reschke@gmx.de>  2010-04-01 10:10:10 ---
(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.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 1 April 2010 10:10:12 UTC