[whatwg] instantiating display:none plugins
Michael A. Puls II
shadow2531 at gmail.com
Wed Nov 2 08:40:55 PDT 2011
On Tue, 01 Nov 2011 19:36:44 -0400, Robert O'Callahan
<robert at ocallahan.org> wrote:
> "The above algorithm is independent of CSS properties (including
> 'overflow', and 'visibility'). For example, it runs even if the element
> hidden with a 'display:none' CSS style, and does not run again if the
> element's visibility changes."
> Unfortunately this breaks real-world usage. The example we ran into is
> documented here:
> In this case, the site has a display:none autoplay Youtube Flash video
> that's not supposed to play.
> I did some experiments on browser behavior, documented here:
> There are some variations but no browser instantiates a plugin that's
> always display:none.
> I recommend that the spec be changed so that the "steps to (re)determine
> what the object element represents" avoid instantiating plugins that are
> display:none (or have a display:none ancestor). Dynamic changes to the
> display state should queue a task that checks whether the display state
> the element has changed since the last time the "steps to (re)determine
> what the object element represents" ran; if it has, it should rerun those
> As far as I know, there is no need to consider any visibility state other
> than display:none.
These threads (at least) have the discussion on <object> and the css
Boris mention that it was considered a bug by Mozilla that <object> is
affected by the display property (including display: none). Hixie agreed
and said that the author is expected to use JS and not create and append
the <object> until it's expected to be instantiated. I agreed with that,
but also suggested a load-on-demand attribute for <object> for authors
that want to create the object with parsed markup and just defer
instantiation where just removing the attribute with JS would cause it to
instantiate. That wasn't received well though.
Also, the display property never really affected <object> in Opera except
for display: none. But, that's was changed in Opera for images ( <img> and
<object> I think and maybe everything) I think. Opera users are pissed by
the change though because users used display: none for ad-blocking
(including blocking the resource fetching) and Opera didn't provide an
alternative when making the change. See
<http://my.opera.com/community/forums/topic.dml?id=972092>. But, that's
not web-compat-related and not necessarily about plug-ins, but the users
in those threads want the old display: none behavior back.
I still think display: none shouldn't affect <object> instantiation and if
there needs to be a solution, it should be an attribute and we should
evangelize and get any problem sites fixed (by using the attribute for
More information about the whatwg