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 <[email protected]>
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 <[email protected]>
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. [email protected]
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 <[email protected]> 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
[email protected]
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
