<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 10, 2010, at 10:54 PM, Garrett Smith wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Mon, May 10, 2010 at 8:28 PM, Perry Smith <<a href="mailto:pedzsan@gmail.com">pedzsan@gmail.com</a>> wrote:<br><font class="Apple-style-span" color="#006312"><snip><br></font><blockquote type="cite">So, how about this?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">As part of HTMLElement, have a defined bucket, maybe call it elementObject which is defined to be a native ECMAScript object. If X denotes a particular DOM element, then X.elementObject is defined to return the same native ECMAScript object each time. More details could be added perhaps to define how the object is created (i.e. which prototype to use, etc). I'm thinking making it the same as {}.<br></blockquote><blockquote type="cite"><br></blockquote><br>WebIDL could require DOM objects to be implemented as native ECMAScript objects.<br></div></blockquote></div><br><div>To me, the "host objects" and the fact that they are mostly unspecified seems rather critical and limiting. The getUserData seems terribly awkward and I guess it suffers from portability issues as well.</div><div><br></div><div>Is WebIDL the best place to address this?</div><div><br></div><div>Thanks,</div><div>pedz</div><div><br></div></body></html>