W3C home > Mailing lists > Public > public-html@w3.org > April 2008

Re: Reinitializing OBJECT and EMBED - data and type changes

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 23 Apr 2008 15:50:53 -0500
Message-ID: <480FA12D.80000@mit.edu>
To: "Michael A. Puls II" <shadow2531@gmail.com>
CC: public-html@w3.org

Michael A. Puls II wrote:
> Because it might ruin any Attr modification optimizations on OBJECT?

Possibly, and arguably mean that a change that doesn't fire mutation events has 
an effect on what's going on.  Then again, I guess we have that sort of thing 
going on for the "src" attribute of HTMLImageElement, so maybe this isn't a big 
deal.

> What if you have this:
> 
> <object type="application/x-java-applet">
> <param name="code" value"MyJavaClass">
> </object>
> 
> and change the value of the param to MyNewJavaClass

Ideally that would trigger the load on its own, without having to do a "foo.type 
= foo.type" hack.

> What is your opinion on making it so type and data changes don't
> reinitialize and having a reinitialize() function instead?

I would be fine with that from a "how easy is it to implement this?" 
perspective, but it introduces hysteresis effects where the state of the DOM is 
not enough to determine what the state of the object is.  I think those should 
be avoided, personally.

> var obj = document.getElementById("test");
> obj.type = "something";
> obj.parentNode.replaceChild(obj.cloneNode(true), obj);
> 
> , after doing the replacement, 'obj' would no longer point to the
> right object and I would have to manually update 'obj'.  As an
> implementor, is it trivial for you to solve this problem *IF* it was
> necessary to go that route?

I'm not quite sure what you're asking here.

-Boris
Received on Wednesday, 23 April 2008 20:52:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:16 GMT