I agree with Jonas that something on the Windows object would be the best way to go. Boris suggested a set of key/value string pairs. Would it be an associative array?
http://www.w3.org/TR/Window/#window-embedding - for window.name, I note that it says "Need to describe how this could come from a containing element." and window.frameElement is a big TODO. Would window.name in the <object> case be the id of the object? That's one quick way to pass a parameter (or a concatenated series of parameters) then (uh, once it's implemented, of course - guess I should check that out). Still hoping there's a hack out there ;) Regards, Jeff On 3/13/08, Jonas Sicking <[EMAIL PROTECTED]> wrote: > Jeff Schiller wrote: > > I'm not well-versed on the history behind document.domain and how "the > > web depends on it being writable". Can someone send me a pointer? > > > > I can understand not letting the embedded object get at the elements > > outside of the HTMLObjectElement, but this seems like a weird design > > flaw - the object parameters should be accessible to the embedded > > object, regardless of domain - that's their purpose. It would have > > been great if HTMLObjectElement had an accessible "params" NodeList > > readonly attribute :( > > > That wouldn't really help. While you can get access to the <object> > element using window.frameElement, you don't have access to do anything > at all with it. Even if we added properties directly on > HTMLObjectElement you would not be granted access to them. > > The proper fix here is IMHO to add something to the window object. So > that you don't have to reach out into documents that are from a > different domain. > > I would not rely on document.domain tricks. IMO document.domain is a > hack and a much better solution to the problem it's trying to solve is > postMessage. > > > / Jonas >
