[whatwg] <object> behavior

On Sun, 20 Sep 2009 14:49:11 -0400, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 9/18/09 6:35 PM, Michael A. Puls II wrote:
>> With <object style="display: none" data="file.swf?vid=file.flv"> when
>> the page is parsed (or added to the document), what would happen?
>>
>> Would it be something like this?:
>>
>> 1. Create the plug-in instance.
>>
>> 2. fetch file.swf
>>
>> 3. Give the file.swf stream to the plug-in when it requests it.
>>
>> 4. Fetch file.flv when the plug-in requests it
>>
>> 5. If autoplay, start playing the video (audio only since the <object>
>> isn't shown)
>
> #5 is up to the plug-in; the browser doesn't do that part.

Understood.

> What we should do in this case, imo, is instantiate the plug-in, tell it  
> the data we have, tell it it's not being shown (has a null window in  
> NPAPI terms), and let it do whatever it wants with that situation.  I  
> believe Flash, in theory, pauses itself whenever its window is set to  
> null.

O.K.

>> Or, would those optimizations not be triggered at all by display: none,
>> or would it depend on the plug-in or plug-in API or whatever the browser
>> feels like doing?
>
> Depends on the plug-in and plug-in API, yes.

O.K.

>> In other words, if browsers make it so display: none doesn't prevent the
>> loading of a plug-in, does display: none still prevent the automatic
>> streaming of the file in @data by the browser
>
> I'd think no (especially since you have to do the data load to even  
> figure out whether the data is going to be handled by a plug-in to start  
> with; right now given the markup in your example Gecko will do the HTTP  
> GET on file.swf no matter what).
>
>> (for plug-ins, not native types like text/html)?
>
> You don't know which it is until you've gotten at least the HTTP headers  
> of the response (and possibly the first 512 bytes of the body, or  
> whatever the content sniffing mechanism uses).
>
>> The reason I ask is that if existing web pages use multiple <object>'s
>> that load videos for example, that are initially set to display: none
>> and only shown later, then if browsers start fetching all these files as
>> soon as the page loads
>
> They already have to do that, and will continue to, because the HTTP  
> headers from the response are needed to determine how to handle the  
> data.  Right now they might just abort that load as soon as they  
> discover that the data is being handled by a plug-in.  That's what Gecko  
> does.

O.K. All that makes sense. You have to fetch to know what you've got. And,  
in the case of just <object type=""> where there's no data to fetch until  
the plug-in decides what to do with the params it gets, the plug-in could  
do like you said above where it perhaps doesn't do anything or pauses  
while the window is null.

> Note that aborting the load is sometimes a more expensive operation (in  
> terms of affecting the loading of other content) than completing the  
> load, depending on bandwidth, latency, and data size... The higher the  
> latency, the higher the bandwidth, and the smaller the data, the more  
> expensive canceling gets.  Amusingly enough, that means it's more  
> expensive (holding data size constant) on your typical cell phone than  
> on your typical home PC...

Interesting. Thanks very much.

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.

HTML5 could also be extra clear by example that display: none doesn't  
destroy, or prevent the creation of, the plug-in instance and that  
changing the display value doesn't destroy the instance.

Lastly, HTML5 could briefly mention that what the plug-in does when its  
window/area is not displayed because of display: none, is plug-in and  
plug-in API dependent.

Then, anything else can be sorted out elsewhere like in the NPAPI spec  
amongst browser vendors.

Does that sound good? Is everyone else O.K. with this too? I don't think  
HTML5 should just imply the above by being silent about it.

It should briefly make good mention of it, imo. (Not those exact words,  
but something to that effect). (I don't currently see anything in the spec  
that covers this)

Thanks again.

-- 
Michael

Received on Sunday, 20 September 2009 12:54:55 UTC