[whatwg] instantiating display:none plugins

[Michael A. Puls II]

On Wed, 02 Nov 2011 13:04:54 -0400, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 11/2/11 11:40 AM, Michael A. Puls II wrote:
>> Boris mention that it was considered a bug by Mozilla that <object> is
>> affected by the display property (including display: none).
>
> The bug in Mozilla was pretty broad: any changes to the CSS box  
> structure affected the plug-in.  That's the bug we have a fix for and  
> are testing now.  The initial fix made display:none not affect the  
> plug-in; Robert is reporting that this was found to not be  
> web-compatible.

Understood.

>> 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.
>
> That's nice, but that expectation is broken since no commonly used  
> browser requires authors to do that... so they don't.

Understood. I thought they were all planning on doing it though and just  
haven't gotten to that part of HTML5 yet.

>> Also, the display property never really affected <object> in Opera
>> except for display: none.
>
> Yes; this thread is about "display:none" and nothing else.

Understood.

>> 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
>
> I'm not sure you understand.
>
> The patch to make display:none is not even checked into the main Mozilla  
> source tree.  The only people who have been running with that patch are  
> those who manually applied it to a local source tree and then compiled.  
>   That's about 3 people or so.  They've been running with this patch for  
> a few weeks.  As of a week ago, at least one site was identified that  
> has issues as a result.
>
> So after a week or two of use by 3 people we already have one site the  
> change is not compatible with.  Statistically speaking, the chance that  
> the number of such sites is small is very low.  Just for scale, it  
> usually it takes testing over months by millions of users to discover  
> that something is not compatible enough with existing content.  So I  
> suspect that the evangelism effort here would be rather like carrying  
> water in a sieve.
>
> Add to this the fact that currently all browsers agree with each other  
> and disagree with the spec, and that implementing the behavior browsers  
> agree on would keep the site working, and changing the spec to match  
> reality seems like the sanest approach.

Understood. What I got from those threads at the time though was that we  
were saying to hell with the display: none behavior that's in current  
browsers (especially since I think there were use-cases for hiding an  
active plug-in with display: none (instead of visibility: hidden and  
absolute positioning etc.) while not having the plug-in instance get  
destroyed).

If we want to keep the display: none behavior that's in current browsers,  
I'm not going to object. Just saying that it'd be nice (better/make more  
sense) if the use-case for display: none (deferring instantiation till  
it's shown) was handled by an attribute (instead of css) where removing  
the attribute made it come alive. That should be compatible with older  
browsers for sites already using display: none for deferring instantiation  
and would just be a minor change to the site. But, I realize that any  
change at all might not be welcome.

-- 
Michael