ECMA TC 39 / W3C HTML and WebApps WG coordination

[rubys]

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

[Anne van Kesteren-2]

On Thu, 24 Sep 2009 14:36:56 +0200, Sam Ruby <rubys@...>  
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.)


--
Anne van Kesteren
http://annevankesteren.nl/
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Robin Berjon-2]

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.

--
Robin Berjon - http://berjon.com/



_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[James Graham-7]

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:
>
>   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.
>

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

[Maciej Stachowiak]

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.

Regards,
Maciej

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

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Maciej Stachowiak]

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:
>
>  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.

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@...> mailing list. We could continue here if it  
would be helpful. I'm not sure it's useful to discuss in person  
without being up to speed on the email discussion. Here are some  
relevant threads: <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html 
 > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html 
 > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html 
 > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html 
 >.

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.

Regards,
Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

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@...
  is at most a garden hose, which is an advantage.

Another problem is that not all Ecma TC39 members are W3C members  
(their employers are not members, that is).

There are transparency problems on both sides, IMHO. People in dark-
glass houses...

>> https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
>> and the rest of that thread
>>
>> https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
>> (not the transactional behavior, which is out -- just the
>> interaction with Array's custom [[Put]]).
>>
>> https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
>>  on an "ArrayLike interface" with references to DOM docs at the  
>> bottom
>>
>> https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
>>  about a WebIDL float terminal value issue.
>
> It seems like these are largely Web IDL issues (to the extent I can  
> identify issues in the threads at all).

TC39 members, Mark Miller articulated this yesterday, hope to restrict  
host objects in future versions of the JavaScript standard from doing  
any nutty thing they like, possibly by collaborating with WebIDL  
standardizers so that instead of "anything goes" for host objects, we  
have "only what WebIDL can express".

Catch-all magic where host object interfaces handle arbitrary property  
gets and puts are currently not implementable in ES -- this may be  
possible in a future edition, but even then it will carry performance  
penalties and introduce analysis hazards. We hope to steer ES bindings  
for WebIDL-expressed interfaces away from catch-all patterns.

Beyond this tarpit, we're interested in the best way to linearize  
multiply-inherited WebIDL interfaces onto prototype chains, or whether  
to use prototype chains at all -- or in the seemingly unlikely event  
ES grows first-class method-suite mixins, binding WebIDL inheritance  
to those. We would welcome use-cases and collobaration, at least I  
would. Who knows what better system might result?

>> There are larger (and less precise concerns at this time) about  
>> execution scope (e.g., presumptions of locking behavior,  
>> particularly by HTML5 features such as local storage).  The two  
>> groups need to work together to convert these concerns into  
>> actionable suggestions for improvement.
>
> There was extensive recent email discussion of local storage locking  
> on the <whatwg@...> mailing list. We could continue here if  
> it would be helpful. I'm not sure it's useful to discuss in person  
> without being up to speed on the email discussion. Here are some  
> relevant threads: <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html 
> > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html 
> > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html 
> > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html 
> >.

Thanks for the links, I was aware of these but hadn't read them.

Mandatory try-locks in JS, just say no.


> I'm not sure what the other concerns about "execution scope" are -  
> seems hard to discuss fruitfully without more detail.

The term I used was "execution model". "scope" is a mis-transcription.

>> We should take steps to address the following "willful violation":
>>
>> If the script's global object is a Window object, then in JavaScript,
>> the this keyword in the global scope must return the Window object's
>> WindowProxy object.
>>
>> This is a willful violation of the JavaScript specification current  
>> at
>> the time of writing (ECMAScript edition 3). The JavaScript
>> specification requires that the this keyword in the global scope
>> return the global object, but this is not compatible with the  
>> security
>> design prevalent in implementations as specified herein. [ECMA262]
>
> Wasn't ES5 fixed to address this?

No, nothing was changed in ES5 and it is not clear without more  
discussion with various experts active in whatwg, w3, and Ecma what to  
do.

Since you asked, I think you make the case that we should collaborate  
a bit more closely.


> I know the feedback was passed along.

Yes, but describing the problem does not give the solution.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[wycats]

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).

-- Yehuda

On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich <brendan@...> 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@... is at most a garden hose, which is an advantage.

Another problem is that not all Ecma TC39 members are W3C members (their employers are not members, that is).

There are transparency problems on both sides, IMHO. People in dark-glass houses...

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
and the rest of that thread

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
(not the transactional behavior, which is out -- just the
interaction with Array's custom [[Put]]).

https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
 on an "ArrayLike interface" with references to DOM docs at the bottom

https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
 about a WebIDL float terminal value issue.

It seems like these are largely Web IDL issues (to the extent I can identify issues in the threads at all).

TC39 members, Mark Miller articulated this yesterday, hope to restrict host objects in future versions of the JavaScript standard from doing any nutty thing they like, possibly by collaborating with WebIDL standardizers so that instead of "anything goes" for host objects, we have "only what WebIDL can express".

Catch-all magic where host object interfaces handle arbitrary property gets and puts are currently not implementable in ES -- this may be possible in a future edition, but even then it will carry performance penalties and introduce analysis hazards. We hope to steer ES bindings for WebIDL-expressed interfaces away from catch-all patterns.

Beyond this tarpit, we're interested in the best way to linearize multiply-inherited WebIDL interfaces onto prototype chains, or whether to use prototype chains at all -- or in the seemingly unlikely event ES grows first-class method-suite mixins, binding WebIDL inheritance to those. We would welcome use-cases and collobaration, at least I would. Who knows what better system might result?

There are larger (and less precise concerns at this time) about execution scope (e.g., presumptions of locking behavior, particularly by HTML5 features such as local storage).  The two groups need to work together to convert these concerns into actionable suggestions for improvement.

There was extensive recent email discussion of local storage locking on the <whatwg@...> mailing list. We could continue here if it would be helpful. I'm not sure it's useful to discuss in person without being up to speed on the email discussion. Here are some relevant threads: <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html>.

Thanks for the links, I was aware of these but hadn't read them.

Mandatory try-locks in JS, just say no.

I'm not sure what the other concerns about "execution scope" are - seems hard to discuss fruitfully without more detail.

The term I used was "execution model". "scope" is a mis-transcription.

We should take steps to address the following "willful violation":

If the script's global object is a Window object, then in JavaScript,
the this keyword in the global scope must return the Window object's
WindowProxy object.

This is a willful violation of the JavaScript specification current at
the time of writing (ECMAScript edition 3). The JavaScript
specification requires that the this keyword in the global scope
return the global object, but this is not compatible with the security
design prevalent in implementations as specified herein. [ECMA262]

Wasn't ES5 fixed to address this?

No, nothing was changed in ES5 and it is not clear without more discussion with various experts active in whatwg, w3, and Ecma what to do.

Since you asked, I think you make the case that we should collaborate a bit more closely.

I know the feedback was passed along.

Yes, but describing the problem does not give the solution.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Maciej Stachowiak]

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@...
>  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...
>
>
>>> https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
>>> and the rest of that thread
>>>
>>> https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
>>> (not the transactional behavior, which is out -- just the
>>> interaction with Array's custom [[Put]]).
>>>
>>> https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
>>> on an "ArrayLike interface" with references to DOM docs at the  
>>> bottom
>>>
>>> https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
>>> about a WebIDL float terminal value issue.
>>
>> It seems like these are largely Web IDL issues (to the extent I can  
>> identify issues in the threads at all).
>
> TC39 members, Mark Miller articulated this yesterday, hope to  
> restrict host objects in future versions of the JavaScript standard  
> from doing any nutty thing they like, possibly by collaborating with  
> WebIDL standardizers so that instead of "anything goes" for host  
> objects, we have "only what WebIDL can express".
>
> Catch-all magic where host object interfaces handle arbitrary  
> property gets and puts are currently not implementable in ES -- this  
> may be possible in a future edition, but even then it will carry  
> performance penalties and introduce analysis hazards. We hope to  
> steer ES bindings for WebIDL-expressed interfaces away from catch-
> all patterns.

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@...> mailing list. We could continue  
>> here if it would be helpful. I'm not sure it's useful to discuss in  
>> person without being up to speed on the email discussion. Here are  
>> some relevant threads: <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html 
>> > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html 
>> > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html 
>> > <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html 
>> >.
>
> Thanks for the links, I was aware of these but hadn't read them.
>
> Mandatory try-locks in JS, just say no.

I 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.)

Regards,
Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Maciej Stachowiak]

On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:

Maybe this would be a good opportunity to revisit the utility of WebIDL in specifications (as formal specifications were re-examined for ES-Harmony). The WebIDL spec is pretty large, and I personally have found its use a confounding factor in understanding other specs (like HTML5).

Its utility is in providing a way to specify API behavior in a way that is consistent between specifications, language-independent, and reasonably concise. It's true that it adds an additional thing you have to learn. That's regrettable, but there are a lot of details that need to be specified to get interoperability. Pre-WebIDL specs such as DOM Level 2[1] left many details undefined, leading to problematic behavior differences among browsers and a need for mutual reverse-engineering.

Regards,

Maciej

[1] http://www.w3.org/TR/DOM-Level-2-Core/

-- Yehuda

On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich <brendan@...> 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@... is at most a garden hose, which is an advantage.

Another problem is that not all Ecma TC39 members are W3C members (their employers are not members, that is).

There are transparency problems on both sides, IMHO. People in dark-glass houses...

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
and the rest of that thread

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
(not the transactional behavior, which is out -- just the
interaction with Array's custom [[Put]]).

https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
 on an "ArrayLike interface" with references to DOM docs at the bottom

https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
 about a WebIDL float terminal value issue.

It seems like these are largely Web IDL issues (to the extent I can identify issues in the threads at all).

TC39 members, Mark Miller articulated this yesterday, hope to restrict host objects in future versions of the JavaScript standard from doing any nutty thing they like, possibly by collaborating with WebIDL standardizers so that instead of "anything goes" for host objects, we have "only what WebIDL can express".

Catch-all magic where host object interfaces handle arbitrary property gets and puts are currently not implementable in ES -- this may be possible in a future edition, but even then it will carry performance penalties and introduce analysis hazards. We hope to steer ES bindings for WebIDL-expressed interfaces away from catch-all patterns.

Beyond this tarpit, we're interested in the best way to linearize multiply-inherited WebIDL interfaces onto prototype chains, or whether to use prototype chains at all -- or in the seemingly unlikely event ES grows first-class method-suite mixins, binding WebIDL inheritance to those. We would welcome use-cases and collobaration, at least I would. Who knows what better system might result?

There are larger (and less precise concerns at this time) about execution scope (e.g., presumptions of locking behavior, particularly by HTML5 features such as local storage).  The two groups need to work together to convert these concerns into actionable suggestions for improvement.

There was extensive recent email discussion of local storage locking on the <whatwg@...> mailing list. We could continue here if it would be helpful. I'm not sure it's useful to discuss in person without being up to speed on the email discussion. Here are some relevant threads: <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html>.

Thanks for the links, I was aware of these but hadn't read them.

Mandatory try-locks in JS, just say no.

I'm not sure what the other concerns about "execution scope" are - seems hard to discuss fruitfully without more detail.

The term I used was "execution model". "scope" is a mis-transcription.

We should take steps to address the following "willful violation":

If the script's global object is a Window object, then in JavaScript,
the this keyword in the global scope must return the Window object's
WindowProxy object.

This is a willful violation of the JavaScript specification current at
the time of writing (ECMAScript edition 3). The JavaScript
specification requires that the this keyword in the global scope
return the global object, but this is not compatible with the security
design prevalent in implementations as specified herein. [ECMA262]

Wasn't ES5 fixed to address this?

No, nothing was changed in ES5 and it is not clear without more discussion with various experts active in whatwg, w3, and Ecma what to do.

Since you asked, I think you make the case that we should collaborate a bit more closely.

I know the feedback was passed along.

Yes, but describing the problem does not give the solution.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[wycats]

Is it really true that WebIDL and the vague way DOM2 was described are the only two options? Surely that's a false dilemma?

-- Yehuda

On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak <mjs@...> wrote:

On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:

Maybe this would be a good opportunity to revisit the utility of WebIDL in specifications (as formal specifications were re-examined for ES-Harmony). The WebIDL spec is pretty large, and I personally have found its use a confounding factor in understanding other specs (like HTML5).

Its utility is in providing a way to specify API behavior in a way that is consistent between specifications, language-independent, and reasonably concise. It's true that it adds an additional thing you have to learn. That's regrettable, but there are a lot of details that need to be specified to get interoperability. Pre-WebIDL specs such as DOM Level 2[1] left many details undefined, leading to problematic behavior differences among browsers and a need for mutual reverse-engineering.

Regards,

Maciej

[1] http://www.w3.org/TR/DOM-Level-2-Core/

-- Yehuda

On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich <brendan@...> 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@... is at most a garden hose, which is an advantage.

Another problem is that not all Ecma TC39 members are W3C members (their employers are not members, that is).

There are transparency problems on both sides, IMHO. People in dark-glass houses...

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
and the rest of that thread

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
(not the transactional behavior, which is out -- just the
interaction with Array's custom [[Put]]).

https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
 on an "ArrayLike interface" with references to DOM docs at the bottom

https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
 about a WebIDL float terminal value issue.

It seems like these are largely Web IDL issues (to the extent I can identify issues in the threads at all).

TC39 members, Mark Miller articulated this yesterday, hope to restrict host objects in future versions of the JavaScript standard from doing any nutty thing they like, possibly by collaborating with WebIDL standardizers so that instead of "anything goes" for host objects, we have "only what WebIDL can express".

Catch-all magic where host object interfaces handle arbitrary property gets and puts are currently not implementable in ES -- this may be possible in a future edition, but even then it will carry performance penalties and introduce analysis hazards. We hope to steer ES bindings for WebIDL-expressed interfaces away from catch-all patterns.

Beyond this tarpit, we're interested in the best way to linearize multiply-inherited WebIDL interfaces onto prototype chains, or whether to use prototype chains at all -- or in the seemingly unlikely event ES grows first-class method-suite mixins, binding WebIDL inheritance to those. We would welcome use-cases and collobaration, at least I would. Who knows what better system might result?

There are larger (and less precise concerns at this time) about execution scope (e.g., presumptions of locking behavior, particularly by HTML5 features such as local storage).  The two groups need to work together to convert these concerns into actionable suggestions for improvement.

There was extensive recent email discussion of local storage locking on the <whatwg@...> mailing list. We could continue here if it would be helpful. I'm not sure it's useful to discuss in person without being up to speed on the email discussion. Here are some relevant threads: <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html>.

Thanks for the links, I was aware of these but hadn't read them.

Mandatory try-locks in JS, just say no.

I'm not sure what the other concerns about "execution scope" are - seems hard to discuss fruitfully without more detail.

The term I used was "execution model". "scope" is a mis-transcription.

We should take steps to address the following "willful violation":

If the script's global object is a Window object, then in JavaScript,
the this keyword in the global scope must return the Window object's
WindowProxy object.

This is a willful violation of the JavaScript specification current at
the time of writing (ECMAScript edition 3). The JavaScript
specification requires that the this keyword in the global scope
return the global object, but this is not compatible with the security
design prevalent in implementations as specified herein. [ECMA262]

Wasn't ES5 fixed to address this?

No, nothing was changed in ES5 and it is not clear without more discussion with various experts active in whatwg, w3, and Ecma what to do.

Since you asked, I think you make the case that we should collaborate a bit more closely.

I know the feedback was passed along.

Yes, but describing the problem does not give the solution.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Maciej Stachowiak]

On Sep 24, 2009, at 11:11 AM, Yehuda Katz wrote:

Is it really true that WebIDL and the vague way DOM2 was described are the only two options? Surely that's a false dilemma?

I'm not saying those are the only two options. I'm explaining how WebIDL solves a problem. Are there other ways to solve the problem? Probably. Do you have a specific proposal?

Regards,

Maciej

-- Yehuda

On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak <mjs@...> wrote:

On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:

Maybe this would be a good opportunity to revisit the utility of WebIDL in specifications (as formal specifications were re-examined for ES-Harmony). The WebIDL spec is pretty large, and I personally have found its use a confounding factor in understanding other specs (like HTML5).

Its utility is in providing a way to specify API behavior in a way that is consistent between specifications, language-independent, and reasonably concise. It's true that it adds an additional thing you have to learn. That's regrettable, but there are a lot of details that need to be specified to get interoperability. Pre-WebIDL specs such as DOM Level 2[1] left many details undefined, leading to problematic behavior differences among browsers and a need for mutual reverse-engineering.

Regards,

Maciej

[1] http://www.w3.org/TR/DOM-Level-2-Core/

-- Yehuda

On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich <brendan@...> 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@... is at most a garden hose, which is an advantage.

Another problem is that not all Ecma TC39 members are W3C members (their employers are not members, that is).

There are transparency problems on both sides, IMHO. People in dark-glass houses...

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
and the rest of that thread

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
(not the transactional behavior, which is out -- just the
interaction with Array's custom [[Put]]).

https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
 on an "ArrayLike interface" with references to DOM docs at the bottom

https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
 about a WebIDL float terminal value issue.

It seems like these are largely Web IDL issues (to the extent I can identify issues in the threads at all).

TC39 members, Mark Miller articulated this yesterday, hope to restrict host objects in future versions of the JavaScript standard from doing any nutty thing they like, possibly by collaborating with WebIDL standardizers so that instead of "anything goes" for host objects, we have "only what WebIDL can express".

Catch-all magic where host object interfaces handle arbitrary property gets and puts are currently not implementable in ES -- this may be possible in a future edition, but even then it will carry performance penalties and introduce analysis hazards. We hope to steer ES bindings for WebIDL-expressed interfaces away from catch-all patterns.

Beyond this tarpit, we're interested in the best way to linearize multiply-inherited WebIDL interfaces onto prototype chains, or whether to use prototype chains at all -- or in the seemingly unlikely event ES grows first-class method-suite mixins, binding WebIDL inheritance to those. We would welcome use-cases and collobaration, at least I would. Who knows what better system might result?

There are larger (and less precise concerns at this time) about execution scope (e.g., presumptions of locking behavior, particularly by HTML5 features such as local storage).  The two groups need to work together to convert these concerns into actionable suggestions for improvement.

There was extensive recent email discussion of local storage locking on the <whatwg@...> mailing list. We could continue here if it would be helpful. I'm not sure it's useful to discuss in person without being up to speed on the email discussion. Here are some relevant threads: <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html>.

Thanks for the links, I was aware of these but hadn't read them.

Mandatory try-locks in JS, just say no.

I'm not sure what the other concerns about "execution scope" are - seems hard to discuss fruitfully without more detail.

The term I used was "execution model". "scope" is a mis-transcription.

We should take steps to address the following "willful violation":

If the script's global object is a Window object, then in JavaScript,
the this keyword in the global scope must return the Window object's
WindowProxy object.

This is a willful violation of the JavaScript specification current at
the time of writing (ECMAScript edition 3). The JavaScript
specification requires that the this keyword in the global scope
return the global object, but this is not compatible with the security
design prevalent in implementations as specified herein. [ECMA262]

Wasn't ES5 fixed to address this?

No, nothing was changed in ES5 and it is not clear without more discussion with various experts active in whatwg, w3, and Ecma what to do.

Since you asked, I think you make the case that we should collaborate a bit more closely.

I know the feedback was passed along.

Yes, but describing the problem does not give the solution.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

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@...
>>  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 http://wiki.ecmascript.org/ 
. 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.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Maciej Stachowiak]

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@...
>>>  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.

Regards,
Maciej



_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[wycats]

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.

-- Yehuda

On Thu, Sep 24, 2009 at 11:17 AM, Maciej Stachowiak <mjs@...> wrote:

On Sep 24, 2009, at 11:11 AM, Yehuda Katz wrote:

Is it really true that WebIDL and the vague way DOM2 was described are the only two options? Surely that's a false dilemma?

I'm not saying those are the only two options. I'm explaining how WebIDL solves a problem. Are there other ways to solve the problem? Probably. Do you have a specific proposal?

Regards,

Maciej

-- Yehuda

On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak <mjs@...> wrote:

On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:

Maybe this would be a good opportunity to revisit the utility of WebIDL in specifications (as formal specifications were re-examined for ES-Harmony). The WebIDL spec is pretty large, and I personally have found its use a confounding factor in understanding other specs (like HTML5).

Its utility is in providing a way to specify API behavior in a way that is consistent between specifications, language-independent, and reasonably concise. It's true that it adds an additional thing you have to learn. That's regrettable, but there are a lot of details that need to be specified to get interoperability. Pre-WebIDL specs such as DOM Level 2[1] left many details undefined, leading to problematic behavior differences among browsers and a need for mutual reverse-engineering.

Regards,

Maciej

[1] http://www.w3.org/TR/DOM-Level-2-Core/

-- Yehuda

On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich <brendan@...> 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@... is at most a garden hose, which is an advantage.

Another problem is that not all Ecma TC39 members are W3C members (their employers are not members, that is).

There are transparency problems on both sides, IMHO. People in dark-glass houses...

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
and the rest of that thread

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
(not the transactional behavior, which is out -- just the
interaction with Array's custom [[Put]]).

https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
 on an "ArrayLike interface" with references to DOM docs at the bottom

https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
 about a WebIDL float terminal value issue.

It seems like these are largely Web IDL issues (to the extent I can identify issues in the threads at all).

TC39 members, Mark Miller articulated this yesterday, hope to restrict host objects in future versions of the JavaScript standard from doing any nutty thing they like, possibly by collaborating with WebIDL standardizers so that instead of "anything goes" for host objects, we have "only what WebIDL can express".

Catch-all magic where host object interfaces handle arbitrary property gets and puts are currently not implementable in ES -- this may be possible in a future edition, but even then it will carry performance penalties and introduce analysis hazards. We hope to steer ES bindings for WebIDL-expressed interfaces away from catch-all patterns.

Beyond this tarpit, we're interested in the best way to linearize multiply-inherited WebIDL interfaces onto prototype chains, or whether to use prototype chains at all -- or in the seemingly unlikely event ES grows first-class method-suite mixins, binding WebIDL inheritance to those. We would welcome use-cases and collobaration, at least I would. Who knows what better system might result?

There are larger (and less precise concerns at this time) about execution scope (e.g., presumptions of locking behavior, particularly by HTML5 features such as local storage).  The two groups need to work together to convert these concerns into actionable suggestions for improvement.

There was extensive recent email discussion of local storage locking on the <whatwg@...> mailing list. We could continue here if it would be helpful. I'm not sure it's useful to discuss in person without being up to speed on the email discussion. Here are some relevant threads: <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html>.

Thanks for the links, I was aware of these but hadn't read them.

Mandatory try-locks in JS, just say no.

I'm not sure what the other concerns about "execution scope" are - seems hard to discuss fruitfully without more detail.

The term I used was "execution model". "scope" is a mis-transcription.

We should take steps to address the following "willful violation":

If the script's global object is a Window object, then in JavaScript,
the this keyword in the global scope must return the Window object's
WindowProxy object.

This is a willful violation of the JavaScript specification current at
the time of writing (ECMAScript edition 3). The JavaScript
specification requires that the this keyword in the global scope
return the global object, but this is not compatible with the security
design prevalent in implementations as specified herein. [ECMA262]

Wasn't ES5 fixed to address this?

No, nothing was changed in ES5 and it is not clear without more discussion with various experts active in whatwg, w3, and Ecma what to do.

Since you asked, I think you make the case that we should collaborate a bit more closely.

I know the feedback was passed along.

Yes, but describing the problem does not give the solution.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Maciej Stachowiak]

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.

 - Maciej 

-- Yehuda

On Thu, Sep 24, 2009 at 11:17 AM, Maciej Stachowiak <mjs@...> wrote:

On Sep 24, 2009, at 11:11 AM, Yehuda Katz wrote:

Is it really true that WebIDL and the vague way DOM2 was described are the only two options? Surely that's a false dilemma?

I'm not saying those are the only two options. I'm explaining how WebIDL solves a problem. Are there other ways to solve the problem? Probably. Do you have a specific proposal?

Regards,

Maciej

-- Yehuda

On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak <mjs@...> wrote:

On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:

Maybe this would be a good opportunity to revisit the utility of WebIDL in specifications (as formal specifications were re-examined for ES-Harmony). The WebIDL spec is pretty large, and I personally have found its use a confounding factor in understanding other specs (like HTML5).

Its utility is in providing a way to specify API behavior in a way that is consistent between specifications, language-independent, and reasonably concise. It's true that it adds an additional thing you have to learn. That's regrettable, but there are a lot of details that need to be specified to get interoperability. Pre-WebIDL specs such as DOM Level 2[1] left many details undefined, leading to problematic behavior differences among browsers and a need for mutual reverse-engineering.

Regards,

Maciej

[1] http://www.w3.org/TR/DOM-Level-2-Core/

-- Yehuda

On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich <brendan@...> 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@... is at most a garden hose, which is an advantage.

Another problem is that not all Ecma TC39 members are W3C members (their employers are not members, that is).

There are transparency problems on both sides, IMHO. People in dark-glass houses...

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
and the rest of that thread

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
(not the transactional behavior, which is out -- just the
interaction with Array's custom [[Put]]).

https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
 on an "ArrayLike interface" with references to DOM docs at the bottom

https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
 about a WebIDL float terminal value issue.

It seems like these are largely Web IDL issues (to the extent I can identify issues in the threads at all).

TC39 members, Mark Miller articulated this yesterday, hope to restrict host objects in future versions of the JavaScript standard from doing any nutty thing they like, possibly by collaborating with WebIDL standardizers so that instead of "anything goes" for host objects, we have "only what WebIDL can express".

Catch-all magic where host object interfaces handle arbitrary property gets and puts are currently not implementable in ES -- this may be possible in a future edition, but even then it will carry performance penalties and introduce analysis hazards. We hope to steer ES bindings for WebIDL-expressed interfaces away from catch-all patterns.

Beyond this tarpit, we're interested in the best way to linearize multiply-inherited WebIDL interfaces onto prototype chains, or whether to use prototype chains at all -- or in the seemingly unlikely event ES grows first-class method-suite mixins, binding WebIDL inheritance to those. We would welcome use-cases and collobaration, at least I would. Who knows what better system might result?

There are larger (and less precise concerns at this time) about execution scope (e.g., presumptions of locking behavior, particularly by HTML5 features such as local storage).  The two groups need to work together to convert these concerns into actionable suggestions for improvement.

There was extensive recent email discussion of local storage locking on the <whatwg@...> mailing list. We could continue here if it would be helpful. I'm not sure it's useful to discuss in person without being up to speed on the email discussion. Here are some relevant threads: <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html>.

Thanks for the links, I was aware of these but hadn't read them.

Mandatory try-locks in JS, just say no.

I'm not sure what the other concerns about "execution scope" are - seems hard to discuss fruitfully without more detail.

The term I used was "execution model". "scope" is a mis-transcription.

We should take steps to address the following "willful violation":

If the script's global object is a Window object, then in JavaScript,
the this keyword in the global scope must return the Window object's
WindowProxy object.

This is a willful violation of the JavaScript specification current at
the time of writing (ECMAScript edition 3). The JavaScript
specification requires that the this keyword in the global scope
return the global object, but this is not compatible with the security
design prevalent in implementations as specified herein. [ECMA262]

Wasn't ES5 fixed to address this?

No, nothing was changed in ES5 and it is not clear without more discussion with various experts active in whatwg, w3, and Ecma what to do.

Since you asked, I think you make the case that we should collaborate a bit more closely.

I know the feedback was passed along.

Yes, but describing the problem does not give the solution.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

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

http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.x_working_docs&cache=cache&media=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:

 http://damowmow.com/playground/demos/global-object/001.html
 http://damowmow.com/playground/demos/global-object/002.html
 http://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?

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[rubys]

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:

  http://www.w3.org/2004/08/invexp.html

On Thu, Sep 24, 2009 at 5:02 PM, Brendan Eich <brendan@...> 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
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Maciej Stachowiak]

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:
>
>  http://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.

Regards,
Maciej

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[rubys]

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:
>>
>>  http://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.

> Regards,
> Maciej

- Sam Ruby


_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss