W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2011

[whatwg] instantiating display:none plugins

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 2 Nov 2011 12:36:44 +1300
Message-ID: <CAOp6jLaC5XNqAnmk6fbZk1NcR31_Wbok1ykhXYHKbQZNk1c_+g@mail.gmail.com>
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.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]
Received on Tuesday, 1 November 2011 16:36:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:09 UTC