[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