- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 11 Jun 2012 22:48:57 -0700
- To: Josh Aas <joshmoz@gmail.com>
- Cc: whatwg@whatwg.org
I'm somewhat skeptical whether adding such an DOM property will actually solve the problem. I would expect that many sites that use hidden plug-ins won't update to use the new DOM property, which means you'll need a solution that doesn't involve the web site changing its code. One approach is to provide a UI affordance for playing the plug-in outside of the web page itself. Adam On Mon, Jun 11, 2012 at 5:29 PM, Josh Aas <joshmoz@gmail.com> wrote: > Mozilla has been working on a click-to-play feature for plugins. The > feature currently breaks a large number of sites because it interacts > poorly with scripting and fallback schemes. For example, quite a bit > of plugin usage doesn't involve user-visible content but rather plugin > instances that exist for scripting alone. When instances aren't > created as expected for script calls, the resulting exceptions cause > problems. > > In order for click-to-play to be a viable feature we'll probably need > to allow pages with complex plugin usage (i.e. scripting) to query for > click-to-play state. > > This could be expressed via a Web IDL enum property on embed and > object elements. The property could be called something like > "pluginState". The states might be (with apologies for the rough > names): > > - not-plugin (object/embed is some other type like image or document) > - active (plugin instance created, running) > - inactive (e.g. crashed) > - no-handler (e.g. missing plugin) > - click-to-play (click-to-play UI is diplayed, should become active upon click) > > Thoughts? > > -- > Josh Aas > Mozilla Corporation
Received on Tuesday, 12 June 2012 05:50:02 UTC