On Mon, 24 Aug 2009 19:31:30 -0400, Ian Hickson <i...@hixie.ch> wrote:
On Fri, 14 Aug 2009, Michael A. Puls II wrote:
On Thu, 13 Aug 2009 22:05:26 -0400, Ian Hickson <i...@hixie.ch> wrote:
> > - Should <object>s exist all the time whether they are attached to
the
> > document or not?
> Assuming you mean the plugins, as opposed to the elements themselves,
then
> the way the spec is written, the plugin instantiates regardless of
whether
> it is in the document or not.
Are you saying that in the following case (for the Netscape 6.4 WMP
plug-in
(the liveconnect-supported one) for example):
<script>
var obj = document.createElement("object");
obj.setAttribute("type", "application/x-mplayer2");
//document.documentElement.appendChild(obj);
window.onload = function() {
setTimeout(function() {
alert(obj.SetFileName);
//document.documentElement.removeChild(obj);
//alert(obj.SetFileName);
}, 10000);
};
</script>
that .SetFileName() (a function the plug-in supports), will be
accessible even if the object hasn't been attached yet? Are you also
saying that if it is attached and you remove it from the document that
SetFileName will still be callable?
Yes.
If so, that's not what happens in Opera. Pulling the object out of the
document nukes the plug-in instance and an instance isn't created until
you append to the document. Firefox behaves that way with plug-ins too.
And, I think that behavior is required for compat.
If it is required for compat, then we should change the spec. Can you
confirm that this is the case? Generally, having elements act different
out of document is something I'm trying to avoid.
I urge browser devs to comment more on the technical side of this, but:
Here's an example that uses a more modern plug-in that shows what browsers
do.
window.onload = function() {
var obj = document.createElement("object");
obj.type = "application/x-shockwave-flash";
obj.data = "http://adobe.com/shockwave/welcome/flash.swf";;
obj.width = "320";
obj.height = "240";
//document.body.appendChild(obj);
//obj.style.display = "none";
setTimeout(function() {
alert(obj.SetVariable);
}, 1000);
};
In other words, for a plug-in to be initialized (and scriptable if it's
capable):
1. Its element must be attached to the document.
2. Its element must not be set to display of 'none' (and therefore must
not be part of fallback content that's not triggered yet).
As soon as any one of those conditions are not satisfied, the plug-in
instance is destroyed/gone/not accessible.
3. For flash (non-activex-version) at least, in window modes other than
'window' (like 'opaque' and 'transparent'), the plug-in won't *fully*
initialize (as in, it won't paint and start fetching data) until you
scroll the element into view. Firefox, Opera and Safari do this at least,
and it's actually quite nice most of the time that things work that way.
You can see this behavior on songza.com and blip.fm sometimes. You can
also see this on very tall pages with lots of flash player objects
attached.
I believe these things are all necessary for resource management and a
good user experience and are now expected.
Examples:
If you remove a plug-in object from the document, it shouldn't be
lingering around in memory and using other resources, especially if you're
replacing it with another object.
If you initially set an <object> to display: none and plan to flip its
display later to load a plug-in, you wouldn't want the plug-in to
initialize before then.
You also might want to turn a plug-in off by setting an <object> to
display: none.
Imagine a site where you have 2 plugin objects: one for a flash youtube
player and one for a flash audio player from another site. You might only
want to have the instance running that's applicable for the track being
played. Songza.com was an example of a situation where this could be
applicable. They seem to *only* be using the youtube player now now.
If HTML5 says differently, it's really contradicting current browser
behavior. Changing browser behavior to match HTML5 would not match the
expectations of authors and page behavior.
I can't vouch whether vendors are willing to change things in these areas,
but it sounds really risky.
--
Michael
