On Sun, 20 Sep 2009 14:49:11 -0400, Boris Zbarsky <bzbar...@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
