- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 23 Apr 2008 15:50:53 -0500
- 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 UTC