[whatwg] <object> behavior

Michael A. Puls II shadow2531 at gmail.com
Mon Sep 21 11:01:04 PDT 2009


On Mon, 21 Sep 2009 08:24:37 -0400, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 9/20/09 3:54 PM, Michael A. Puls II wrote:
>> O.K., so put simply, HTML5 should explicitly mention that the css
>> display property for <object>, <embed> (and <applet> in the handling
>> section) has absolutely no effect on plug-in instantiation and
>> destroying and has absolutely no effect on @src and @data resource
>> fetching.
>
> Imo, yes.  Especially given your HTML example, where the behavior  
> difference is easy to stumble on by trying to get the contentDocument of  
> the <object> and work with it.

What about mobile browsers specifically? Using display: none as a defer  
might be a good thing. Maybe that's why webkit and Opera do what they do  
in the first place. It's like load on demand. I think Opera even defers  
the fetching of display: none images until the display is changed.

There is @declare on <object>, but you have to have another <object> point  
to it to get it going. And, @declare isn't really supported.

So, I'm thinking HTML5 should say that display: none specifically (not  
other display values) "SHOULD NOT" affect... instead of "MUST NOT"  
affect... because there might be cases where display: none deferring is  
desired. (As for display: none destroying, I don't know if that's ever  
needed on mobile)

Of course, if the idea is to support deferring for images, <object> and  
<embed> etc. and it's not desired that that support be given through css,  
perhaps there should be some attribute that does that. <img disabled>  
<object disabled> <embed disabled> etc. where .disabled = false brings  
them alive.

I don't know. Whatever everyone thinks is best. Just giving ideas and  
trying to think of all the cases.

-- 
Michael



More information about the whatwg mailing list