- From: Yehuda Katz <wycats@gmail.com>
- Date: Thu, 24 Sep 2009 11:11:37 -0700
- To: Maciej Stachowiak <mjs@apple.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: <245fb4700909241111y4c9d456ah58bbd8d841db0fce@mail.gmail.com>
Is it really true that WebIDL and the vague way DOM2 was described are the only two options? Surely that's a false dilemma? -- 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 22:18:14 UTC