Array Like Interface

[Allen Wirfs-Brock]

(forwarding for Travis since his direct post bounced)

From: Travis Leithead
Sent: Monday, May 18, 2009 10:28 AM
To: brendan at mozilla.com; Allen Wirfs-Brock; cam at mcc.id.au
Cc: es-discuss; Garrett Smith; Chris Wilson
Subject: Re: Array Like Interface


(Adding Cameron, the WebIDL editor)



>> Anyone working on IE care to comment here, or in a w3c public list? If the latter, a folllowup giving a link to the thread here would be appreciated.



Regarding whether we'd have a different take on the matter: we recognize that first and foremost, web developers want and need consistency in their experiences in cross-browser coding. It makes a lot of sense to implement DOM APIs, etc., as native objects because that gives web developers the best seamless JavaScript->DOM experience. Deviations, as Garrett has pointed out in a previous message, lead to the perception of a bug in the implementation.



IE does not implement the DOM as native JS objects, but as host objects. Therefore we depend heavily on specifications like WebIDL to help formalize what the mappings look like from COM to JavaScript. I don't know (or can't yet disclose ;) what the future will hold as far as our binding is concerned, but our ultimate goal is interoperability in this space, and this area has been a trouble-spot for interoperability in the past. I believe that WebIDL will go a long way toward reducing web dev pain as it is properly implemented.



WebIDL provides a logical and predictable JavaScript binding for the DOM. In my opinion, there are only a few places where it needs a bit more clarity:

*        The List bindings (called sequence<T> in the spec, of which the author acknowledges that this needs some work (http://dev.w3.org/2006/webapi/WebIDL/#es-sequence). If implementations are allowed to start converting various NodeLists or NamedNodeMaps, etc. to Arrays, then what does a [[Put]] mean? Where would it go? Because many of the lists in the DOM are "live", a [[Put]] would be strange. It doesn't seem natural to use a linear model and automatically map it back to a tree model, because there's just not enough context to do that in the linear model. Of course, given the proper restrictions, I suppose a mapping could be worked out. I don't know how many of the Array-generics would make sense for various DOM collections. My instinct tells me that one-size does not fit all.

*        New ES5 concepts.

o   Now that ES5 is moving closer to standardization, WebIDL needs to consider the new ES5 concepts and how they should be mapped to DOM standards. For example, are there certain DOM objects that need to be considered "sealed" or "frozen"?

o   How should object properties be represented; as data or accessor properties, or as a combination of both? IE8 took the route of consistency and made every property of the DOM an accessor property (which was natural, since the COM binding is a set of get/set pairs anyway), however, I'm not sure if this is needed as the default for many simple properties like element.id for instance.





-----Original Message-----

From: Brendan Eich [mailto:brendan at mozilla.com]

Sent: Friday, May 15, 2009 12:17 PM

To: Allen Wirfs-Brock

Cc: Garrett Smith; es-discuss

Subject: Re: Array Like Interface



On May 15, 2009, at 10:34 AM, Allen Wirfs-Brock wrote:



> Note that the host object exceptions in the Es5 spec. permits, but do

> not require that hosts take liberties with the ES specified object

> semantics. In particular, there is no reason that a browser cannot

> implement DOM objects as "native objects" rather than "host objects".



This is what Gecko has done forever, likewise KHTML -> WebKit, AFAIK.



The only "host objects" in Mozilla code have been some LiveConnect (Java <-> JS bridge) ones, but those are being replaced by "native objects" too.





> Nor, from an ES specification perspective, there is no particular

> reason that the ES binding of WebIDL should permit use of host object

> semantics (which pretty means unspecified) rather than native object

> semantics. However, those responsible for maintaining and

> incrementally evolving existing implementations probably would have a

> different take on this matter.







Anyone working on IE care to comment here, or in a w3c public list? If the latter, a folllowup giving a link to the thread here would be appreciated.



/be





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090518/e80c5fb8/attachment-0001.html>