[whatwg] instantiating display:none plugins

On Tue, 01 Nov 2011 19:36:44 -0400, Robert O'Callahan  
<robert at ocallahan.org> wrote:

> http://www.whatwg.org/specs/web-apps/current-work/#the-object-element
> "The above algorithm is independent of CSS properties (including  
> 'display',
> 'overflow', and 'visibility'). For example, it runs even if the element  
> is
> 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:
> https://bugzilla.mozilla.org/show_bug.cgi?id=697651
> 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:
> https://bugzilla.mozilla.org/show_bug.cgi?id=697651#c19
> 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  
> of
> 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
> steps.
>
> 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  
display property:

<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-September/thread.html#22563>
<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-October/thread.html#23641>
<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-November/024010.html>
<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/thread.html#24434>

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=1112972> and  
<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  
example).


-- 
Michael

Received on Wednesday, 2 November 2011 08:40:55 UTC