[whatwg] <object> behavior

[Michael A. Puls II]

On Mon, 24 Aug 2009 19:31:30 -0400, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 14 Aug 2009, Michael A. Puls II wrote:
>> On Thu, 13 Aug 2009 22:05:26 -0400, Ian Hickson <ian at 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