[whatwg] <object> behavior

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.  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.

> 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.

> 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.  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...

-Boris

Received on Sunday, 20 September 2009 11:49:11 UTC