ECMA TC 39 / W3C HTML and WebApps WG coordination
On Thu, 24 Sep 2009 14:36:56 +0200, Sam Ruby <rubys at intertwingly.net>
wrote:
The current WebIDL binding to ECMAScript is based on ES3... this needs
to more closely track to the evolution of ES, in particular it needs to
be updated to ES5 w.r.t the Meta Object Protocol.
Is there a more detailed comment on this available somewhere?
In the process, we should discuss whether this work continues in the
W3C, is done as a joint effort with ECMA, or moves to ECMA entirely.
What is the reason for moving it away from W3C? I'd much rather have it
there since most consumers are there too. (Another reason would be that
the W3C has a more open process.)
On Sep 24, 2009, at 15:11 , Anne van Kesteren wrote:
In the process, we should discuss whether this work continues in
the W3C, is done as a joint effort with ECMA, or moves to ECMA
entirely.What is the reason for moving it away from W3C? I'd much rather have
it there since most consumers are there too. (Another reason would
be that the W3C has a more open process.)
+1, though joint participation from TC 39 would be really good.
Sam Ruby wrote:
A concern specific to HTML5 uses WebIDL in a way that precludes implementation of these objects in ECMAScript (i.e., they can only be implemented as host objects), and an explicit goal of ECMA TC39 has been to reduce such. Ideally ECMA TC39 and the W3C HTML WG would jointly develop guidance on developing web APIs, and the W3C HTML WG would apply that guidance in HTML5.
Meanwhile, I would encourage members of ECMA TC 39 who are aware of specific issues to open bug reports:
And I would encourage members of the HTML WG who are interested in this topic to read up on the following emails (suggested by Brendan Eich):
mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html and the rest of that thread
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]]).
esdiscuss/2009-May/009300 on an "ArrayLike interface" with references to DOM docs at the bottom
mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html about a WebIDL float terminal value issue.
Would it be possible to summarise the known issues in an email (or on a wiki page or something)? I read those threads and it was unclear to me which specific points are considered outstanding problems with the HTML5/WebIDL specs.
On Sep 24, 2009, at 5:36 AM, Sam Ruby wrote:
At the upcoming TPAC, there is an opportunity for F2F coordination
between these two groups, and the time slot between 10 O'Clock and
Noon on Friday has been suggested for this.
It would be nice if the coordination time slot wasn't at a time that
the HTML WG is meeting, and perhaps was on a day the Web Apps WG is
meeting or the plenary day. I say this because:
A) It would be poor form for Sam and myself to miss one of the HTML WG
sessions, but I suspect both of us will be interested in the Web
Apps / ECMA TC 39 joint session. Or at least I am, having a great
interest in Web IDL.
B) Some Web Apps WG members may be attending TPAC only for the days
Web Apps is meeting WG.
Thus, a time slot on Monday, Tuesday or Wednesday of TPAC would be
better.
, Maciej
On Sep 24, 2009, at 5:36 AM, Sam Ruby wrote:
At the upcoming TPAC, there is an opportunity for F2F coordination
between these two groups, and the time slot between 10 O'Clock and
Noon on Friday has been suggested for this.To help prime the pump, here are four topics suggested by ECMA TC39
for discussion. On these and other topics, there is no need to wait
for the TPAC, discussion can begin now on the es-discuss mailing list.
The current WebIDL binding to ECMAScript is based on ES3... this
needs to more closely track to the evolution of ES, in particular it
needs to be updated to ES5 w.r.t the Meta Object Protocol. In the
process, we should discuss whether this work continues in the W3C,
is done as a joint effort with ECMA, or moves to ECMA entirely.
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. Probably the best thing to do is to provide
detailed technical review of Web IDL via the W3C process.
A concern specific to HTML5 uses WebIDL in a way that precludes
implementation of these objects in ECMAScript (i.e., they can only
be implemented as host objects), and an explicit goal of ECMA TC39
has been to reduce such. Ideally ECMA TC39 and the W3C HTML WG
would jointly develop guidance on developing web APIs, and the W3C
HTML WG would apply that guidance in HTML5.Meanwhile, I would encourage members of ECMA TC 39 who are aware of
specific issues to open bug reports:And I would encourage members of the HTML WG who are interested in
this topic to read up on the following emails (suggested by Brendan
Eich):mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html and the rest of that thread
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]]).
esdiscuss/2009-May/009300 on an "ArrayLike interface" with references to DOM docs at the
bottommail.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).
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 at 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: <lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html
<lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html <lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html <lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html .
I'm not sure what the other concerns about "execution scope" are -
seems hard to discuss fruitfully without more detail.
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? I know the feedback was passed along.
, Maciej
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 at 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...
mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html and the rest of that thread
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]]).
esdiscuss/2009-May/009300 on an "ArrayLike interface" with references to DOM docs at the
bottommail.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 at 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: <lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html<lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html <lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html <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.
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).
On Sep 24, 2009, at 9:47 AM, Brendan Eich 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 at 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).
The converse of all these problems would arise if the spec became an
ECMA spec. Indeed, possibly worse, because ECMA has no formally
defined process for external review of a specification (though ECMA
subgroups could define their own process presumably).
There are transparency problems on both sides, IMHO. People in dark- glass houses...
mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html and the rest of that thread
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]]).
esdiscuss/2009-May/009300 on an "ArrayLike interface" with references to DOM docs at the
bottommail.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.
We could recommend avoiding catch-alls as a best practice. However,
many legacy DOM interfaces require catch-all behavior, so it can't be
completely eliminated. If we want to restrict host objects to what
WebIDL allows, but not break the Web, then catch-all getters and
putters have to be among the things it allows.
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?
Yes, linearization of multiply-inherited interfaces (and multiple
interfaces that are present but not inherited) is something that could
use careful review and a better design. When I said "these are largely
Web IDL issues" I mean "not directly issues for the HTML Working
Group". I did not mean to imply that TC 39 shouldn't have input - it
should.
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 at 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: <lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html<lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html <lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html <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 didn't like most of the proposed designs either.
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.
Are there specific issues other than the concurrency model for storage
APIs?
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.
Sounds like a good issue to discuss then.
I know the feedback was passed along.
Yes, but describing the problem does not give the solution.
If ES5 has requirements on this that match ES3, then it has a
requirement that Firefox, Safari and Chrome (and I think Opera?) are
all violating, and likely will continue to violate for the foreseeable
future. That seems like a problem. (Unless we convince ourselves that
the split global object pattern somehow doesn't actually violate the
ECMAScript spec.)
, Maciej
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.
, Maciej
Is it really true that WebIDL and the vague way DOM2 was described are the only two options? Surely that's a false dilemma?
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?
, Maciej
On Sep 24, 2009, at 10:48 AM, Maciej Stachowiak wrote:
On Sep 24, 2009, at 9:47 AM, Brendan Eich wrote:
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 at 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).The converse of all these problems would arise if the spec became an
ECMA spec.
I'm not advocating that, personally -- I'm explicitly encouraging some
kind of collaboration across an artificial divide.
This may be difficult for many reasons, but where the spec ends up is
less important to me (and if you make me choose either-or, I prefer
w3's RF to Ecma's RAND on first principles) than that we have good
collaboration without requiring every TC39 member to join w3c (if
possible).
Do we have to agree on where the spec ends up before collaborating? I
hope not, especially since it seems likely both ES specs and W3C ones
may need to contain sub-specs that hook together, possibly involving
common pieces duplicated among the specs.
Indeed, possibly worse, because ECMA has no formally defined process
for external review of a specification (though ECMA subgroups could
define their own process presumably).
We've had external review of ES5 drafts, and ES4 and ES3.1 materials
before them, for years. This list hears all about the many updates to
. We also publish meeting notes freely (we used to publish the formal
minutes but doing so, IIRC, did run afoul of Ecma's rules -- but the
notes are much more complete and useful IMO).
We could recommend avoiding catch-alls as a best practice. However,
many legacy DOM interfaces require catch-all behavior, so it can't
be completely eliminated. If we want to restrict host objects to
what WebIDL allows, but not break the Web, then catch-all getters
and putters have to be among the things it allows.
The problem is containing the old patterns, heading off the temptation
to use them in new APIs.
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?Yes, linearization of multiply-inherited interfaces (and multiple
interfaces that are present but not inherited) is something that
could use careful review and a better design. When I said "these are
largely Web IDL issues" I mean "not directly issues for the HTML
Working Group". I did not mean to imply that TC 39 shouldn't have
input - it should.
There's probably a better future beyond prototype chains, and I think
the odds of finding that world and colonizing it are greater if we
collaborate somehow. The current situation is making the best of de-
facto standards, rationalizing what's out there.
Possibly TC39 members need to do the main work on mixins, and then
propose something coherent for WebIDL to bind to. But I know of folks
not active in TC39 or not even Ecma mebmers, who are able to
participate in the public HTML5 lists (and of course in whatwg.org),
who do want mixins a la Ruby modules in JS, and their input would help
us make some kind of progress.
But this separation of "producers" and "consumers" is artificial, and
it may miss critical information not expressed in mythical waterfall
requirements docs one might imagine the parties exchange. Systems R&D
benefits from mixing up the experts and opening the silos to cross
disciplines, interest areas, programming audiences, and less
defensible boundaries to-do with standards body politics.
The current division of labor between "core language" (Ecma) and DOM/
WebAPI/WebIDL (W3C) has its advantages, don't get me wrong. But
obviously some things have fallen through the cracks (multiple
globals, split windows, execution rules).
The term I used was "execution model". "scope" is a mis- transcription.
Are there specific issues other than the concurrency model for
storage APIs?
There are AFAIK interop issues to-do with modal dialogs and events in
major browsers, but I haven't retested lately. Possibly HTML5 has this
all nailed down and browser bug fixes are all that's left to do.
Beyond this, concurrency via workers is great for certain use-cases
but not enough for others.
In TC39 we are talking about formalizing the run-to-completion
execution model of JS, along with asynchronous message passing
concurrency. In particular, we're looking at Promises (precedent from
E) and Futures (differently, in MultiLisp and Alice-ML). At least one
contributor on es-discuss has advocated lower-level components such as
dataflow variables.
It's too early to predict what we'll do but I hear strong consensus in
favor of asynchronous messaging and shared-nothing, with higher-level
abstractions such as Promises favored over lower-level concurrent
programming features such as dataflow variables.
This is for the same reasons given on es-discuss over the last three
years against adding sharp low-level tools such as call/cc, instead
supporting higher-level (very) delimited continuations (Pythonic
generators as in JS1.7).
If ES5 has requirements on this that match ES3, then it has a
requirement that Firefox, Safari and Chrome (and I think Opera?) are
all violating, and likely will continue to violate for the
foreseeable future. That seems like a problem. (Unless we convince
ourselves that the split global object pattern somehow doesn't
actually violate the ECMAScript spec.)
It's a violation, for sure, but no one will be struck down by
lightning. We can live with it a bit longer.
Much of the hoped-for multiple global objects spec that is notoriously
missing from ES1-5 did not appear as an informative document (an Ecma
TR), but it still needs to be done, and it looks like Hixie et al.
have done some of it. A future ES spec would need to say more to work
with the HTML5 spec, and we might want the core language to say a lot
more, not just the minimum necessary to interoperate with the other
spec.
WindowProxy and Window go a step beyond multiple globals, of course,
splitting each global in two (or one proxy and one or more globals
under navigation with cached history).
Do we need a WindowProxy in the core language? I'm not sure, but if
not then there has to be some other way of specifying how |this| in
global code binds to the outer window rather than the inner (Ecma
global). We didn't try to make something up here for ES5.
On Sep 24, 2009, at 11:25 AM, Brendan Eich wrote:
On Sep 24, 2009, at 10:48 AM, Maciej Stachowiak wrote:
On Sep 24, 2009, at 9:47 AM, Brendan Eich wrote:
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 at 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).The converse of all these problems would arise if the spec became
an ECMA spec.I'm not advocating that, personally -- I'm explicitly encouraging
some kind of collaboration across an artificial divide.This may be difficult for many reasons, but where the spec ends up
is less important to me (and if you make me choose either-or, I
prefer w3's RF to Ecma's RAND on first principles) than that we have
good collaboration without requiring every TC39 member to join w3c
(if possible).
Any TC39 members whose employers can't join could perhaps become
Invited Experts to the W3C Web Applications Working Group, if that
facilitates review.
Do we have to agree on where the spec ends up before collaborating?
I hope not, especially since it seems likely both ES specs and W3C
ones may need to contain sub-specs that hook together, possibly
involving common pieces duplicated among the specs.
We already have a spec in progress and it already has a home, so
starting the conversation with a suggestion to move the work elsewhere
struck me as odd and potentially disruptive.
We could recommend avoiding catch-alls as a best practice. However,
many legacy DOM interfaces require catch-all behavior, so it can't
be completely eliminated. If we want to restrict host objects to
what WebIDL allows, but not break the Web, then catch-all getters
and putters have to be among the things it allows.The problem is containing the old patterns, heading off the
temptation to use them in new APIs.
That would probably best be done via a recommendation not to use
catchalls in new APIs (in the Web IDL spec perhaps).
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?Yes, linearization of multiply-inherited interfaces (and multiple
interfaces that are present but not inherited) is something that
could use careful review and a better design. When I said "these
are largely Web IDL issues" I mean "not directly issues for the
HTML Working Group". I did not mean to imply that TC 39 shouldn't
have input - it should.There's probably a better future beyond prototype chains, and I
think the odds of finding that world and colonizing it are greater
if we collaborate somehow. The current situation is making the best
of de-facto standards, rationalizing what's out there.
Indeed, because the variance in what's out there makes life more
difficult for authors. I expect it's not possible to get rid of
prototypes from ECMAScript DOM bindings given the constraints of Web
compatibility.
Possibly TC39 members need to do the main work on mixins, and then
propose something coherent for WebIDL to bind to. But I know of
folks not active in TC39 or not even Ecma mebmers, who are able to
participate in the public HTML5 lists (and of course in whatwg.org),
who do want mixins a la Ruby modules in JS, and their input would
help us make some kind of progress.But this separation of "producers" and "consumers" is artificial,
and it may miss critical information not expressed in mythical
waterfall requirements docs one might imagine the parties exchange.
Systems R&D benefits from mixing up the experts and opening the
silos to cross disciplines, interest areas, programming audiences,
and less defensible boundaries to-do with standards body politics.The current division of labor between "core language" (Ecma) and DOM/ WebAPI/WebIDL (W3C) has its advantages, don't get me wrong. But
obviously some things have fallen through the cracks (multiple
globals, split windows, execution rules).
I think we are in agreement that collaboration would enable a better
outcome here. All I meant to do is to point out the proper W3C Working
Group for coordination.
The term I used was "execution model". "scope" is a mis- transcription.
Are there specific issues other than the concurrency model for
storage APIs?There are AFAIK interop issues to-do with modal dialogs and events
in major browsers, but I haven't retested lately. Possibly HTML5 has
this all nailed down and browser bug fixes are all that's left to do.Beyond this, concurrency via workers is great for certain use-cases
but not enough for others.In TC39 we are talking about formalizing the run-to-completion
execution model of JS, along with asynchronous message passing
concurrency. In particular, we're looking at Promises (precedent
from E) and Futures (differently, in MultiLisp and Alice-ML). At
least one contributor on es-discuss has advocated lower-level
components such as dataflow variables.It's too early to predict what we'll do but I hear strong consensus
in favor of asynchronous messaging and shared-nothing, with higher- level abstractions such as Promises favored over lower-level
concurrent programming features such as dataflow variables.This is for the same reasons given on es-discuss over the last three
years against adding sharp low-level tools such as call/cc, instead
supporting higher-level (very) delimited continuations (Pythonic
generators as in JS1.7).
Workers are technically a Web Apps WG spec and not part of HTML5
proper any more. They provide an asynchronous messaging shared-nothing
model, while preventing access to most browser-specific APIs in
anything but the main thread. It would be nice to study whether in-
language concurrency features could work together with the Workers
model rather than being completely separate.
If ES5 has requirements on this that match ES3, then it has a
requirement that Firefox, Safari and Chrome (and I think Opera?)
are all violating, and likely will continue to violate for the
foreseeable future. That seems like a problem. (Unless we convince
ourselves that the split global object pattern somehow doesn't
actually violate the ECMAScript spec.)It's a violation, for sure, but no one will be struck down by
lightning. We can live with it a bit longer.
Well, it seems bad to me for the spec to state a requirement that
won't be followed.
Much of the hoped-for multiple global objects spec that is
notoriously missing from ES1-5 did not appear as an informative
document (an Ecma TR), but it still needs to be done, and it looks
like Hixie et al. have done some of it. A future ES spec would need
to say more to work with the HTML5 spec, and we might want the core
language to say a lot more, not just the minimum necessary to
interoperate with the other spec.
Specifying more about multiple global objects would be good, but I
think it's not a case where current browser behavior violates the
ECMAScript spec, so it's not really the same issue.
WindowProxy and Window go a step beyond multiple globals, of course,
splitting each global in two (or one proxy and one or more globals
under navigation with cached history).Do we need a WindowProxy in the core language? I'm not sure, but if
not then there has to be some other way of specifying how |this| in
global code binds to the outer window rather than the inner (Ecma
global). We didn't try to make something up here for ES5.
ECMAScript could just allow host embeddings to make the outermost
scope chain entry be something other than the global object. The main
downside is that this is more loose than is needed and could
technically allow crazy unreasonable things. But it may not be
possible to fully specify the behavior at the ECMAScript level, since
it depends on the notion of navigation. There may be a way to provide
a more narrowly tailored hook.
, Maciej
I'll think about it. I was mostly hoping to start a discussion about alternatives. I think the bottom line here is that while the spec is well-optimized for implementors, it is not very well optimized for consumers. I suppose it would be possible to say that this stuff is only for implementors. I'd prefer if it were also readable for those trying to use the specification.
On Sep 24, 2009, at 12:00 PM, Yehuda Katz wrote:
I'll think about it. I was mostly hoping to start a discussion about
alternatives. I think the bottom line here is that while the spec is
well-optimized for implementors, it is not very well optimized for
consumers. I suppose it would be possible to say that this stuff is
only for implementors. I'd prefer if it were also readable for
those trying to use the specification.
My inclination would be to address this by improving the current Web
IDL spec, or to write an informative "primer" style document to
accompany it. I also think some of the complexity of the Web IDL spec
can probably be removed without losing anything important - I think it
offers some constructs that are not used by any spec relying on it.
On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:
This may be difficult for many reasons, but where the spec ends up
is less important to me (and if you make me choose either-or, I
prefer w3's RF to Ecma's RAND on first principles) than that we
have good collaboration without requiring every TC39 member to join
w3c (if possible).Any TC39 members whose employers can't join could perhaps become
Invited Experts to the W3C Web Applications Working Group, if that
facilitates review.
Are invited experts time-bound in some way? We learned in Ecma that
experts were to be invited to one meeting only.
Do we have to agree on where the spec ends up before collaborating?
I hope not, especially since it seems likely both ES specs and W3C
ones may need to contain sub-specs that hook together, possibly
involving common pieces duplicated among the specs.We already have a spec in progress and it already has a home, so
starting the conversation with a suggestion to move the work
elsewhere struck me as odd and potentially disruptive.
I've been writing my own opinion, qualified that way. Other TC39
members should opine. I really don't want to grab a spec from w3c,
even if there is some concern about expertise being split awkwardly.
I'm interested in fixing the split, not where the spec or specs end up.
ISO and Ecma will insist on some degree of self-contained status for
the ES specs. We refer to Unicode and IEEE-754 but for foundational
things like the global object(s) and the execution model.
There's probably a better future beyond prototype chains, and I
think the odds of finding that world and colonizing it are greater
if we collaborate somehow. The current situation is making the best
of de-facto standards, rationalizing what's out there.Indeed, because the variance in what's out there makes life more
difficult for authors. I expect it's not possible to get rid of
prototypes from ECMAScript DOM bindings given the constraints of Web
compatibility.
Yes, the foreseeable future wants backward compatibility. But we might
find a better binding for new APIs, and possibly recast old ones
(minus old stuff that is not actually used much) in new, more usable
clothing.
If ES5 has requirements on this that match ES3, then it has a
requirement that Firefox, Safari and Chrome (and I think Opera?)
are all violating, and likely will continue to violate for the
foreseeable future. That seems like a problem. (Unless we convince
ourselves that the split global object pattern somehow doesn't
actually violate the ECMAScript spec.)It's a violation, for sure, but no one will be struck down by
lightning. We can live with it a bit longer.Well, it seems bad to me for the spec to state a requirement that
won't be followed.
Yes, it's bad. Now what?
Specifying more about multiple global objects would be good, but I
think it's not a case where current browser behavior violates the
ECMAScript spec, so it's not really the same issue.
Multiple globals as in frame or window objects, probably not. Although
IE does some very strange dynamic scoping in its window.eval
implementation, or did -- see
resources:jscriptdeviationsfromes3.pdf
This is not going to be standardized, so it's an IE bug to fix (if not
fixed already).
There are edge cases to do with split windows and whether you get
exceptions or !== true results, but these are the real multiple global
objects issue I had in mind. Even ignoring multiple frames or windows,
just a single WindowProxy with more than one Window global object is
outside the ES specs, which do not admit more than one global object.
WindowProxy and Window go a step beyond multiple globals, of
course, splitting each global in two (or one proxy and one or more
globals under navigation with cached history).Do we need a WindowProxy in the core language? I'm not sure, but if
not then there has to be some other way of specifying how |this| in
global code binds to the outer window rather than the inner (Ecma
global). We didn't try to make something up here for ES5.ECMAScript could just allow host embeddings to make the outermost
scope chain entry be something other than the global object.
That's backward: the outermost scope chain object must be the ES
global object, what HTML5 types in WebIDL as a Window.
It's the WindowProxy for that Window (and others forward and back in
session history) that must be bound to |this| in global code, contrary
to ES.
The main downside is that this is more loose than is needed and
could technically allow crazy unreasonable things.
This is not tenable -- the WindowProxy is shared among multiple
globals and possibly cross-origin scripts loaded in multiple globals.
Those globals not current but rather "back" and "forward" in the same
WindowProxy's history must be frozen in an informal sense -- not the
ES5 sense -- but other frames or windows can access certain
WindowProxy properties cross-origin.
But it may not be possible to fully specify the behavior at the
ECMAScript level, since it depends on the notion of navigation.
There may be a way to provide a more narrowly tailored hook.
Narrow tailoring could be good, we may not need navigation or even
multiple globals (either in history or among currently navigated
frames and windows).
Hixie's tests:
damowmow.com/playground/demos/global-object/001.html, damowmow.com/playground/demos/global-object/002.html, damowmow.com/playground/demos/global-object/005.html
002 and 005 behave differently among current browsers.
Can there exist a narrow tailoring that does not include some notion
of navigation, therefore multiple global (Window) objects, and (for |
this| binding) a global proxy (WindowProxy)? Would so narrow a
tailoring be useful and stand alone in ES well?
On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:
Any TC39 members whose employers can't join could perhaps become Invited Experts to the W3C Web Applications Working Group, if that facilitates review.
Unfortunately, no. See #2 and #3 below:
www.w3.org/2004/08/invexp.html
On Thu, Sep 24, 2009 at 5:02 PM, Brendan Eich <brendan at mozilla.com> wrote:
Are invited experts time-bound in some way? We learned in Ecma that experts were to be invited to one meeting only.
In general, no. There is a time limit mentioned in #4 above, but that is just for exceptional circumstances, ones that are not likely to apply in this situation.
- Sam Ruby
On Sep 24, 2009, at 2:16 PM, Sam Ruby wrote:
On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:
Any TC39 members whose employers can't join could perhaps become
Invited Experts to the W3C Web Applications Working Group, if that
facilitates review.Unfortunately, no. See #2 and #3 below:
It depends on the nature of the employer, and the reason they are
unable to join. Historically there have been Invited Experts in W3C
Working Groups who are employed by such organizations as universities
or small start-ups. We even have some in the HTML Working Group. So it
would probably be more accurate to say "it depends" and that it may be
subject to the judgment of the W3C Team.
, Maciej
Maciej Stachowiak wrote:
On Sep 24, 2009, at 2:16 PM, Sam Ruby wrote:
On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:
Any TC39 members whose employers can't join could perhaps become Invited Experts to the W3C Web Applications Working Group, if that facilitates review.
Unfortunately, no. See #2 and #3 below:
It depends on the nature of the employer, and the reason they are unable to join. Historically there have been Invited Experts in W3C Working Groups who are employed by such organizations as universities or small start-ups. We even have some in the HTML Working Group. So it would probably be more accurate to say "it depends" and that it may be subject to the judgment of the W3C Team.
I've discussed the specific case with the W3C, and it is the case that in the judgment of the W3C Team, the answer in this specific case is no.
You, of course, are welcome to try again in the hopes of getting a different answer.
, Maciej
- Sam Ruby
On Sep 24, 2009, at 2:37 PM, Sam Ruby wrote:
Maciej Stachowiak wrote:
On Sep 24, 2009, at 2:16 PM, Sam Ruby wrote:
On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:
Any TC39 members whose employers can't join could perhaps become
Invited Experts to the W3C Web Applications Working Group, if that
facilitates review.Unfortunately, no. See #2 and #3 below:
www.w3.org/2004/08/invexp.html It depends on the nature of the employer, and the reason they are
unable to join. Historically there have been Invited Experts in W3C
Working Groups who are employed by such organizations as
universities or small start-ups. We even have some in the HTML
Working Group. So it would probably be more accurate to say "it
depends" and that it may be subject to the judgment of the W3C Team.I've discussed the specific case with the W3C, and it is the case
that in the judgment of the W3C Team, the answer in this specific
case is no.You, of course, are welcome to try again in the hopes of getting a
different answer.
I didn't know that there was a specific case driving this concern. I
thought this was a general worry about, e.g., university researchers.
I would not ask the W3C Team to reconsider specific cases where they
have already rendered a judgment.
, Maciej
Sam Ruby:
At the upcoming TPAC, there is an opportunity for F2F coordination
between these two groups, and the time slot between 10 O'Clock and
Noon on Friday has been suggested for this.
I'm travelling at the moment, so apologies for the delay in replying.
Unfortunately I won't be attending TPAC, but I am sure some useful
discussions will come out of the meeting between those TC 39, Web Apps
and HTML WG people who can attend.
I will be in Mountain View from Saturday for 11 days (for SVG stuff),
so I could probably find some time to meet with interested people if
that's deemed to be a good idea.
Some general responses to questions raised in this thread:
• I agree that a better solution for the multiple inheritance
problem is needed.
• Web IDL is somewhat poorly written at the moment, so it would
indeed be good to make it easier to follow. I do think the spec is
aimed at implementors rather than authors, though.
I look forward to increased collaboration with the ECMA folks on the
spec!
That sounds reasonable. There are really two issues. One is that there are parts of WebIDL that are unused. Another is that the parts of the spec themselves are fairly arcane and very implementor-specific. Consider: interface UndoManager { readonly attribute unsigned long length; getter any item(in unsigned long index); readonly attribute unsigned long position; unsigned long add(in any data, in DOMString title); void remove(in unsigned long index); void clearUndo(); void clearRedo(); };
I almost forget that I'm looking at something most widely implemented in a dynamic language when I look at that. Since this is most likely to be implemented in terms of ECMAScript, why not provide an ECMAScript reference implementation?
On Sep 24, 2009, at 5:44 PM, Yehuda Katz wrote:
That sounds reasonable. There are really two issues. One is that
there are parts of WebIDL that are unused. Another is that the parts
of the spec themselves are fairly arcane and very implementor- specific. Consider:interface UndoManager { readonly attribute unsigned long length; getter any item(in unsigned long index); readonly attribute unsigned long position; unsigned long add(in any data, in DOMString title); void remove(in unsigned long index); void clearUndo(); void clearRedo(); };
I almost forget that I'm looking at something most widely
implemented in a dynamic language when I look at that. Since this is
most likely to be implemented in terms of ECMAScript, why not
provide an ECMAScript reference implementation?
These methods do things that can't actually be implemented in pure
ECMAScript, since they need to tie into the browser implementation and
system APIs. So a reference implementation in ECMAScript is not
possible.
What this interface definition actually specifies is some constraints
on how the implementation of this object is reflected to ECMAScript.
For example, this method must convert its second parameter to a string
using a particular algorithm, and the prose description of the
method's behavior assumes that has been done, and the return value
promises to be a positive integer:
unsigned long add(in any data, in DOMString title);
This method converts its one parameter to a number, and performs
truncation and range checks according to some standard rules, and will
for example raise an exception if a negative number is provided:
void remove(in unsigned long index);
It would be tedious to spell out all those details for every such
method, either in prose or in ECMAScript code - that interface
definition would be replaced by something 5-10 times as long.
Another thing to keep in mind - although ECMAScript is the primary
target language for the IDL interfaces in Web technology
specifications, it is quite common to expose these interfaces in Java,
and is desirable for various applications to be able to provide them
in languages such as Python, C++, Objective-C, and Ruby. Thus, we need
a language-independent formalism to define the interfaces, even though
the ECMAScript bindings are the most important.
And finally, even though the snippet of Web IDL you cited is very much
aimed at authors, I think it's pretty easy to understand the practical
upshot for ECMAScript programmers, without understanding the details
of Web IDL. It's pretty clear what attributes and methods you can use,
and what kind of parameters you should provide. For those who care
about the full details, you only have to learn Web IDL once, and it's
not a very big syntax. It's sort of like learning EBNF to understand
grammar definitions. The extra conciseness is worth the cost of an
extra formal syntax to learn, in my opinion.
, Maciej
Maciej Stachowiak wrote:
On Sep 24, 2009, at 5:44 PM, Yehuda Katz wrote:
That sounds reasonable. There are really two issues. One is that there are parts of WebIDL that are unused. Another is that the parts of the spec themselves are fairly arcane and very implementor-specific. Consider:
interface UndoManager { readonly attribute unsigned long length; getter any item(in unsigned long index); readonly attribute unsigned long position; unsigned long add(in any data, in DOMString title); void remove(in unsigned long index); void clearUndo(); void clearRedo(); };
I almost forget that I'm looking at something most widely implemented in a dynamic language when I look at that. Since this is most likely to be implemented in terms of ECMAScript, why not provide an ECMAScript reference implementation?
These methods do things that can't actually be implemented in pure ECMAScript, since they need to tie into the browser implementation and system APIs. So a reference implementation in ECMAScript is not possible.
I'll accept that it is a true statement that in an pure ECMAScript implementation of these interfaces in Safari on Mac OSX such wouldn't be possible.
Alternate perspective, one that I believe more closely matches the view of TC39: one could image an operating system and browser implemented in either in ECMAScript or in a secure subset thereof. In such an environment it would be highly unfortunate if the the WebIDL for something as important as HTML5 and WebApps were written in such a way as to preclude the creation of a conforming ECMAScript implementation.
At this point, I'm not personally interested in discussions as to whether WebIDL is or is not the right way forward. Anybody who wishes to invest their time in producing more useful documentation and/or reference implementations is not only welcome to do so, they are positively encouraged to do so.
Meanwhile, what we need is concrete bug reports of specific instances where the existing WebIDL description of key interfaces is done in a way that precludes a pure ECMAScript implementation of the function.
- Sam Ruby
On Fri, 25 Sep 2009 11:38:08 +0200, Sam Ruby <rubys at intertwingly.net>
wrote:
Meanwhile, what we need is concrete bug reports of specific instances
where the existing WebIDL description of key interfaces is done in a way
that precludes a pure ECMAScript implementation of the function.
Is there even agreement that is a goal?
I personally think the catch-all pattern which Brendan mentioned is quite
convenient and I do not think it would make sense to suddenly stop using
it. Also, the idea of removing the feature from Web IDL so that future
specifications cannot use it is something I disagree with since having it
in Web IDL simplifies writing specifications for the (legacy) platform and
removes room for error.
Having Web IDL is a huge help since it clarifies how a bunch of things map
to ECMAScript. E.g. how the XMLHttpRequest constructor object is exposed,
how you can prototype XMLHttpRequest, that objects implementing
XMLHttpRequest also have all the members from EventTarget, etc. I'm fine
with fiddling with the details, but rewriting everything from scratch
seems like a non-starter. Especially when there is not even a proposal on
the table.
On Fri, Sep 25, 2009 at 5:57 AM, Anne van Kesteren <annevk at opera.com> wrote:
On Fri, 25 Sep 2009 11:38:08 +0200, Sam Ruby <rubys at intertwingly.net> wrote:
Meanwhile, what we need is concrete bug reports of specific instances where the existing WebIDL description of key interfaces is done in a way that precludes a pure ECMAScript implementation of the function.
Is there even agreement that is a goal?
This was expressed by ECMA TC39 as a goal. There is no agreement as of yet to this goal by the HTML WG.
I'm simply suggesting that they way forward at this time is via specifics, ideally in the form of bug reports.
I personally think the catch-all pattern which Brendan mentioned is quite convenient and I do not think it would make sense to suddenly stop using it. Also, the idea of removing the feature from Web IDL so that future specifications cannot use it is something I disagree with since having it in Web IDL simplifies writing specifications for the (legacy) platform and removes room for error.
Having Web IDL is a huge help since it clarifies how a bunch of things map to ECMAScript. E.g. how the XMLHttpRequest constructor object is exposed, how you can prototype XMLHttpRequest, that objects implementing XMLHttpRequest also have all the members from EventTarget, etc. I'm fine with fiddling with the details, but rewriting everything from scratch seems like a non-starter. Especially when there is not even a proposal on the table.
I agree that either getting a proposal on the table or bug reports is the right next step. I further agree that removal of function and/or a wholesale switch away from Web IDL is likely to be a non-starter.
Anne van Kesteren annevankesteren.nl
- Sam Ruby
On Sep 25, 2009, at 2:38 AM, Sam Ruby wrote:
Maciej Stachowiak wrote:
On Sep 24, 2009, at 5:44 PM, Yehuda Katz wrote:
That sounds reasonable. There are really two issues. One is that
there are parts of WebIDL that are unused. Another is that the
parts of the spec themselves are fairly arcane and very
implementor-specific. Consider:interface UndoManager { readonly attribute unsigned long length; getter any item(in unsigned long index); readonly attribute unsigned long position; unsigned long add(in any data, in DOMString title); void remove(in unsigned long index); void clearUndo(); void clearRedo(); };
I almost forget that I'm looking at something most widely
implemented in a dynamic language when I look at that. Since this
is most likely to be implemented in terms of ECMAScript, why not
provide an ECMAScript reference implementation? These methods do things that can't actually be implemented in pure
ECMAScript, since they need to tie into the browser implementation
and system APIs. So a reference implementation in ECMAScript is not
possible.I'll accept that it is a true statement that in an pure ECMAScript
implementation of these interfaces in Safari on Mac OSX such
wouldn't be possible.Alternate perspective, one that I believe more closely matches the
view of TC39: one could image an operating system and browser
implemented in either in ECMAScript or in a secure subset thereof.
In such an environment it would be highly unfortunate if the the
WebIDL for something as important as HTML5 and WebApps were written
in such a way as to preclude the creation of a conforming ECMAScript
implementation.
Unfortunately, this is the case. But in many cases this is due to
legacy compatibility requirements combined with certain features that
do not (yet) exist in ECMAScript. See below.
At this point, I'm not personally interested in discussions as to
whether WebIDL is or is not the right way forward. Anybody who
wishes to invest their time in producing more useful documentation
and/or reference implementations is not only welcome to do so, they
are positively encouraged to do so.Meanwhile, what we need is concrete bug reports of specific
instances where the existing WebIDL description of key interfaces is
done in a way that precludes a pure ECMAScript implementation of the
function.
I think the main cases where this is true are interfaces with catchall
getters and setters, or interfaces that are callable (but also have
various methods and properties and are not Functions). I believe most
of these are due to legacy compatibility constraints. Thus, ECMAScript
will need to change to be able to plausibly implement equivalent
interfaces. A change to Web IDL to match current ECMAScript
capabilities would mean it can't actually describe the APIs that exist
in browsers today, and such a description of these APIs would be,
essentially, false. This seems like putting the cart before the horse.
Let me give a concrete example, the HTMLCollection interface from
HTML5: dev.w3.org/html5/spec/Overview.html#htmlcollection-0.
This interface is defined to have "getter" properties which imply
catchall getters for index and non-index properties. This is
implemented by all existing browsers and is needed for compatibility
with a lot of Web content. It is also required by DOM Level 2 HTML's
ECMAScript bindings: <www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html
. The fact that ECMAScript 5 can't implement an interface that
behaves like this is an ECMAScript issue, not an HTML issue, in my
opinion, and one that will hopefully be fixed in future editions.
Now, it may be that some non-legacy APIs require special host object
behavior that wouldn't otherwise be implicated by legacy APIs. If
anyone identifies such APIs, then we can look at fixing them.
, Maciej
On Thu, Sep 24, 2009 at 7:55 AM, Maciej Stachowiak <mjs at apple.com> wrote:
On Sep 24, 2009, at 5:36 AM, Sam Ruby wrote:
The current WebIDL binding to ECMAScript is based on ES3... this needs to more closely track to the evolution of ES, in particular it needs to be updated to ES5 w.r.t the Meta Object Protocol. In the process, we should discuss whether this work continues in the W3C, is done as a joint effort with ECMA, or moves to ECMA entirely.
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. Probably the best thing to do is to provide detailed technical review of Web IDL via the W3C process.
To clarify, AFAIK, no one on the EcmaScript committee is proposing that WebIDL itself be moved to ECMA, but rather the WebIDL->EcmaScript
language binding.
To answer a concern brought up later in the thread, neither is anyone of the EcmaScript committee proposing that anything be removed from WebIDL, or that the definition of these binding change in ways that create incompatibilities with current pre-HTML5 browser APIs. Whatever problems are created by legacy uses of WebIDL, we all accept that we have to live with these problems for the foreseeable future (essentially forever). Rather, the concern is that new APIs defined using WebIDL should not magnify these problems.
These are two separate points. The second point constitutes only advice from ECMA to W3C, and demonstrates a need for dialog. The EcmaScript committee has been evolving EcmaScript with one of our goals being to close the gap between what DOM objects can do and what EcmaScript objects can emulate. While we were busy trying to close the gap, html5 was busy widening it. This is largely our fault by not having communicated this goal. We seek dialog repair this mistake and to avoid repeating it.
The first point may be more contentious, but I think is also clearer. Say Joe creates JoeLang and creates a browser plugin or something that gives JoeLang access to the DOM. Joe should not expect W3C to define the WebIDL->JoeLang binding. As you say, WebIDL is a nominally
language-independent formalism. As such, it should serve precisely as the abstraction mechanism needed to allow work on host environment APIs like browsers to proceed loosely coupled to the design on the languages that run in such host environments.
Catchalls are an excellent example issue for both points, in opposite directions. Regarding the second point, yes, we believe that new host APIs should generally seek to avoid requiring catchalls, since new native (i.e., written in EcmaScript) APIs must, and since there are many benefits to being able to emulate more host APIs more easily in EcmaScript (such as the ability to interpose intermediary wrappers). Regarding the first point, since legacy host APIs do require catchalls, EcmaScript must eventually too. The definition of how WebIDL-expressed catchalls map to future EcmaScript should co-evolve with the changes to EcmaScript needed to support this mapping.
On Fri, 25 Sep 2009 16:26:21 +0200, Mark S. Miller <erights at google.com>
wrote:
To clarify, AFAIK, no one on the EcmaScript committee is proposing that WebIDL itself be moved to ECMA, but rather the WebIDL->EcmaScript language binding.
That is the most essential part of Web IDL for most consumers though.
Maybe one should hope for the best, but I think the WebApps WG is a much
better place in terms of transparency and I do not see any reason why the
ECMAScript committee cannot simply provide public feedback just like
everyone else. Even if a person cannot be on the WG for whatever reason he
is still allowed to join the mailing list and participate in discussion.
I think it is better in terms of transparency because all the decisions
are made on a public list, the draft is in version control (and written in
HTML), and it is very easy for people to participate by just emailing
public-webapps at w3.org or chatting with the editor on IRC.
(Admittedly I also have my reservations on how certain decisions regarding
ECMAScript have been made running contrary to deployed implementations.
E.g. with to the de facto getters and setters standard. I think
something like that would be much less likely to happen at the W3C though
in the end of course it depends on who is involved.)
To answer a concern brought up later in the thread, neither is anyone of the EcmaScript committee proposing that anything be removed from WebIDL, or that the definition of these binding change in ways that create incompatibilities with current pre-HTML5 browser APIs. Whatever problems are created by legacy uses of WebIDL, we all accept that we have to live with these problems for the foreseeable future (essentially forever). Rather, the concern is that new APIs defined using WebIDL should not magnify these problems.
I'm not sure I agree they are problems, though it might help if some
explicit examples were given.
These are two separate points. The second point constitutes only advice from ECMA to W3C, and demonstrates a need for dialog. The EcmaScript committee has been evolving EcmaScript with one of our goals being to close the gap between what DOM objects can do and what EcmaScript objects can emulate. While we were busy trying to close the gap, html5 was busy widening it. This is largely our fault by not having communicated this goal. We seek dialog repair this mistake and to avoid repeating it.
Where exactly was the gap widened?
The first point may be more contentious, but I think is also clearer. Say Joe creates JoeLang and creates a browser plugin or something that gives JoeLang access to the DOM. Joe should not expect W3C to define the WebIDL->JoeLang binding. As you say, WebIDL is a nominally language-independent formalism. As such, it should serve precisely as the abstraction mechanism needed to allow work on host environment APIs like browsers to proceed loosely coupled to the design on the languages that run in such host environments.
While N languages might not be possible doing it for the 2 we care about
does make sense I think. The specific language details also influence the
design of Web IDL. And especially in case of ECMAScript makes reviewing
the draft much easier because you can easily check if it matches what
contemporary implementations do.
On Sep 25, 2009, at 16:26 , Mark S. Miller wrote:
To clarify, AFAIK, no one on the EcmaScript committee is proposing that WebIDL itself be moved to ECMA, but rather the WebIDL->EcmaScript language binding.
I understand the rationale you have to motivate this proposal, I do
have a level of sympathy for it, and I certainly believe that we
should do as much as possible to pool our expertise across what I
agree is an artificial divide. Yet such a move would seem to me to
have more drawbacks than advantages.
One is that defining WebIDL at the same time as the ES binding has the
huge advantage of keeping it on mission. I would be concerned that
removing the ES bindings would potentially open the door to some level
of feature creep, or would risk opening cracks in WebIDL's intended
adherence to reality.
Another one is the virtuous feedback loop that I believe would work
better if the two are kept close-by. New features in ES5 should be
reflected perhaps not only in the binding, but in the core of what
WebIDL can do.
Additionally there is co-ordination with all the other WGs that have a
stake in this. HTML, WebApps, SVG, DAP, and many others need not only
to track WebIDL because it is the formalism but also the ES binding
because we all need a concrete binding, because ES is usually the only
one that really matters (it certainly is core to our shared vision of
the Web) and the one that we use in building test suites. That would
be quite a hassle for a fair number of people.
That being said I fully understand that it is conversely true for TC39
participants, and therefore I'd like to find a solution that keeps the
work in one place while making everyone happy (or at least, not overly
disgruntled).
WebIDL is defined almost entirely in email discussion, there haven't
been calls or meetings about it in a long while, and I don't see any
in the close future. WebApps will likely touch on it during the F2F
but that would be short (it might in fact be non-existent given that
it will be discussed jointly with TC39 anyway). So unless there is
consensus in TC39 that email discussion is not good enough to move
this forward, I believe that all we need is a list. That's why I liked
Doug's idea of a public-idl at w3.org mailing list for this very purpose.
It would be low traffic, people who only care about WebIDL would only
get that, discussion would be publicly archived, and everyone would be
welcome. We can easily complement that with an IRC channel, and
perhaps other supporting services.
I don't care a rat's arse where that list is hosted, and I suspect
others here feel the same — so long as we don't split the work, and
that all interested parties can help. I like W3C mailing list and
their archiving system because they are more sanely configured than
most, but I can live with anything else. If ECMA wishes to create the
same list I'll happily join, or we can host it elsewhere still.
Would that not work for TC39? If not, can you detail the reasons why
so that we can try to figure out a solution?
I guess that we could go the legalese way and start investigating the
idea of a MoU between W3C and ECMA on this, but that would take time
and probably be rather heavy — with little obvious technological
advantage. I'd rather not go there.
Three distinct topics are being mixed up here:
-
Whether to use WebIDL or some unproposed alternative.
-
Whether to use catchall patterns in new WebIDL-defined interfaces.
-
Whether the JS WebIDL bindings should be standardized by Ecma or W3C.
The straw man (0. Whether to remove catchall patterns from existing
WebIDL interfaces required for backward compatibility) is nonsense and
I'm going to ignore it from here on.
My positions are:
-
WebIDL, the bird in the hand (I agree with Sam: go invent something
better, come back when you're done). -
Don't keep perpetuating catchall patterns, they are confusing for
developers and costly for implementors and static analysis tools, even
if implementable in some future ES edition. -
Don't care.
I differ from Mark on 3, but that's ok. What is not ok is to waste a
lot of time arguing from divergent premises that need to be unpacked
or else let alone for now, when we could be collaborating on concrete
issues such as split windows, execution model, catchall policing, etc.
Mark's Joe with his JoeLang bindings for WebIDL vs. Anne's point about
the primacy of JavaScript bindings for WebIDL-defined interfaces is
not going to lead to rapid agreement on putting the ES WebIDL bindings
in Ecma vs. leaving them in W3C. It's a rathole, IMHO.
Both points of view have merit, but precedent and possession matter
too, and Ecma can't plausibly fork or steal the binding spec. We're
trying to collaborate, so let's get on with that hard work instead of
trying to assail one another with principles that can't encompass the
whole picture.
Hope this helps,
+1
On Sep 25, 2009, at 12:08 PM, Jonas Sicking wrote:
On Fri, Sep 25, 2009 at 9:56 AM, Brendan Eich <brendan at mozilla.com>
wrote:My positions are:
WebIDL, the bird in the hand (I agree with Sam: go invent
something better, come back when you're done).Don't keep perpetuating catchall patterns, they are confusing for developers and costly for implementors and static analysis tools,
even if implementable in some future ES edition.Don't care.
Regarding 2. How do you feel about index accessors? I.e. for example
you can do:myNode.children[5]
which returns the same as
myNode.children.item(5)
This seems equally impossible to implement in ECMAScript, but is something that I think is helpful to authors so not something that I want to stop adding to new interfaces.
Good point. I have mixed feelings, to be honest. See the ArrayLike
thread on es-discuss:
and followups. The one from Travis Leithead of Microsoft at:
links to dev.w3.org/2006/webapi/WebIDL/#es-sequence, which has
words about an "Array host object":
dev.w3.org/2006/webapi/WebIDL/#dfn-array-host-object
This is new and different from the legacy collection/nodelist stuff,
which we can't change. Is it the new-model solution for index
accessors, or are you still wanting to make live "tree cursors" with
indexed getter and setter catchalls?
The live tree cursors always seemed like a mixed bag at best. Folks
want to use Array generic methods on them, and sometimes find the
liveness a problem. I've not heard anyone saying the liveness was a
crucial win.
I will stop the over-citing madness here and now :-P.
The struggle to formalize ArrayLike, which seems like a common goal
for ES the core language and for WebIDL's ES bindings, makes me want
to give an exception to the "catchalls considered harmful for new
interfaces" injunction. I agree that indexing into array-likes, with
no liveness magic, seems containable and desirable. ES folks haven't
nailed down ArrayLike yet (our fault) and we would benefit from
collaboration with WebIDL folks here.
So if you are doing more ArrayLike interfaces, let's keep talking.
Don't let at least my catchalls-considered-harmful statements stop
progress on ArrayLikes.
I expect some ES folks may demur now :-).
Brendan Eich:
The struggle to formalize ArrayLike, which seems like a common goal for ES the core language and for WebIDL's ES bindings, makes me want to give an exception to the "catchalls considered harmful for new interfaces" injunction. I agree that indexing into array-likes, with no liveness magic, seems containable and desirable. ES folks haven't nailed down ArrayLike yet (our fault) and we would benefit from collaboration with WebIDL folks here.
So currently in Web IDL there are three ways to get objects with properties that have non-negative integer names: sequences, arrays and regular interfaces with index getters. The definitions for sequence<T>
and T[] types in Web IDL are relatively recent, but they are probably more in line with the kinds of thing you’re looking for with ArrayLike (without having re-read that thread yet).
The main difference between sequences and arrays is that sequence types are effectively pass-by-value and use native Array objects, while array types are host objects that act similarly to native Arrays, but with appropriate IDL ↔ ECMAScript type conversions. IDL arrays have the native Array prototype object in their prototype chain. A given IDL array an be designated as read only, so that assigning to length or array index properties has no effect.
There are no ES implementations of IDL sequences or arrays yet as far as I know.
The third way, defining a regular interface with an index getter (and maybe a setter) is currently used. It’s implemented with special [[Get]] (and [[Put]]) behaviour, which I guess is what you would like to avoid. However it’s not just a simple catchall – such objects are defined to gain and lose properties with the appropriate index names as appropriate for the interface. This is done pretty much just so that ‘in’ and hasOwnProperty return true for array index properties, which is needed for HTMLCollection and the like.
(Cross-posting to these three lists makes me feel funny, although I recognise that these issues involve all three groups.)
Do we need a WindowProxy in the core language? I'm not sure, but if
not then there has to be some other way of specifying how |this| in
global code binds to the outer window rather than the inner (Ecma
global). We didn't try to make something up here for ES5.ECMAScript could just allow host embeddings to make the outermost
scope chain entry be something other than the global object. The main
downside is that this is more loose than is needed and could
technically allow crazy unreasonable things. But it may not be
possible to fully specify the behavior at the ECMAScript level, since
it depends on the notion of navigation. There may be a way to provide
a more narrowly tailored hook., Maciej
ECMA-262 allows (in 15.1) the prototype of the global object to be anything (including a host object with catchall semantics, or with properties existing for all names, just with value undefined, custom [[Put]] and [[Get]], etc.). Would implementing WindowProxy on that object and Window on the global object solve the use cases? Is there actually a comprehensive list of use cases for this splitting anywhere, to facilitate checking any potential solutions against them?
Best ,
Krzysztof HTML WG
Brendan Eich wrote:
I will stop the over-citing madness here and now :-P.
The struggle to formalize ArrayLike, which seems like a common goal for ES the core language and for WebIDL's ES bindings, makes me want to give an exception to the "catchalls considered harmful for new interfaces" injunction. I agree that indexing into array-likes, with no liveness magic, seems containable and desirable. ES folks haven't nailed down ArrayLike yet (our fault) and we would benefit from collaboration with WebIDL folks here.
So if you are doing more ArrayLike interfaces, let's keep talking. Don't let at least my catchalls-considered-harmful statements stop progress on ArrayLikes.
I expect some ES folks may demur now :-).
I am on the record for strongly opposing catch-alls. It's unproductive to repeat the reasons because that would sidetrack the discussion and the reasons mentioned by Brendan are sufficient to make the idea deeply flawed. We've gone around that rathole many times in the past.
However, I have no particular objections to making additional kinds of array-like objects. This does not suffer from the same problems that catchalls in general do.
WaldemarOn Sep 25, 2009, at 7:26 AM, Mark S. Miller wrote:
To clarify, AFAIK, no one on the EcmaScript committee is proposing that WebIDL itself be moved to ECMA, but rather the WebIDL->EcmaScript language binding.
The design of Web IDL itself is highly informed by the ECMAScript
language binding - in fact, many Web IDL constructs exist solely for
modeling ECMAScript APIs. So I don't think this split is useful
To answer a concern brought up later in the thread, neither is anyone of the EcmaScript committee proposing that anything be removed from WebIDL, or that the definition of these binding change in ways that create incompatibilities with current pre-HTML5 browser APIs. Whatever problems are created by legacy uses of WebIDL, we all accept that we have to live with these problems for the foreseeable future (essentially forever). Rather, the concern is that new APIs defined using WebIDL should not magnify these problems.
These are two separate points. The second point constitutes only advice from ECMA to W3C, and demonstrates a need for dialog. The EcmaScript committee has been evolving EcmaScript with one of our goals being to close the gap between what DOM objects can do and what EcmaScript objects can emulate. While we were busy trying to close the gap, html5 was busy widening it. This is largely our fault by not having communicated this goal. We seek dialog repair this mistake and to avoid repeating it.
I think there are two possible perspectives on what constitutes
"magnify[ing] tthe problem" or "widening the gap"
A) Any new kind of requirement for implementations of object
interfaces that can't be implemented in pure ECMAScript expands the
scope of the problem.
B) Any new interface that isn't implementable in ECMAScript widens the
gap, even if it is for a reason that also applies to legacy
My view is A. That's why I pointed to legacy interfaces - if the
construct can't go away from APIs in general, but we wish to implement
all APIs in ECMAScript, then ultimately it is ECMAScript that must
change, so using the same construct again doesn't create a new
problem. Avoiding it in new APIs would provide a small amount of
temporary relief for the brave person who seeks to implement the whole
Web platform in pure ECMAScript, but in the long run would make no
difference to the feasibility of the overall goal.
Now, there may be pragmatic reasons for avoiding catchall getters and
setters:
- Difficulty of efficient implementation (this is less true for index- only catchall getters).
- Potential confusingness to authors (probably also less true for
index access). - Namespace collisions between the magical attributes and the
object's built-in attributes and methods - this makes it harder to
specify and explain the interface and creates hazards for use (does
not apply to the index access pattern afaict).
I think these are reasonable arguments (though I wouldn't rule out a
priori that there may be situations where the API convenience of
catchalls outweighs these concerns).
But I think these are totally separate from the "implementability in
pure ECMAScript" concern. And in particular, I think index access to
array-like objects is a good pattern that we should not stop using in
APIs just because it's not implementable in pure ECMAScript today.
Past interfaces use this pattern, and future interfaces should clearly
use it once ECMAScript supports it. A temporary moratorium on using it
would not be a wise tradeoff.
, Maciej
On Sep 25, 2009, at 1:18 PM, Brendan Eich wrote:
I will stop the over-citing madness here and now :-P.
The struggle to formalize ArrayLike, which seems like a common goal
for ES the core language and for WebIDL's ES bindings, makes me want
to give an exception to the "catchalls considered harmful for new
interfaces" injunction. I agree that indexing into array-likes, with
no liveness magic, seems containable and desirable. ES folks haven't
nailed down ArrayLike yet (our fault) and we would benefit from
collaboration with WebIDL folks here.So if you are doing more ArrayLike interfaces, let's keep talking.
Don't let at least my catchalls-considered-harmful statements stop
progress on ArrayLikes.
Perhaps when catchalls are considered for ECMAScript, there could b a
way to encapsulate the specific pattern of index access, so you can
have magical getters and setters for all index properties (integer
numbers in range to be an array index) without having to install a
full catchall for all properties.
, Maciej
On Sep 25, 2009, at 3:34 PM, Krzysztof Maczyński wrote:
Do we need a WindowProxy in the core language? I'm not sure, but if not then there has to be some other way of specifying how |this| in global code binds to the outer window rather than the inner (Ecma global). We didn't try to make something up here for ES5.
ECMAScript could just allow host embeddings to make the outermost scope chain entry be something other than the global object. The main downside is that this is more loose than is needed and could technically allow crazy unreasonable things. But it may not be possible to fully specify the behavior at the ECMAScript level, since it depends on the notion of navigation. There may be a way to provide a more narrowly tailored hook.
, Maciej ECMA-262 allows (in 15.1) the prototype of the global object to be
anything (including a host object with catchall semantics, or with
properties existing for all names, just with value undefined, custom
[[Put]] and [[Get]], etc.). Would implementing WindowProxy on that
object and Window on the global object solve the use cases? Is there actually a comprehensive list of use cases for this
splitting anywhere, to facilitate checking any potential solutions
against them?
ECMAScript requires the outermost scope chain entry and the object
that is used as "this" for global function calls to be the same
object. But the scope chain entry cannot be directly observed, so the
only observable difference is in property access behavior. Nothing
requires this to be stable and consistent for a host object.
But ECMAScript doesn't have a way to distinguish normal property
access from property access via lexical scoping. It's unclear whether
you could say an object is actually "the same" but happens to give
different answers for scope chain access and direct property access,
and possibly even different answers depending on which scope chain it
was found in. I would think that strains host object exemptions to the
breaking point.
, Maciej
On Sep 25, 2009, at 4:57 PM, Maciej Stachowiak wrote:
On Sep 25, 2009, at 1:18 PM, Brendan Eich wrote:
So if you are doing more ArrayLike interfaces, let's keep talking.
Don't let at least my catchalls-considered-harmful statements stop
progress on ArrayLikes.Perhaps when catchalls are considered for ECMAScript, there could b
a way to encapsulate the specific pattern of index access, so you
can have magical getters and setters for all index properties
(integer numbers in range to be an array index) without having to
install a full catchall for all properties.
Good point -- implementing array-likes via catchalls has been on our
minds since the ES4 "meta" days [1], although we never split hooks
based on property name being non-negative (possibly also <= 2^32 - 1
-- or is it <= 2^32 - 2?!).
With WebIDL folks' help we will probably take down ArrayLike first,
without going whole-hog for catchalls. The "catchalls climb the meta
ladder" problem is more profound than the index/length magic (even the
awful uint32 domain) of array-likes. I agree with Waldemar, we should
make progress on array-likes without getting hung up on catchalls.
/be
-----Original Message----- From: es-discuss-bounces at mozilla.org [mailto:es-discuss- ... But ECMAScript doesn't have a way to distinguish normal property access from property access via lexical scoping.
In the ES5 specification it does. Reference that that resolve to property accesses are explicitly distinguished from those that resolve to environment records. This includes object environments such as the global environment and with environments.
It's unclear whether you could say an object is actually "the same" but happens to give different answers for scope chain access and direct property access, and possibly even different answers depending on which scope chain it was found in. I would think that strains host object exemptions to the breaking point.
Accesses to the global object are mediated through a object environment record, but the actual access to the global object's properties take place using "internal methods" [[Get]], [[Put]], [[DefineOwnProperty]], etc. regardless of whether the access was initiated via a direct property reference or via an environment record. However, because neither ES3 or ES5 (except for a only a couple new requirements) really define or require specific semantics for host object internal methods virtually anything goes. Even behavior that differs depending upon the "calling context" of the internal method. (although "internal methods" aren't real and aren't actually called).
When ECMAScript says "host object" it is really saying "arbitrary implementation dependent magic could happen here.
Maciej Stachowiak wrote:
Perhaps when catchalls are considered for ECMAScript, there could b a way to encapsulate the specific pattern of index access, so you can have magical getters and setters for all index properties (integer numbers in range to be an array index) without having to install a full catchall for all properties.
That's what ES4 did. The a[b] operator could be overridden by an object, as could for-in iteration. Hence you could implement array-like things (multidimensional in the case of ES4 because it also understood a[b,c,d]) without doing catch-alls.
This seems like an attractive avenue, especially since we now have some ES5 methods that reliably access underlying properties.
WaldemarOn Fri, Sep 25, 2009 at 4:54 PM, Maciej Stachowiak <mjs at apple.com> wrote:
On Sep 25, 2009, at 7:26 AM, Mark S. Miller wrote: I think there are two possible perspectives on what constitutes "magnify[ing] tthe problem" or "widening the gap"
A) Any new kind of requirement for implementations of object interfaces that can't be implemented in pure ECMAScript expands the scope of the problem. B) Any new interface that isn't implementable in ECMAScript widens the gap, even if it is for a reason that also applies to legacy
My view is A. That's why I pointed to legacy interfaces - if the construct can't go away from APIs in general, but we wish to implement all APIs in ECMAScript, then ultimately it is ECMAScript that must change, so using the same construct again doesn't create a new problem. Avoiding it in new APIs would provide a small amount of temporary relief for the brave person who seeks to implement the whole Web platform in pure ECMAScript, but in the long run would make no difference to the feasibility of the overall goal.
A good distinction. I agree that the #A problem is worse. I also do not know of cases of #A.
Regarding #B, I also think these are best avoided. Various existing systems that try to emulate DOM object behavior using JavaScript code may fail to emulate some of these, creating leaky abstractions that their users live with. Each additional case adds another headache. However, your split below of Array-like vs catchalls is nice, and your enumeration of the reasons to avoid APIs that need general catchalls is great.
Now, there may be pragmatic reasons for avoiding catchall getters and setters:
- Difficulty of efficient implementation (this is less true for index-only catchall getters).
- Potential confusingness to authors (probably also less true for index access).
- Namespace collisions between the magical attributes and the object's built-in attributes and methods - this makes it harder to specify and explain the interface and creates hazards for use (does not apply to the index access pattern afaict).
Yes. As an obvious example of #3, what happens when a Storage dev.w3.org/html5/webstorage key is "toString"?
I note that WebIDL already distinguishes between requiring catchalls for any property name, as in getItem(), vs requiring only index access, as in key() below.
interface Storage { readonly attribute unsigned long length; getter any key(in unsigned long index); getter any getItem(in DOMString key); setter creator void setItem(in DOMString key, in any data); deleter void removeItem(in DOMString key); void clear(); };
I think these are reasonable arguments (though I wouldn't rule out a priori that there may be situations where the API convenience of catchalls outweighs these concerns).
Of course nothing should be ruled out a priori. But your issue #3 is quite serious. Do you know of any cases where the API convenience justifies creating yet another such namespace confusion? IMO, Storage does not and the getter/setter/deleter annotations on it, being a non-legacy API, should be removed from all but key(). The inconvenience of tracking down the resulting bugs outweigh the convenience of saving a few characters in source.
OTOH, if our resolution of the need for array-like generic indexes is to allow overloading of [], then perhaps the resolution for new APIs is to annotate them somehow, to distinguish them from the legacy-namespace-confused-APIs-we-can't-fix, so that, for example,
storage['toString'] is equivalent to storage.getItem('toString'),
and neither is considered a property access (other than access to the getItem property). storage.toString accesses storage's toString property, and is not affected by the alternate getter annotation we'd use instead of the above.
But I think these are totally separate from the "implementability in pure ECMAScript" concern. And in particular, I think index access to array-like objects is a good pattern that we should not stop using in APIs just because it's not implementable in pure ECMAScript today. Past interfaces use this pattern, and future interfaces should clearly use it once ECMAScript supports it. A temporary moratorium on using it would not be a wise tradeoff.
These are good distinctions. I do not disagree.
Regarding named properties, I think such a moratorium is justified.
On Fri, Sep 25, 2009 at 8:27 PM, Mark S. Miller <erights at google.com> wrote:
OTOH, if our resolution of the need for array-like generic indexes is to allow overloading of [], then perhaps the resolution for new APIs is to annotate them somehow, to distinguish them from the legacy-namespace-confused-APIs-we-can't-fix, so that, for example,
storage['toString'] is equivalent to storage.getItem('toString'), and neither is considered a property access (other than access to the getItem property). storage.toString accesses storage's toString property, and is not affected by the alternate getter annotation we'd use instead of the above.
I withdraw that alternate suggestion. It would require any code attempting to access genuine properties of the storage object by computed name to resort to indirect and inconvenience means, like using Object.getOwnPropertyDescriptor() and simulating the [[Get]] algorithm.
Maciej Stachowiak:
Now, there may be pragmatic reasons for avoiding catchall getters and setters: …
Mark S. Miller:
Yes. As an obvious example of #3, what happens when a Storage dev.w3.org/html5/webstorage key is "toString"?
It’s a good example of something that’s not obvious, though it is defined. If [OverrideBuiltins] is on the interface, then toString is taken as a a named property; otherwise, it’s the property from the Storage prototype object. This is handled by the host object [[Get]] method:
Maciej Stachowiak wrote:
I think there are two possible perspectives on what constitutes "magnify[ing] the problem" or "widening the gap"
A) Any new kind of requirement for implementations of object interfaces that can't be implemented in pure ECMAScript expands the scope of the problem. B) Any new interface that isn't implementable in ECMAScript widens the gap, even if it is for a reason that also applies to legacy
My view is firmly B, for the reasons given below.
My view is A. That's why I pointed to legacy interfaces - if the construct can't go away from APIs in general, but we wish to implement all APIs in ECMAScript, then ultimately it is ECMAScript that must change, so using the same construct again doesn't create a new problem.
Yes it does:
-
In many cases, APIs are partially redundant, in such a way that developers can choose to avoid some of the legacy interfaces without any significant loss of functionality. By doing so, they can avoid the problems caused by clashes between names defined in HTML, and names of ECMAScript methods. If new APIs also use catch-alls, they are less likely to be able to do this.
-
The potential name clashes created by catch-alls also create a forward compatibility issue: if a new method is added to an interface, it might clash with names used in existing HTML content. In the case of legacy interfaces, it is less likely that we want to add new methods to them, and so this forward compatibility issue is less of a problem.
-
Implementors of subsets in which the DOM APIs are "tamed" for security reasons can choose not to implement some APIs that are problematic for them to support; but if new APIs are equally problematic, they will be unable to provide access to that functionality.
On Sep 26, 2009, at 12:20 AM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
I think there are two possible perspectives on what constitutes "magnify[ing] the problem" or "widening the gap"
A) Any new kind of requirement for implementations of object
interfaces that can't be implemented in pure ECMAScript expands the scope of the problem. B) Any new interface that isn't implementable in ECMAScript widens
the gap, even if it is for a reason that also applies to legacyMy view is firmly B, for the reasons given below.
My view is A. That's why I pointed to legacy interfaces - if the construct can't go away from APIs in general, but we wish to
implement all APIs in ECMAScript, then ultimately it is ECMAScript that must change, so using the same construct again doesn't create a new
problem.Yes it does:
In many cases, APIs are partially redundant, in such a way that developers can choose to avoid some of the legacy interfaces without any significant loss of functionality. By doing so, they can avoid
the problems caused by clashes between names defined in HTML, and
names of ECMAScript methods. If new APIs also use catch-alls, they are less likely to be able to do this.The potential name clashes created by catch-alls also create a
forward compatibility issue: if a new method is added to an interface, it might clash with names used in existing HTML content. In the case of legacy interfaces, it is less likely that we want to add new methods to them, and so this forward compatibility issue is less of a
problem.
It seems like these first two reasons are pragmatic concerns about
fully general property access catchalls, which are independent of
anyone's desire to implement the interfaces in ECMAScript. These
arguments also do not apply to other kinds of extended host object
behavior, such as array-like index access, or the fact that
document.all compares as boolean false.
- Implementors of subsets in which the DOM APIs are "tamed" for
security reasons can choose not to implement some APIs that are problematic
for them to support; but if new APIs are equally problematic, they
will be unable to provide access to that functionality.
I think trying to tame the DOM APIs is a quixotic task anyway.
A common example cited is to embedding a widget via direct DOM
embedding in a "safe" way. Presumably "safe" means you have toprevent
the widget reading or modifying the DOM outside its subtree, prevent
executing JS outside the sandbox, and prevent displaying content
outside its designated bounds. To achieve this, you have to restrict
the behavior of nearly every single DOM method, often in extremely
complicated ways that amount to reimplementing major portions of
browser functionality.
Consider for example the setAttribute method on the Element interface.
You have to intercept attempts to set the "style" attribute, parse the
CSS being set, and make sure that the widget is not trying to use CSS
positioning or overflow to display outside its bounds. You can't just
forbid CSS styling entirely, because that makes it impossible to make
a decent-looking widget. previousSibling, nextSibling, ownerDocument
all have to be prevented from going outside the tree. Any method to
find particular elements has to be essentially rewritten to prevent
going outside the tree, even something as basic as
document.getElementById(). Attempts to set the "id" attribute have to
be intercepted and the id has to be silently rewritten if it clashes
with an id used in the embedding content, so that getElementById()
calls by the embedder aren't tricked into manipulating the embedded
content. Timers have to be reimplemented to make sure their JavaScript
is executed in the sandbox. Setting <a href> to a "javascript:" URL
has to be prevented, unless you completely override the navigation
behavior of <a> elements. Creating plugins or Java applets has to be
prevented, since they can't be made to follow the security
constraints. document.write() and innerHTML have to be intercepted,
and the contents have to be parsed as HTML to prevent any forbidden
constructs in the markup. This is just scratching the surface, and
we've already found that CSS parsing, HTML parsing and DOM query
methods will have to be reimplemented (from scratch, yet in a way that
matches what the browser does) to make this work. Note that none of
this complexity is imposed by exotic host object behaviors, it's all
intrinsic to the way the Web platform works. Even considering the case
of taming LocalStorage, the catchall behavior is the least of your
worries.
The best way to serve this kind of use case is either an <iframe> with
postMessage, or inventing an entirely new API for embedded content
that doesn't even try to look anything like the DOM, and just exposes
a carefully selected set of capabilities. I don't think our time is
well spent trying to accommodate the use case of building a security
facade on top of the DOM.
, Maciej
(To es-discuss only.)
Doug Schepers today at
lists.w3.org/Archives/Public/public-webapps/2009JulSep/1463.html
announces the public-script-coord at w3.org mailing list. See Doug's post
for how to subscribe, read the public archive, etc. We should use this
list now instead of garden-hosing three lists talking about WebIDL, ES
bindings for WebIDL, etc.
Thanks to Doug, Maciej, and others involved with W3C for this,
At the upcoming TPAC, there is an opportunity for F2F coordination between these two groups, and the time slot between 10 O'Clock and Noon on Friday has been suggested for this.
To help prime the pump, here are four topics suggested by ECMA TC39 for discussion. On these and other topics, there is no need to wait for the TPAC, discussion can begin now on the es-discuss mailing list.
The current WebIDL binding to ECMAScript is based on ES3... this needs to more closely track to the evolution of ES, in particular it needs to be updated to ES5 w.r.t the Meta Object Protocol. In the process, we should discuss whether this work continues in the W3C, is done as a joint effort with ECMA, or moves to ECMA entirely.
A concern specific to HTML5 uses WebIDL in a way that precludes implementation of these objects in ECMAScript (i.e., they can only be implemented as host objects), and an explicit goal of ECMA TC39 has been to reduce such. Ideally ECMA TC39 and the W3C HTML WG would jointly develop guidance on developing web APIs, and the W3C HTML WG would apply that guidance in HTML5.
Meanwhile, I would encourage members of ECMA TC 39 who are aware of specific issues to open bug reports:
www.w3.org/Bugs/Public
And I would encourage members of the HTML WG who are interested in this topic to read up on the following emails (suggested by Brendan Eich):
mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html and the rest of that thread
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]]).
esdiscuss/2009-May/009300 on an "ArrayLike interface" with references to DOM docs at the bottom
mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html about a WebIDL float terminal value issue.
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.
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]
At the upcoming TPAC, there is an opportunity for F2F coordination between these two groups, and the time slot between 10 O'Clock and Noon on Friday has been suggested for this. To help prime the pump, here are four topics suggested by ECMA TC39 for discussion. On these and other topics, there is no need to wait for the TPAC, discussion can begin now on the es-discuss mailing list. - - - The current WebIDL binding to ECMAScript is based on ES3... this needs to more closely track to the evolution of ES, in particular it needs to be updated to ES5 w.r.t the Meta Object Protocol. In the process, we should discuss whether this work continues in the W3C, is done as a joint effort with ECMA, or moves to ECMA entirely. - - - A concern specific to HTML5 uses WebIDL in a way that precludes implementation of these objects in ECMAScript (i.e., they can only be implemented as host objects), and an explicit goal of ECMA TC39 has been to reduce such. Ideally ECMA TC39 and the W3C HTML WG would jointly develop guidance on developing web APIs, and the W3C HTML WG would apply that guidance in HTML5. Meanwhile, I would encourage members of ECMA TC 39 who are aware of specific issues to open bug reports: http://www.w3.org/Bugs/Public/ And I would encourage members of the HTML WG who are interested in this topic to read up on the following emails (suggested by Brendan Eich): 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. - - - 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. - - - 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] - Sam Ruby