[whatwg] <object> behavior
    Michael A. Puls II 
    shadow2531 at gmail.com
       
    Mon Sep 21 15:26:27 PDT 2009
    
    
  
On Mon, 21 Sep 2009 16:30:29 -0400, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 9/21/09 2:01 PM, Michael A. Puls II wrote:
>> I think Opera even defers
>> the fetching of display: none images until the display is changed.
>
> With those, I believe, it does a synchronous GET when someone asks about  
> things about the image that need the image data, no?
If you mean like asking for img.width, it just shows 0. As in, the <img>  
is dead until you change its display. Safari doesn't do this though.
> I have no problem with a load-on-demand setup as long as it's  
> transparent to content...
>
>> 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.
>
> I think that makes the model very confusing for authors, but maybe  
> that's just me.
Yeh, it doesn't sound ideal. That's for sure.
> How do you envision an audio object inside <head> working with this  
> setup?  Or would it have to go inside <body>, per spec?  What about  
> wanting an object that has no rendering at all but lets you interact  
> with it via script and does something useful for you (say S/MIME stuff  
> for a webmail client)?
Good questions. I envision the object doing whatever I tell to do or not  
to do :). And, being able to tell it what to do or not to do and have it  
listen would be great. See below.
>> 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 would prefer something like this.  Using CSS for this purpose seems  
> wrong.
Sounds good. If it is an attribute, I wonder what would be a good name.  
'disabled' might be likely to conflict with some plug-in param and might  
conflict with <object> and <img> when they are form controls.
-- 
Michael
    
    
More information about the whatwg
mailing list