- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 24 Sep 2009 11:17:30 -0700
- To: Yehuda Katz <wycats@gmail.com>
- Cc: Brendan Eich <brendan@mozilla.com>, public-webapps@w3.org, HTML WG <public-html@w3.org>, es-discuss <es-discuss@mozilla.org>
- Message-id: <34FE1E9B-6127-453A-8483-F06E3186E71A@apple.com>
On Sep 24, 2009, at 11:11 AM, Yehuda Katz wrote: > Is it really true that WebIDL and the vague way DOM2 was described > are the only two options? Surely that's a false dilemma? I'm not saying those are the only two options. I'm explaining how WebIDL solves a problem. Are there other ways to solve the problem? Probably. Do you have a specific proposal? Regards, Maciej > > -- Yehuda > > On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak <mjs@apple.com> > wrote: > > On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote: > >> Maybe this would be a good opportunity to revisit the utility of >> WebIDL in specifications (as formal specifications were re-examined >> for ES-Harmony). The WebIDL spec is pretty large, and I personally >> have found its use a confounding factor in understanding other >> specs (like HTML5). > > Its utility is in providing a way to specify API behavior in a way > that is consistent between specifications, language-independent, and > reasonably concise. It's true that it adds an additional thing you > have to learn. That's regrettable, but there are a lot of details > that need to be specified to get interoperability. Pre-WebIDL specs > such as DOM Level 2[1] left many details undefined, leading to > problematic behavior differences among browsers and a need for > mutual reverse-engineering. > > Regards, > Maciej > > [1] http://www.w3.org/TR/DOM-Level-2-Core/ > > >> >> -- Yehuda >> >> On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich <brendan@mozilla.com> >> wrote: >> On Sep 24, 2009, at 7:55 AM, Maciej Stachowiak wrote: >> >> It seems like this is a Web IDL issue. I don't see any reason for >> Web IDL to move to ECMA. It is a nominally language-independent >> formalism that's being picked up by many W3C specs, and which >> happens to have ECMAScript as one of the target languages. Much of >> it is defined by Web compatibility constraints which would be >> outside the core expertise of TC39. >> >> Some of us on TC39 have lots of Web compatibility experience :-P. >> >> >> >> Probably the best thing to do is to provide detailed technical >> review of Web IDL via the W3C process. >> >> Expertise on both sides of the artificial standards body divide may >> very well be needed. The rest of this message convinces me it is >> needed. >> >> One problem with inviting review via the W3C process is getting >> attention and following too many firehose-like mailing lists. es-discuss@mozilla.org >> is at most a garden hose, which is an advantage. >> >> Another problem is that not all Ecma TC39 members are W3C members >> (their employers are not members, that is). >> >> There are transparency problems on both sides, IMHO. People in dark- >> glass houses... >> >> >> >> https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html >> and the rest of that thread >> >> https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html >> (not the transactional behavior, which is out -- just the >> interaction with Array's custom [[Put]]). >> >> https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html >> on an "ArrayLike interface" with references to DOM docs at the >> bottom >> >> https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html >> about a WebIDL float terminal value issue. >> >> It seems like these are largely Web IDL issues (to the extent I can >> identify issues in the threads at all). >> >> TC39 members, Mark Miller articulated this yesterday, hope to >> restrict host objects in future versions of the JavaScript standard >> from doing any nutty thing they like, possibly by collaborating >> with WebIDL standardizers so that instead of "anything goes" for >> host objects, we have "only what WebIDL can express". >> >> Catch-all magic where host object interfaces handle arbitrary >> property gets and puts are currently not implementable in ES -- >> this may be possible in a future edition, but even then it will >> carry performance penalties and introduce analysis hazards. We hope >> to steer ES bindings for WebIDL-expressed interfaces away from >> catch-all patterns. >> >> Beyond this tarpit, we're interested in the best way to linearize >> multiply-inherited WebIDL interfaces onto prototype chains, or >> whether to use prototype chains at all -- or in the seemingly >> unlikely event ES grows first-class method-suite mixins, binding >> WebIDL inheritance to those. We would welcome use-cases and >> collobaration, at least I would. Who knows what better system might >> result? >> >> >> >> There are larger (and less precise concerns at this time) about >> execution scope (e.g., presumptions of locking behavior, >> particularly by HTML5 features such as local storage). The two >> groups need to work together to convert these concerns into >> actionable suggestions for improvement. >> >> There was extensive recent email discussion of local storage >> locking on the <whatwg@whatwg.org> mailing list. We could continue >> here if it would be helpful. I'm not sure it's useful to discuss in >> person without being up to speed on the email discussion. Here are >> some relevant threads: <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html >> > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html >> > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html >> > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html >> >. >> >> Thanks for the links, I was aware of these but hadn't read them. >> >> Mandatory try-locks in JS, just say no. >> >> >> >> I'm not sure what the other concerns about "execution scope" are - >> seems hard to discuss fruitfully without more detail. >> >> The term I used was "execution model". "scope" is a mis- >> transcription. >> >> >> >> We should take steps to address the following "willful violation": >> >> If the script's global object is a Window object, then in JavaScript, >> the this keyword in the global scope must return the Window object's >> WindowProxy object. >> >> This is a willful violation of the JavaScript specification current >> at >> the time of writing (ECMAScript edition 3). The JavaScript >> specification requires that the this keyword in the global scope >> return the global object, but this is not compatible with the >> security >> design prevalent in implementations as specified herein. [ECMA262] >> >> Wasn't ES5 fixed to address this? >> >> No, nothing was changed in ES5 and it is not clear without more >> discussion with various experts active in whatwg, w3, and Ecma what >> to do. >> >> Since you asked, I think you make the case that we should >> collaborate a bit more closely. >> >> >> >> I know the feedback was passed along. >> >> Yes, but describing the problem does not give the solution. >> >> /be >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> -- >> Yehuda Katz >> Developer | Engine Yard >> (ph) 718.877.1325 > > > > > -- > Yehuda Katz > Developer | Engine Yard > (ph) 718.877.1325
Received on Thursday, 24 September 2009 18:23:44 UTC