subject:"ECMA TC 39 \/ W3C HTML and WebApps WG coordination"

2009-09-27 Thread ~:'' ありがとうございました



On Sep 26, 2009, at 8:05 PM, Brendan Eich wrote:


On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:


- Note: I think catchall deleters are used only by Web Storage and
not by other new or legacy interfaces.


Seems like a strong reason to change to the proposed API to  
eliminate the need for

a new ES language extension.


I previously argued for removing the need for catchall deleters  
from the Web Storage API (since nothing else requires , but other  
browser vendors (including  Mozilla) were happy with it,


(including Mozilla) and happy with it leave out some nuance:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014856.html

Robert O'Callahan here wrote If overloading delete is too quirky  
or too hard to implement, then it seems none of the other shorthands  
should be allowed either. His message adverted to the better course  
of methodical access instead of property access to Web Storage keyed  
values.


Alas Rob finally gave up at:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014868.html

I think the Web Storage key/value reflection as properties is a  
mistake. Sorry I wasn't reviewing it in time to say so. But it was  
obviously not a situation everyone was happy with, even ignoring  
the issue of delete.


I accept your corrections as to nuance. At the time I felt like I was  
fighting a losing battle. The real issue, though, is what to do going  
forward.





and I think now everyone (including I believe Microsoft) has  
implemented the spec behavior. See prior discussion thread here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014851.html 
.  At this point, since we have multiple deployed implementations  
of Web Storage, we'd have to investigate whether it's safe to  
remove this behavior without breaking content.


We could try to remove it -- or (what is more likely to go down  
easily) we could add methods and let the property reflections  
wither, and vow to avoid repeating this mistake.


There are methods, but I'm not optimistic that they will cause  
property reflection to wither.


If the number of places in the Web platform that require custom delete  
behavior goes from 1 to 2, that's a lot less bad than going from 0 to  
1. So it won't accomplish much. However, I missed a spot and it looks  
like custom deleters are also used by the DOMStringMap interface,  
which is used to reflect data-* attributes. http://dev.w3.org/html5/spec/Overview.html#domstringmap-0 
 I don't think anyone has implemented that yet.


I believe we could get rid of custom deleters from the Web platform if  
Firefox and IE remove support for custom deleters in LocalStorage,  
refuse to add it back, and refuse to implement it for DOMStringMap. If  
that happened, I'm sure other browsers and the spec would follow suit.  
I don't think I can convince my colleagues to remove the behavior from  
WebKit if Gecko and Trident continue to support it.






2) Ability to support being called (via [[Call]]) without being a
Function.


Not an issue with the core ES5 semantics.  Most ES3/5 section 15  
functions have this
characteristic. As long as such WebIDL objects are defined  
similarly to the built-in
function they too can have this characteristic. It may well be  
useful to introduce a
mechanism defining such pure functions in the language but it  
probably isn't necessary
to proceed with the WebIDL binding.  The important thing to try to  
avoid is specify

a custom [[Call]]


I tend to agree that this behavior (and the next 3) are not  
philosophically problematic, even though they cannot today be  
implemented in pure ECMAScript.


What does typeof say for such a callable object?


I think it should probably say object, though that's not compatible  
with ES3 or current WebKit practice.




In what sense are any DOM methods required to be not Functions  
(native function objects) in the specs? In Netscape of old and  
Mozilla browsers since 1998, DOM methods are native function objects.


This is not an issue for DOM methods. It's an issue for interfaces  
such as HTMLCollection and HTMLFormElement that support indexing by  
function call syntax, for legacy compatibility reasons. Constructors  
like XMLHttpRequest, Option and Image also do not inherit from  
Function.prototype even though they are callable.


This seems winning since developers want not only sane typeof,  
but .apply/call/bind.


It's definitely winning, and it may be possible to apply it to global  
constructors that are also callable as a future improvement, but it's  
probably not possible to make HTMLCollection or HTMLFormElement  
inherit from the Function prototype, and I think it would not be  
desirable either.




We've talked on es-discuss about pure functions (ones without  
[[Construct]] and .prototype) before:


https://mail.mozilla.org/pipermail/es5-discuss/2009-July/002920.html

in case you missed the thread. Agreed it's not a big deal. We have a  
bugzilla.mozilla.org

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

2009-09-27 Thread Brendan Eich


On Sep 26, 2009, at 11:28 PM, Maciej Stachowiak wrote:

There are methods, but I'm not optimistic that they will cause  
property reflection to wither.


getItem/setItem/removeItem/key/clear methods, plus .length -- not a  
balanced name-set stylistically, but usable to avoid collisions (my  
key is named 'key', heh).


Agreed it looks nearly hopeless to herd developers toward always using  
these methods instead of .myKey, etc.



If the number of places in the Web platform that require custom  
delete behavior goes from 1 to 2, that's a lot less bad than going  
from 0 to 1. So it won't accomplish much. However, I missed a spot  
and it looks like custom deleters are also used by the DOMStringMap  
interface, which is used to reflect data-* attributes. http://dev.w3.org/html5/spec/Overview.html#domstringmap-0 
 I don't think anyone has implemented that yet.


Horses still out the barn door and we didn't close it yet, I'm not  
sure who to blame except us (would be barn-door closers, possibly in  
charge of those horses -- but perhaps they're not even ours!).



I believe we could get rid of custom deleters from the Web platform  
if Firefox and IE remove support for custom deleters in  
LocalStorage, refuse to add it back, and refuse to implement it for  
DOMStringMap. If that happened, I'm sure other browsers and the spec  
would follow suit. I don't think I can convince my colleagues to  
remove the behavior from WebKit if Gecko and Trident continue to  
support it.


I'll see what the relevant Mozilla WebAPI hackers think, if they're  
not reading this thread. At this point I suspect it is too late, in  
the sense that we'd be taking risks with plaform compatibility we  
don't accept in our release version/compatibility plan.




What does typeof say for such a callable object?


I think it should probably say object, though that's not  
compatible with ES3 or current WebKit practice.


ES3 lets host objects choose function or object or any old string  
(Implementation-dependent).


ES5 says:

Object (native or host and does implement [[Call]])
  - function

Object (host and does not implement [[Call]])
  - Implementation-defined except may not be undefined, boolean,  
number, or string.



This is not an issue for DOM methods. It's an issue for interfaces  
such as HTMLCollection and HTMLFormElement that support indexing by  
function call syntax, for legacy compatibility reasons. Constructors  
like XMLHttpRequest, Option and Image also do not inherit from  
Function.prototype even though they are callable.


Right, thanks for clarifying that. DOM collection types, even if  
callable (VBScript was to blame) are not function objects, and DOM  
constructors, unlike chapter 15 built-in ES constructors, are not  
generally function objects.



This seems winning since developers want not only sane typeof,  
but .apply/call/bind.


It's definitely winning, and it may be possible to apply it to  
global constructors that are also callable as a future improvement,  
but it's probably not possible to make HTMLCollection or  
HTMLFormElement inherit from the Function prototype, and I think it  
would not be desirable either.


Why not for HTMLFormElement? Agree for HTMLCollection.


Perhaps it's sufficient to provide an API for altering the [[Call]]  
and [[Construct]] behavior of an existing object without a first- 
class syntax, following in the spirit of defineOwnProperty().  
Something like foo.defineOperation(construct,  
funcToCallWhenConstructing). This would address all of points 2 to  
5, for ECMAScript implementations that wish to precisely replicate  
DOM behavior. This approach could also be used for index getters/ 
setters/has-testers, general catchall getters/setters/has-testers,  
removing either one of call or construct while retaining the other,  
making call and construct do different things, and perhaps other  
useses. And using a method instead of first-class syntax would let  
scripts feature-test for this capability.


See http://wiki.ecmascript.org/doku.php?id=strawman:catchalls but note  
objections there, as well as some alternatives discussed in es-disc...@mozilla.org 
.


A MOP for catchalls that stratifies the hooks into mirage (by analogy  
to mirror-based reflection) objects may be forthcoming; we'll see  
(I'll let the experts say more). A dark horse, at this point, but hey,  
those other horses made it out of the barn ;-).


For simple things like non-constructor functions one might prefer a  
declarative form. As an implementor and a developer, I would --  
mutation is a bitch to optimize in a VM, and to contain in one's user  
code. Also the meta-programming API seems likely to be more verbose  
than the (still elusive, but stipulate that it must be concise)  
hypothetical declarative syntax.



Ye olde Image and Option, at least, act like most built-in  
constructors by constructing when called, at least in Gecko and I  
think IE -- but not in WebKit (I just tested).


My

W3C process: was: ECMA TC 39 / W3C HTML and WebApps WG coordination


Yehuda,

I have raised the issue[1][2] you outline with Ian Jacobs, the W3C   
Process working group and others at W3C,


It's my particular concern and thesis that authors and end-users,  
including those requiring alternative affordance

are not well represented on W3C working groups.

Why is there no W3C UA Games technology or WG?

regards

Jonathan Chetwynd
Honte.eu



Jonathan Chetwynd

j.chetw...@btinternet.com
http://www.openicon.org/

+44 (0) 20 7978 1764



[1] On 24 Sep 2009, at 20:00, 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.


-- Yehuda



[2] There are for instance a very large number of published comments  
raising similar concerns, regarding the technical language of  WCAG2   
- WAI, W3C.

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 27, 2009, at 12:30 AM, Brendan Eich wrote:


On Sep 26, 2009, at 11:28 PM, Maciej Stachowiak wrote:



What does typeof say for such a callable object?


I think it should probably say object, though that's not  
compatible with ES3 or current WebKit practice.


ES3 lets host objects choose function or object or any old  
string (Implementation-dependent).


ES5 says:

Object (native or host and does implement [[Call]])
 - function

Object (host and does not implement [[Call]])
 - Implementation-defined except may not be undefined, boolean,  
number, or string.


I think it may be a compatibility risk for HTMLCollection to report  
its type as function instead of object.





This is not an issue for DOM methods. It's an issue for interfaces  
such as HTMLCollection and HTMLFormElement that support indexing by  
function call syntax, for legacy compatibility reasons.  
Constructors like XMLHttpRequest, Option and Image also do not  
inherit from Function.prototype even though they are callable.


Right, thanks for clarifying that. DOM collection types, even if  
callable (VBScript was to blame) are not function objects, and DOM  
constructors, unlike chapter 15 built-in ES constructors, are not  
generally function objects.



This seems winning since developers want not only sane typeof,  
but .apply/call/bind.


It's definitely winning, and it may be possible to apply it to  
global constructors that are also callable as a future improvement,  
but it's probably not possible to make HTMLCollection or  
HTMLFormElement inherit from the Function prototype, and I think it  
would not be desirable either.


Why not for HTMLFormElement? Agree for HTMLCollection.


By HTMLFormElement I mean the actual instances that represent the  
form element in an HTML DOM, not the pseudo-constructor object named  
HTMLFormElement on the window object. HTML5 gives it callable  
indexing. It already inherits from HTMLElement (and Element and Node)  
so it's unclear how to stick Function into its prototype chain. And I  
don't think we want call(), apply() and bind() methods to start  
appearing on form elements.





Perhaps it's sufficient to provide an API for altering the [[Call]]  
and [[Construct]] behavior of an existing object without a first- 
class syntax, following in the spirit of defineOwnProperty().  
Something like foo.defineOperation(construct,  
funcToCallWhenConstructing). This would address all of points 2 to  
5, for ECMAScript implementations that wish to precisely replicate  
DOM behavior. This approach could also be used for index getters/ 
setters/has-testers, general catchall getters/setters/has-testers,  
removing either one of call or construct while retaining the other,  
making call and construct do different things, and perhaps other  
useses. And using a method instead of first-class syntax would let  
scripts feature-test for this capability.


See http://wiki.ecmascript.org/doku.php?id=strawman:catchalls but  
note objections there, as well as some alternatives discussed in es-disc...@mozilla.org 
.


Thanks for the reference. That does look similar to my suggestion.  
However, it looks like the invoke and construct methods there are  
intended for calling a property of the object (or invoking it as a  
constructor), rather than for applying call or construct to the object  
itself.




A MOP for catchalls that stratifies the hooks into mirage (by  
analogy to mirror-based reflection) objects may be forthcoming;  
we'll see (I'll let the experts say more). A dark horse, at this  
point, but hey, those other horses made it out of the barn ;-).


For simple things like non-constructor functions one might prefer a  
declarative form. As an implementor and a developer, I would --  
mutation is a bitch to optimize in a VM, and to contain in one's  
user code. Also the meta-programming API seems likely to be more  
verbose than the (still elusive, but stipulate that it must be  
concise) hypothetical declarative syntax.


Sure - one way a MOP approach helps is by moving past debates about  
the most elegant syntax, by having unapologetically inelegant syntax.  
Then maybe once the capability is there, someone can invent good  
syntax later.





Ye olde Image and Option, at least, act like most built-in  
constructors by constructing when called, at least in Gecko and I  
think IE -- but not in WebKit (I just tested).


My testing seems to indicate not in IE. Likewise for  
XMLHttpRequest. We should probably specify one way or the other  
whether these are callable and stick to it. I am indifferent as to  
which behavior we standardize on.


Me too, except if I had to do it all over again I would have worked  
harder to make function-ness orthogonal to prototype, a mixin if you  
will.


I wish functions and constructors were different kinds of things. I'm  
not sure if that's the same kind of idea you're talking about.



At this point,

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 27, 2009, at 11:28 AM, Brendan Eich wrote:


On Sep 27, 2009, at 2:57 AM, Maciej Stachowiak wrote:

I'm musing a bit here, bear with me. If we only hack  
incrementally, and preserve backward compatibility with frankly  
dumb (or merely hasty) design decisions (many mine!) then we'll  
probably make less progress than if we try to rationalize old and  
new in a better systematic design.


That's a little too abstract for me to tell if I agree or not.


Shortest-path evolution can walk uphill only a little bit at a time,  
and get stuck at local minimal points in a design space, when over  
the big hill is a much better, richer valley to evolve in. This path  
dependency problem bits many real-world systems.


I experience this point as hard and painful, like concrete -- it' s  
not abstract. I've been around too long to ignore it, as it's all  
around us on the web, and it has been since 1994 if not earlier.


Compatibility concerns in the form of graceful degradation or  
progressive enhancement are not unmixed blessings. More coherent  
stacks from Microsoft, Adobe, and Sun can rightly claim to solve  
problems more cleanly and simply than the web. Of course these  
stacks have other problems, mainly from being single-sourced if not  
proprietary, but also from not progressing compatibly, and for other  
reasons I won't digress on.


But there's no point pretending the Web (ES, DOM, etc.) is an  
example of a well-designed toolkit for building user-facing  
distributed apps!


But we're not really free to discard compatibility. So I'm not that  
excited about the exciting opportunities we could have if we did. The  
Web is a duct tape design but it works. Dropping compatibility would  
kill one of its biggest advantages.


Systems that discard compatibility can also deliver an unusable Second  
System, especially when designed by committee. I would point to  
certain W3C specs that chose to break compatibility with existing  
practice. They are often not only undeployable but also not very  
compelling on their own terms.


I think compatibility constraints, even though they impose messy and  
illogical quirks, can also act as a healthy counterweight to flights  
of design fancy. Constraints make for good art.


Regards,
Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 27, 2009, at 12:35 PM, Robin Berjon wrote:


On Sep 27, 2009, at 00:36 , Cameron McCormack wrote:
Indeed, much of the custom [[Get]] etc. functionality can be turned  
into
ES5 meta-object stuff.  A pertinent question is then: should we  
change

Web IDL to specify an ES5 binding (and not ES3) at this point, given
that specs depending on it want to advance along the Rec track?


I would tend to be rather in disfavour of anything that might cause  
WebIDL to be delayed in any way. I also think that keeping the ES3  
binding is useful (in the short term at least) if only because it is  
familiar, which might point to building the ES5 one separately.


If at all possible I'd rather it went to LC ASAP, and if needed that  
new stuff be done in a branched document.


Based on the conversation so far, I expect Web IDL in roughly its  
current state would not survive Last Call.


 - Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

2009-09-27 Thread Brendan Eich


On Sep 27, 2009, at 4:15 PM, Maciej Stachowiak wrote:


On Sep 27, 2009, at 11:28 AM, Brendan Eich wrote:
But there's no point pretending the Web (ES, DOM, etc.) is an  
example of a well-designed toolkit for building user-facing  
distributed apps!


But we're not really free to discard compatibility. So I'm not that  
excited about the exciting opportunities we could have if we did.  
The Web is a duct tape design but it works. Dropping compatibility  
would kill one of its biggest advantages.


Sure. You didn't see me proposing dropping Web compatibility (suicide  
for browser vendors) -- rather, I'm talking about doing end-to-end  
design as we go, and meeting in the middle.


Too many short hops via a standard body incurs high costs in the spec  
process (some essential, some not) while tending to enshrine mistakes  
over time due to compatibility. Whereas taking big hops risks mission  
creep, or mission cliff-dive into second-system death-beach ;-), or  
even the old mistake of targeting a market foreseen five years out  
that never arrives (the real world zigged instead of zagging).


We've all seen these problems, I think, over our careers. And it's not  
as if the proprietary languages and stacks can break compatibility  
excessively (search for Visual Fred). But they can and do provide  
new and more coherent API-sets that help deprecate old ones.


To avoid proprietary stack examples, consider Python's from __future__  
import mechanism:


http://www.python.org/dev/peps/pep-0236/

This precedent is attractive if one can push out new versions of the  
language implementation, with carrots to induce people to upgrade, as  
well as the stick of unsupported ancient versions. It helps that C- 
Python is source-as-spec, but let's say that is a non-issue with good- 
enough ES specs.


The carrots instead of sticks idea is more critical from what I have  
seen, for Python and for JavaScript -- we can't get people to stop  
doing what worked if there's no new and better way (the recent  
arguments.callee in strict mode thread highlighted this point).


Of course, the web is too big to try to get away with deprecation/ 
obsolescence cycles on any predictable near-term release schedule.  
Never mind coordination among browser vendors on their next versions  
-- IE6 is still Out There.


But perhaps once past IE6, though, with modern browsers auto-updating,  
we'll see the downrev implementations go away faster. There's a  
chance, anyway, from what I see of IE8 replacing IE7, and of course  
faster updating for other, fresher browsers ;-).


If we do see a world where browser version uptake is faster, and the  
downrev problem shrinks or becomes more tractable somehow, then we  
will want shinier duct tape without bits of lint and trash stuck to  
the edges of the tape roll, over time. Every compatibility constraint  
costs non-linearly when refracted through the whole-language design  
process.


So part of ECMAScript Harmony is not just ES6, a prematurely- 
triaged, shortest-path evolutionary jump, but longer-term end to end  
design that ultimately puts the TC39 committee out of the language- 
extension business by empowering developers to bootstrap new language  
versions by themselves.



Systems that discard compatibility can also deliver an unusable  
Second System, especially when designed by committee. I would point  
to certain W3C specs that chose to break compatibility with existing  
practice. They are often not only undeployable but also not very  
compelling on their own terms.


Agreed.


I think compatibility constraints, even though they impose messy and  
illogical quirks, can also act as a healthy counterweight to flights  
of design fancy. Constraints make for good art.


We seem to have some unnecessary constraints, which are bad for art  
and science. Let's try to get rid of the foo(i) for foo[i] or  
foo.item[i] non-mandatory compatibility cruft and see how that goes.


/be

RE: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

2009-09-26 Thread Allen Wirfs-Brock

-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Yehuda Katz

Another way to put my earlier concern is: It's impossible to write a
conforming JS engine that browsers will want to use by only following
the ES spec - since there's additional, un-speced, behavior that isn't
in ES that is necessary in order to construct a browser's DOM.

Consider the following scenario: I write an ECMAScript engine that is
significantly faster than any existing engine by simply following the
ECMAScript spec. A browser maker then wishes to use this engine. This
would be impossible without adding additional (hidden) features to the
engine to support the DOM. There is nothing in the ECMAScript spec
that requires the ability (at the very least) to add native extensions
with arbitrary behavior to the engine.

Is this a requirement ECMA is comfortable with?


No we are not.  This is exactly the heart of our concern. The WebIDL
ECMAScript binding is not simply a mapping of IDL interface onto
standard language features (such as is done for the Java binding).
While it has some of that it also defines an extended ECMAScrpt language
with new semantics. (and I understand this is mostly a reflection
of past (present?) practice of browser implementers).  Essentially,
the semantics of browser ECMAScript has been arbitrarily split into
two independently maintained standards. 

Language design is not primarily about designing individual isolated features.
The hard parts of language design involves the interactions among such
features and typically requires making design trade-offs and alteration to
ensure that all features compose coherently.

If the language specification responsibilities are arbitrarily broken into 
two uncoordinated activities then it is impossible for either to do
the global design that is necessary to have a complete and sound language and
specification.

TC39 has the language design expertise.  W3C has Web API design expertise.
If there are language design issues that must be addressed in order to fully
specify browser ECMAScript (and there are) then those issues need to be
addressed by TC39. Perhaps TC309 has been remiss in the past in addressing
these browser specific language design issues.  If so, it was probably for
historic political and competitive reasons that don't necessarily apply today.
That is what we want to fix.

Allen Wirfs-Brock
Microsoft

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

2009-09-26 Thread Yehuda Katz

On Fri, Sep 25, 2009 at 11:28 PM, Brendan Eich bren...@mozilla.com wrote:
 On Sep 25, 2009, at 11:20 PM, Yehuda Katz wrote:

 On Fri, Sep 25, 2009 at 11:15 PM, Brendan Eich bren...@mozilla.com
 wrote:

 On Sep 25, 2009, at 9:38 PM, Yehuda Katz wrote:

 Another way to put my earlier concern

 Sorry, what earlier concern? You are replying to my reply to Doug
 Schepers
 on a sub-thread where I didn't see a message from you.

 So confusing! So many messages!

 No, you just replied off-topic and rehashed an issue that we all agree needs
 fixing, seemingly as if I had implied that it wasn't an issue. Although the
 generous citations of my reply to Doug Schepers that you included of course
 implied nothing of the kind.

 Why did you do that?

I failed? There are about 100 messages on this topic that I'm reading
and trying to digest. There's a whole lot of history involved. In the
end, I can only speak for myself, and I can say that I'm personally
having a lot of trouble trying to piece things together by looking at
the specifications.


 [big snip]

 My point is that understanding the semantics of the language as
 implemented by browser vendors is not possible by reading the language
 spec. These is not some hypothetical extension, but a mandatory way
 that ECMAScript implemented for the web must behave.

 Well, duh.

 We seem to agree, perhaps vehemently :-/.

 One last time, for the record: it is a bug in ES specs that you can't follow
 th
 The whole point of bothering the HTML WG, public-webapps, and es-discuss
 about collaboration between Ecma and W3C folks has been to fill gaps between
 specs and reality. We had some false starts in my view (like trying to move
 ES WebIDL bindings to Ecma up front, or ever). But the issues laid out in
 Sam's original cross-post were exactly the gaps between ES specs, HTML5
 ones, and browser implementations. At last some of the gaps are filled in
 HTML5 but not in ways that can be injected directly into ES specs.

I'm actually being a bit more radical than you are (perhaps naïvely).
I am personally finding WebIDL to be a blocker to understanding.
That's because it's another spec that interacts with two other (fairly
complex) specs in unpredictable and context-sensitive ways.

 We should fix the ES specs, and make whatever changes follow to the HTML5
 specs. And maybe use WebIDL to constrain host objects. All this has been
 said on the thread already. Were you not reading the messages I was?

I think I saw that in the thread ;)

Like I said, my problem is that the interaction between the three
specs is making it nearly impossible for a casual reader to understand
what's going on. I strongly apologize for not being clearer about
that; I'm only starting to fully understand the source of my own
confusion.


 /be



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

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 25, 2009, at 11:32 PM, Brendan Eich wrote:


On Sep 25, 2009, at 11:28 PM, Brendan Eich wrote:


We seem to agree, perhaps vehemently :-/.

One last time, for the record: it is a bug in ES specs that you  
can't follow th


Sorry, rogue cut before send. it's a bug in ES specs that you can't  
follow them in order to implement a web-compatible JS engine.


Although some of web-compatible JS really does belong in W3C  
specs, not ES specs, it's clear ES1 pretending there is only one  
global object did no one any favors. Ditto for execution model and  
(ultimately) split windows, as Hixie pointed out in raising the  
conflict between HTML5 and ES1-3 (and now ES5).


Just wanted to reassure you, since you seemed to think otherwise,  
that no one views it as a feature that ES specs don't specify  
enough. HTML4 specs didn't either. We're getting there.


That's right. ES3, HTML4 and DOM Level 2 were all missing many things  
needed to implement Web-compatible behavior, as well as having  
requirements that were in some cases contrary to real-world  
compatibility. Writing a new browser engine based on those specs  
required multiple years of trial and error and reverse engineering  
after implementing the spec behavior. Take it from me - that's what we  
had to do to make WebKit (even building on the foundation of KHTML 
+KJS, which had already done some of the reverse engineering).


ES5, HTML5, Web IDL and some of the Web Apps specs (like  
XMLHttpRequest and DOM3 Events) are huge steps forward on this front.  
They don't solve every problem, but they are massive improvements in  
getting the Web platform correctly specified.


Regards,
Maciej

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination



On Sep 26, 2009, at 12:20 AM, David-Sarah Hopwood wrote:


Maciej Stachowiak wrote:

I think there are two possible perspectives on what constitutes
magnify[ing] the problem or widening the gap

A) Any new kind of requirement for implementations of object  
interfaces

that can't be implemented in pure ECMAScript expands the scope of the
problem.
B) Any new interface that isn't implementable in ECMAScript widens  
the

gap, even if it is for a reason that also applies to legacy


My view is firmly B, for the reasons given below.


My view is A. That's why I pointed to legacy interfaces - if the
construct can't go away from APIs in general, but we wish to  
implement

all APIs in ECMAScript, then ultimately it is ECMAScript that must
change, so using the same construct again doesn't create a new  
problem.


Yes it does:

- In many cases, APIs are partially redundant, in such a way that
  developers can choose to avoid some of the legacy interfaces without
  any significant loss of functionality. By doing so, they can avoid  
the
  problems caused by clashes between names defined in HTML, and  
names of

  ECMAScript methods. If new APIs also use catch-alls, they are less
  likely to be able to do this.

- The potential name clashes created by catch-alls also create a  
forward

  compatibility issue: if a new method is added to an interface, it
  might clash with names used in existing HTML content. In the case of
  legacy interfaces, it is less likely that we want to add new methods
  to them, and so this forward compatibility issue is less of a  
problem.


It seems like these first two reasons are pragmatic concerns about  
fully general property access catchalls, which are independent of  
anyone's desire to implement the interfaces in ECMAScript. These  
arguments also do not apply to other kinds of extended host object  
behavior, such as array-like index access, or the fact that  
document.all compares as boolean false.




- Implementors of subsets in which the DOM APIs are tamed for  
security
  reasons can choose not to implement some APIs that are problematic  
for
  them to support; but if new APIs are equally problematic, they  
will be

  unable to provide access to that functionality.


I think trying to tame the DOM APIs is a quixotic task anyway.

A common example cited is to embedding a widget via direct DOM  
embedding in a safe way. Presumably safe means you have toprevent  
the widget reading or modifying the DOM outside its subtree, prevent  
executing JS outside the sandbox, and prevent displaying content  
outside its designated bounds. To achieve this, you have to restrict  
the behavior of nearly every single DOM method, often in extremely  
complicated ways that amount to reimplementing major portions of  
browser functionality.


Consider for example the setAttribute method on the Element interface.  
You have to intercept attempts to set the style attribute, parse the  
CSS being set, and make sure that the widget is not trying to use CSS  
positioning or overflow to display outside its bounds. You can't just  
forbid CSS styling entirely, because that makes it impossible to make  
a decent-looking widget. previousSibling, nextSibling, ownerDocument  
all have to be prevented from going outside the tree. Any method to  
find particular elements has to be essentially rewritten to prevent  
going outside the tree, even something as basic as  
document.getElementById(). Attempts to set the id attribute have to  
be intercepted and the id has to be silently rewritten if it clashes  
with an id used in the embedding content, so that getElementById()  
calls by the embedder aren't tricked into manipulating the embedded  
content. Timers have to be reimplemented to make sure their JavaScript  
is executed in the sandbox. Setting a href to a javascript: URL  
has to be prevented, unless you completely override the navigation  
behavior of a elements. Creating plugins or Java applets has to be  
prevented, since they can't be made to follow the security  
constraints. document.write() and innerHTML have to be intercepted,  
and the contents have to be parsed as HTML to prevent any forbidden  
constructs in the markup. This is just scratching the surface, and  
we've already found that CSS parsing, HTML parsing and DOM query  
methods will have to be reimplemented (from scratch, yet in a way that  
matches what the browser does) to make this work. Note that none of  
this complexity is imposed by exotic host object behaviors, it's all  
intrinsic to the way the Web platform works. Even considering the case  
of taming LocalStorage, the catchall behavior is the least of your  
worries.


The best way to serve this kind of use case is either an iframe with  
postMessage, or inventing an entirely new API for embedded content  
that doesn't even try to look anything like the DOM, and just exposes  
a carefully selected set of capabilities. I don't think our time is  
well spent trying to

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 26, 2009, at 8:28 AM, Allen Wirfs-Brock wrote:



No we are not.  This is exactly the heart of our concern. The WebIDL
ECMAScript binding is not simply a mapping of IDL interface onto
standard language features (such as is done for the Java binding).
While it has some of that it also defines an extended ECMAScrpt  
language

with new semantics. (and I understand this is mostly a reflection
of past (present?) practice of browser implementers).  Essentially,
the semantics of browser ECMAScript has been arbitrarily split into
two independently maintained standards.


Is there any concrete concern on this front other than property access  
catchalls?


Regards,
Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

2009-09-26 Thread Mark S. Miller

On Sat, Sep 26, 2009 at 3:36 PM, Cameron McCormack c...@mcc.id.au wrote:
 Indeed, much of the custom [[Get]] etc. functionality can be turned into
 ES5 meta-object stuff.  A pertinent question is then: should we change
 Web IDL to specify an ES5 binding (and not ES3) at this point, given
 that specs depending on it want to advance along the Rec track?

Since ES5 will be officially done well ahead of HTML5, I don't see why
not. But I do not know what your Rec track constraints imply.


-- 
Cheers,
--MarkM

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

2009-09-26 Thread Mark S. Miller

On Sat, Sep 26, 2009 at 3:48 PM, Oliver Hunt oli...@apple.com wrote:
 I would avoid depending on ES5 until there are multiple realworld
 implementations at least, especially because
 the interaction between the es5 meta-object functionality and host objects
 is less than clear at present.

Hi Oliver, it is precisely the need to clarify this interaction, as
you pointed out in some of your previous posts to es-discuss, that got
us to focus on the need for greater coordination at the last
EcmaScript meeting. Since, as you say, this interaction is currently
unclear, isn't this exactly the kind of problem our standards bodies
should be trying to resolve?

-- 
Cheers,
--MarkM

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 26, 2009, at 3:13 PM, Allen Wirfs-Brock wrote:





From: Maciej Stachowiak [mailto:m...@apple.com]

On Sep 26, 2009, at 8:28 AM, Allen Wirfs-Brock wrote:

...

 Essentially,
the semantics of browser ECMAScript has been arbitrarily split  
into

two independently maintained standards.


Is there any concrete concern on this front other than property  
access catchalls?


Every place the WebIDL ECMAScript binding overrides an ECMAScript  
specification
internal method is a concern as these are special case extensions to  
the ECMAScript
semantics.  As language designers we need to understand if these  
special cases are
exemplars of general deficiencies in the language that should be  
addressed.


We have definitely identified catchall property access as such an  
area. Are there in fact any others? It's a lot more interesting to  
look at specific examples than to expound on the general principles.  
See below where I did some study to find other missing capabilities.


In particular  now that ES5 is finished, WebIDL has a richer  
language to bind to then
it had with ES3.  We need a WebIDL binding that maximizes use of ES5  
capabilities rather
than inventing non-standard (from an ES perspective) language  
extensions.


Updating WebIDL to use ES5 concepts would definitely be worthwhile. At  
the time Web IDL was started (early 2007 I think) this wasn't a  
practical option, but it is now. In particular, interfaces that don't  
have any unusual behavior could be defined as having getters and  
setters, and should not need to override internal properties at all.  
This would better highlight the capabilities that are needed to  
implement the Web platform, but which can't be expressed in the  
property descriptor formalism.


I expect there are relatiively few such capabilities, and little  
interest in depending on new ones, and therefore we do not really have  
a general ongoing problem of language design.


From a quick scan of WebIDL, I see the following:

1) Catchall getters, putters, deleters, definer.
   - Variants that can make the catchall check happen either before  
or after normal property lookup.

   - General string-based name access and index-only versions.
   - Note: I think catchall deleters are used only by Web Storage and  
not by other new or legacy interfaces.
2) Ability to support being called (via [[Call]]) without being a  
Function.
3) Ability to support being invoked a constructor (via [[Construct]])  
without being a Function.
4) Ability to support instanceof checking (via [[HasInstance]])  
without being a constructor (so myElement instanceof HTMLElement works).
5) Ability to have [[Construct]] do something different than [[Call]]  
instead of treating it as a [[Call]] with a freshly allocated Object  
passed as this.


Tentatively, I think all other semantics of Web IDL interfaces can be  
implemented in pure ES5.


Regards,
Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 26, 2009, at 3:58 PM, Cameron McCormack wrote:


Cameron McCormack:
Indeed, much of the custom [[Get]] etc. functionality can be  
turned into
ES5 meta-object stuff.  A pertinent question is then: should we  
change

Web IDL to specify an ES5 binding (and not ES3) at this point, given
that specs depending on it want to advance along the Rec track?


Mark S. Miller:
Since ES5 will be officially done well ahead of HTML5, I don't see  
why

not. But I do not know what your Rec track constraints imply.


For example, Selectors API is at Last Call and will soon be in  
Candidate

Recommendation.  I don’t think it can progress further than that until
its dependencies move forward.


Selectors can't progress to PR/REC until Web IDL is in at least CR  
state (only one difference in maturity level is allowed for  
dependencies). I think Web IDL can enter CR with ES5 as is, but it  
will be considered final as soon as it is published, which is likely  
to be before Web IDL is ready for Last Call. ECMA process does not  
have any states between the equivalent of W3C Working Draft and W3C  
REC (as far as I know). So I don't think this would create any  
problems for Selectors advancing, other than the time to do the rewrite.


On the substantive issue: I do think it would be good to convert Web  
IDL from ES3 formalisms to ES5 formalisms. While Oliver is right that  
ES5 has not yet been proven by interoperable implementations, and that  
some of its methods as defined have a hard time with host objects, I  
believe that the basic designs of ES5 property descriptors and ES5  
getters/setters are sound.


Regards,
Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 26, 2009, at 4:41 PM, Oliver Hunt wrote:

The specific problem is that host objects cannot necessarily match  
the semantics of ES5, and for that reason the interaction of host  
objects with the ES5 semantics is unclear.


I think mapping Web IDL behavior to ES5 property descriptors would  
help make this interaction more clear.


 There are additional concerns -- various es5 features expose the  
underlying implementation mechanisms of the binding -- for instance  
using get or set properties on a dom binding would require  
getOwnPropertyDescriptor to expose that implementation detail.


getOwnPropertyDescriptor risks leaking implementation details (or at  
least implementation differences) in any case. The options for Web IDL  
are:


1) Leave the results of getOwnPropertyDescriptor completely  
implementation-defined, so different implementations may return  
different values.
2) Require getOwnPropertyDescriptor to return specific results that  
expose host object properties as something other than getters or  
setters.
3) Require getOwnPropertyDescriptor to return specific results that  
expose host object properties as getters/setters.


I reluctantly conclude that #3 is best. #1 leaves behavior  
unspecified, this needlessly creates the potential for interop  
problems. #2 conflicts with the way some implementations implement  
their DOM bindings (e.g. Gecko), meaning extra work for them, and is  
outright unimplementable in pure ECMAScript. #3 conflicts with the way  
some implementations implement their DOM bindings (e.g. WebKit) and  
would mean extra work for them.


#3 seems like it has the weakest disadvantages, even though it means  
extra work for us.


However, if we want to allow implementation variance (i.e. policy #1),  
we could still use ES5 getters and setters as the formal model, but  
say that host objects implementations may override [[GetOwnProperty]]  
to give implementation-defined results for host attributes. This would  
change Web IDL from saying that host object implementations MUST  
override internal methods to saying they MAY.


Regard,
Maciej

RE: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

2009-09-26 Thread Allen Wirfs-Brock



-Original Message-
From: Maciej Stachowiak [mailto:m...@apple.com]

I expect there are relatiively few such capabilities, and little
interest in depending on new ones, and therefore we do not really have
a general ongoing problem of language design.

 
We have an ongoing problem of language design in that all new language
features must integrate with existing features. Combinatory feature
interactions is one of the larger challenges of language design.

 From a quick scan of WebIDL, I see the following:

1) Catchall getters, putters, deleters, definer.
- Variants that can make the catchall check happen either before
or after normal property lookup.
- General string-based name access and index-only versions.
No comment, I need to come up to speed on the detailed semantic requirements

- Note: I think catchall deleters are used only by Web Storage and
not by other new or legacy interfaces.

Seems like a strong reason to change to the proposed API to eliminate the need 
for
a new ES language extension.

2) Ability to support being called (via [[Call]]) without being a
Function.

Not an issue with the core ES5 semantics.  Most ES3/5 section 15 functions have 
this
characteristic. As long as such WebIDL objects are defined similarly to the 
built-in
function they too can have this characteristic. It may well be useful to 
introduce a
mechanism defining such pure functions in the language but it probably isn't 
necessary
to proceed with the WebIDL binding.  The important thing to try to avoid is 
specify
a custom [[Call]]


3) Ability to support being invoked a constructor (via [[Construct]])
without being a Function.

Essentially same as 2 although the standard [[Construct]] requires a [[Call]] 
so this
may need some more thought.

4) Ability to support instanceof checking (via [[HasInstance]])
without being a constructor (so myElement instanceof HTMLElement works).

Possibly the specification of the instanceof operator needs to be made 
extensible

5) Ability to have [[Construct]] do something different than [[Call]]
instead of treating it as a [[Call]] with a freshly allocated Object
passed as this.

Similar to 4 regarding extensibility.  At least one recent harmony strawman 
proposal is
moving in a direction that may be relevent to 4 and 5.
See http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_constructors
 



Tentatively, I think all other semantics of Web IDL interfaces can be
implemented in pure ES5.

Regards,
Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 26, 2009, at 5:20 PM, Allen Wirfs-Brock wrote:





-Original Message-
From: Maciej Stachowiak [mailto:m...@apple.com]

I expect there are relatiively few such capabilities, and little
interest in depending on new ones, and therefore we do not really  
have

a general ongoing problem of language design.



We have an ongoing problem of language design in that all new language
features must integrate with existing features. Combinatory feature
interactions is one of the larger challenges of language design.


From a quick scan of WebIDL, I see the following:

1) Catchall getters, putters, deleters, definer.
  - Variants that can make the catchall check happen either before
or after normal property lookup.
  - General string-based name access and index-only versions.
No comment, I need to come up to speed on the detailed semantic  
requirements


They are pretty similar to the way Array overrides  
[[DefineOwnProperty]] or the way String defines





  - Note: I think catchall deleters are used only by Web Storage and
not by other new or legacy interfaces.


Seems like a strong reason to change to the proposed API to  
eliminate the need for

a new ES language extension.


I previously argued for removing the need for catchall deleters from  
the Web Storage API (since nothing else requires , but other browser  
vendors (including  Mozilla) were happy with it, and I think now  
everyone (including I believe Microsoft) has implemented the spec  
behavior. See prior discussion thread here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014851.html 
.  At this point, since we have multiple deployed implementations of  
Web Storage, we'd have to investigate whether it's safe to remove this  
behavior without breaking content.





2) Ability to support being called (via [[Call]]) without being a
Function.


Not an issue with the core ES5 semantics.  Most ES3/5 section 15  
functions have this
characteristic. As long as such WebIDL objects are defined similarly  
to the built-in
function they too can have this characteristic. It may well be  
useful to introduce a
mechanism defining such pure functions in the language but it  
probably isn't necessary
to proceed with the WebIDL binding.  The important thing to try to  
avoid is specify

a custom [[Call]]


I tend to agree that this behavior (and the next 3) are not  
philosophically problematic, even though they cannot today be  
implemented in pure ECMAScript.






3) Ability to support being invoked a constructor (via [[Construct]])
without being a Function.


Essentially same as 2 although the standard [[Construct]] requires a  
[[Call]] so this

may need some more thought.


4) Ability to support instanceof checking (via [[HasInstance]])
without being a constructor (so myElement instanceof HTMLElement  
works).


Possibly the specification of the instanceof operator needs to be  
made extensible



5) Ability to have [[Construct]] do something different than [[Call]]
instead of treating it as a [[Call]] with a freshly allocated Object
passed as this.


Similar to 4 regarding extensibility.  At least one recent harmony  
strawman proposal is

moving in a direction that may be relevent to 4 and 5.
See http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_constructors


Interesting. This may provide a way to implement some of these  
behaviors in pure ECMAScript. The current proposal does allow  
[[Construct]] without [[Call]], but not [[Call]] and [[Construct]]  
that both exist but with different behavior.


Regards,
Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

2009-09-26 Thread Cameron McCormack

Maciej Stachowiak:
 - Note: I think catchall deleters are used only by Web Storage and
 not by other new or legacy interfaces.

Allen Wirfs-Brock:
 Seems like a strong reason to change to the proposed API to eliminate the 
 need for
 a new ES language extension.

When writing Web IDL originally, it didn’t seem at all to me that host
objects were a disapproved of mechanism to get functionality that can’t
be implemented with native objects.  So having a [[Delete]] on a host
object be different from the Object [[Delete]] or the Array one seemed
fine to me.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Sam Ruby

On Fri, Sep 25, 2009 at 5:57 AM, Anne van Kesteren ann...@opera.com wrote:
 On Fri, 25 Sep 2009 11:38:08 +0200, Sam Ruby ru...@intertwingly.net wrote:

 Meanwhile, what we need is concrete bug reports of specific instances
 where the existing WebIDL description of key interfaces is done in a way
 that precludes a pure ECMAScript implementation of the function.

 Is there even agreement that is a goal?

This was expressed by ECMA TC39 as a goal.  There is no agreement as
of yet to this goal by the HTML WG.

I'm simply suggesting that they way forward at this time is via
specifics, ideally in the form of bug reports.

 I personally think the catch-all pattern which Brendan mentioned is quite
 convenient and I do not think it would make sense to suddenly stop using it.
 Also, the idea of removing the feature from Web IDL so that future
 specifications cannot use it is something I disagree with since having it in
 Web IDL simplifies writing specifications for the (legacy) platform and
 removes room for error.

 Having Web IDL is a huge help since it clarifies how a bunch of things map
 to ECMAScript. E.g. how the XMLHttpRequest constructor object is exposed,
 how you can prototype XMLHttpRequest, that objects implementing
 XMLHttpRequest also have all the members from EventTarget, etc. I'm fine
 with fiddling with the details, but rewriting everything from scratch seems
 like a non-starter. Especially when there is not even a proposal on the
 table.

I agree that either getting a proposal on the table or bug reports is
the right next step.  I further agree that removal of function and/or
a wholesale switch away from Web IDL is likely to be a non-starter.

 Anne van Kesteren
 http://annevankesteren.nl/

- Sam Ruby

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Maciej Stachowiak



On Sep 25, 2009, at 2:38 AM, Sam Ruby wrote:


Maciej Stachowiak wrote:

On Sep 24, 2009, at 5:44 PM, Yehuda Katz wrote:
That sounds reasonable. There are really two issues. One is that  
there are parts of WebIDL that are unused. Another is that the  
parts of the spec themselves are fairly arcane and very  
implementor-specific. Consider:


interface UndoManager {
 readonly attribute unsigned long length;
 getter any item(in unsigned long index);
 readonly attribute unsigned long position;
 unsigned long add(in any data, in DOMString title);
 void remove(in unsigned long index);
 void clearUndo();
 void clearRedo();
};

I almost forget that I'm looking at something most widely  
implemented in a dynamic language when I look at that. Since this  
is most likely to be implemented in terms of ECMAScript, why not  
provide an ECMAScript reference implementation?
These methods do things that can't actually be implemented in pure  
ECMAScript, since they need to tie into the browser implementation  
and system APIs. So a reference implementation in ECMAScript is not  
possible.


I'll accept that it is a true statement that in an pure ECMAScript  
implementation of these interfaces in Safari on Mac OSX such  
wouldn't be possible.


Alternate perspective, one that I believe more closely matches the  
view of TC39: one could image an operating system and browser  
implemented in either in ECMAScript or in a secure subset thereof.   
In such an environment it would be highly unfortunate if the the  
WebIDL for something as important as HTML5 and WebApps were written  
in such a way as to preclude the creation of a conforming ECMAScript  
implementation.


Unfortunately, this is the case. But in many cases this is due to  
legacy compatibility requirements combined with certain features that  
do not (yet) exist in ECMAScript. See below.


At this point, I'm not personally interested in discussions as to  
whether WebIDL is or is not the right way forward.  Anybody who  
wishes to invest their time in producing more useful documentation  
and/or reference implementations is not only welcome to do so, they  
are positively encouraged to do so.


Meanwhile, what we need is concrete bug reports of specific  
instances where the existing WebIDL description of key interfaces is  
done in a way that precludes a pure ECMAScript implementation of the  
function.


I think the main cases where this is true are interfaces with catchall  
getters and setters, or interfaces that are callable (but also have  
various methods and properties and are not Functions). I believe most  
of these are due to legacy compatibility constraints. Thus, ECMAScript  
will need to change to be able to plausibly implement equivalent  
interfaces. A change to Web IDL to match current ECMAScript  
capabilities would mean it can't actually describe the APIs that exist  
in browsers today, and such a description of these APIs would be,  
essentially, false. This seems like putting the cart before the horse.


Let me give a concrete example, the HTMLCollection interface from  
HTML5: http://dev.w3.org/html5/spec/Overview.html#htmlcollection-0.


This interface is defined to have getter properties which imply  
catchall getters for index and non-index properties. This is  
implemented by all existing browsers and is needed for compatibility  
with a lot of Web content. It is also required by DOM Level 2 HTML's  
ECMAScript bindings: http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html 
. The fact that ECMAScript 5 can't implement an interface that  
behaves like this is an ECMAScript issue, not an HTML issue, in my  
opinion, and one that will hopefully be fixed in future editions.


Now, it may be that some non-legacy APIs require special host object  
behavior that wouldn't otherwise be implicated by legacy APIs. If  
anyone identifies such APIs, then we can look at fixing them.


Regards,
Maciej

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Mark S. Miller

On Thu, Sep 24, 2009 at 7:55 AM, Maciej Stachowiak m...@apple.com wrote:
 On Sep 24, 2009, at 5:36 AM, Sam Ruby wrote:
 The current WebIDL binding to ECMAScript is based on ES3... this needs to
 more closely track to the evolution of ES, in particular it needs to be
 updated to ES5 w.r.t the Meta Object Protocol.  In the process, we should
 discuss whether this work continues in the W3C, is done as a joint effort
 with ECMA, or moves to ECMA entirely.

 It seems like this is a Web IDL issue. I don't see any reason for Web IDL to
 move to ECMA. It is a nominally language-independent formalism that's being
 picked up by many W3C specs, and which happens to have ECMAScript as one of
 the target languages. Much of it is defined by Web compatibility constraints
 which would be outside the core expertise of TC39. Probably the best thing
 to do is to provide detailed technical review of Web IDL via the W3C
 process.


To clarify, AFAIK, no one on the EcmaScript committee is proposing
that WebIDL itself be moved to ECMA, but rather the WebIDL-EcmaScript
language binding.

To answer a concern brought up later in the thread, neither is anyone
of the EcmaScript committee proposing that anything be removed from
WebIDL, or that the definition of these binding change in ways that
create incompatibilities with current pre-HTML5 browser APIs. Whatever
problems are created by legacy uses of WebIDL, we all accept that we
have to live with these problems for the foreseeable future
(essentially forever). Rather, the concern is that new APIs defined
using WebIDL should not magnify these problems.

These are two separate points. The second point constitutes only
advice from ECMA to W3C, and demonstrates a need for dialog. The
EcmaScript committee has been evolving EcmaScript with one of our
goals being to close the gap between what DOM objects can do and what
EcmaScript objects can emulate. While we were busy trying to close the
gap, html5 was busy widening it. This is largely our fault by not
having communicated this goal. We seek dialog repair this mistake and
to avoid repeating it.

The first point may be more contentious, but I think is also clearer.
Say Joe creates JoeLang and creates a browser plugin or something that
gives JoeLang access to the DOM. Joe should not expect W3C to define
the WebIDL-JoeLang binding. As you say, WebIDL is a nominally
language-independent formalism. As such, it should serve precisely as
the abstraction mechanism needed to allow work on host environment
APIs like browsers to proceed loosely coupled to the design on the
languages that run in such host environments.

Catchalls are an excellent example issue for both points, in opposite
directions. Regarding the second point, yes, we believe that new host
APIs should generally seek to avoid requiring catchalls, since new
native (i.e., written in EcmaScript) APIs must, and since there are
many benefits to being able to emulate more host APIs more easily in
EcmaScript (such as the ability to interpose intermediary wrappers).
Regarding the first point, since legacy host APIs do require
catchalls, EcmaScript must eventually too. The definition of how
WebIDL-expressed catchalls map to future EcmaScript should co-evolve
with the changes to EcmaScript needed to support this mapping.



 - - -

 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

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Anne van Kesteren

On Fri, 25 Sep 2009 16:26:21 +0200, Mark S. Miller erig...@google.com  
wrote:

To clarify, AFAIK, no one on the EcmaScript committee is proposing
that WebIDL itself be moved to ECMA, but rather the WebIDL-EcmaScript
language binding.


That is the most essential part of Web IDL for most consumers though.  
Maybe one should hope for the best, but I think the WebApps WG is a much  
better place in terms of transparency and I do not see any reason why the  
ECMAScript committee cannot simply provide public feedback just like  
everyone else. Even if a person cannot be on the WG for whatever reason he  
is still allowed to join the mailing list and participate in discussion.


I think it is better in terms of transparency because all the decisions  
are made on a public list, the draft is in version control (and written in  
HTML), and it is very easy for people to participate by just emailing  
public-webapps@w3.org or chatting with the editor on IRC.


(Admittedly I also have my reservations on how certain decisions regarding  
ECMAScript have been made running contrary to deployed implementations.  
E.g. with regards to the de facto getters and setters standard. I think  
something like that would be much less likely to happen at the W3C though  
in the end of course it depends on who is involved.)




To answer a concern brought up later in the thread, neither is anyone
of the EcmaScript committee proposing that anything be removed from
WebIDL, or that the definition of these binding change in ways that
create incompatibilities with current pre-HTML5 browser APIs. Whatever
problems are created by legacy uses of WebIDL, we all accept that we
have to live with these problems for the foreseeable future
(essentially forever). Rather, the concern is that new APIs defined
using WebIDL should not magnify these problems.


I'm not sure I agree they are problems, though it might help if some  
explicit examples were given.




These are two separate points. The second point constitutes only
advice from ECMA to W3C, and demonstrates a need for dialog. The
EcmaScript committee has been evolving EcmaScript with one of our
goals being to close the gap between what DOM objects can do and what
EcmaScript objects can emulate. While we were busy trying to close the
gap, html5 was busy widening it. This is largely our fault by not
having communicated this goal. We seek dialog repair this mistake and
to avoid repeating it.


Where exactly was the gap widened?



The first point may be more contentious, but I think is also clearer.
Say Joe creates JoeLang and creates a browser plugin or something that
gives JoeLang access to the DOM. Joe should not expect W3C to define
the WebIDL-JoeLang binding. As you say, WebIDL is a nominally
language-independent formalism. As such, it should serve precisely as
the abstraction mechanism needed to allow work on host environment
APIs like browsers to proceed loosely coupled to the design on the
languages that run in such host environments.


While N languages might not be possible doing it for the 2 we care about  
does make sense I think. The specific language details also influence the  
design of Web IDL. And especially in case of ECMAScript makes reviewing  
the draft much easier because you can easily check if it matches what  
contemporary implementations do.




Catchalls are an excellent example issue for both points, in opposite
directions. Regarding the second point, yes, we believe that new host
APIs should generally seek to avoid requiring catchalls, since new
native (i.e., written in EcmaScript) APIs must, and since there are
many benefits to being able to emulate more host APIs more easily in
EcmaScript (such as the ability to interpose intermediary wrappers).
Regarding the first point, since legacy host APIs do require
catchalls, EcmaScript must eventually too. The definition of how
WebIDL-expressed catchalls map to future EcmaScript should co-evolve
with the changes to EcmaScript needed to support this mapping.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Robin Berjon


Hi Mark,

On Sep 25, 2009, at 16:26 , Mark S. Miller wrote:

To clarify, AFAIK, no one on the EcmaScript committee is proposing
that WebIDL itself be moved to ECMA, but rather the WebIDL-EcmaScript
language binding.


I understand the rationale you have to motivate this proposal, I do  
have a level of sympathy for it, and I certainly believe that we  
should do as much as possible to pool our expertise across what I  
agree is an artificial divide. Yet such a move would seem to me to  
have more drawbacks than advantages.


One is that defining WebIDL at the same time as the ES binding has the  
huge advantage of keeping it on mission. I would be concerned that  
removing the ES bindings would potentially open the door to some level  
of feature creep, or would risk opening cracks in WebIDL's intended  
adherence to reality.


Another one is the virtuous feedback loop that I believe would work  
better if the two are kept close-by. New features in ES5 should be  
reflected perhaps not only in the binding, but in the core of what  
WebIDL can do.


Additionally there is co-ordination with all the other WGs that have a  
stake in this. HTML, WebApps, SVG, DAP, and many others need not only  
to track WebIDL because it is the formalism but also the ES binding  
because we all need a concrete binding, because ES is usually the only  
one that really matters (it certainly is core to our shared vision of  
the Web) and the one that we use in building test suites. That would  
be quite a hassle for a fair number of people.


That being said I fully understand that it is conversely true for TC39  
participants, and therefore I'd like to find a solution that keeps the  
work in one place while making everyone happy (or at least, not overly  
disgruntled).


WebIDL is defined almost entirely in email discussion, there haven't  
been calls or meetings about it in a long while, and I don't see any  
in the close future. WebApps will likely touch on it during the F2F  
but that would be short (it might in fact be non-existent given that  
it will be discussed jointly with TC39 anyway). So unless there is  
consensus in TC39 that email discussion is not good enough to move  
this forward, I believe that all we need is a list. That's why I liked  
Doug's idea of a public-...@w3.org mailing list for this very purpose.  
It would be low traffic, people who only care about WebIDL would only  
get that, discussion would be publicly archived, and everyone would be  
welcome. We can easily complement that with an IRC channel, and  
perhaps other supporting services.


I don't care a rat's arse where that list is hosted, and I suspect  
others here feel the same — so long as we don't split the work, and  
that all interested parties can help. I like W3C mailing list and  
their archiving system because they are more sanely configured than  
most, but I can live with anything else. If ECMA wishes to create the  
same list I'll happily join, or we can host it elsewhere still.


Would that not work for TC39? If not, can you detail the reasons why  
so that we can try to figure out a solution?


I guess that we could go the legalese way and start investigating the  
idea of a MoU between W3C and ECMA on this, but that would take time  
and probably be rather heavy — with little obvious technological  
advantage. I'd rather not go there.


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

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination


Three distinct topics are being mixed up here:

1. Whether to use WebIDL or some unproposed alternative.

2. Whether to use catchall patterns in new WebIDL-defined interfaces.

3. Whether the JS WebIDL bindings should be standardized by Ecma or W3C.

The straw man (0. Whether to remove catchall patterns from existing  
WebIDL interfaces required for backward compatibility) is nonsense and  
I'm going to ignore it from here on.


My positions are:

1. WebIDL, the bird in the hand (I agree with Sam: go invent something  
better, come back when you're done).


2. Don't keep perpetuating catchall patterns, they are confusing for  
developers and costly for implementors and static analysis tools, even  
if implementable in some future ES edition.


3. Don't care.

I differ from Mark on 3, but that's ok. What is not ok is to waste a  
lot of time arguing from divergent premises that need to be unpacked  
or else let alone for now, when we could be collaborating on concrete  
issues such as split windows, execution model, catchall policing, etc.


Mark's Joe with his JoeLang bindings for WebIDL vs. Anne's point about  
the primacy of JavaScript bindings for WebIDL-defined interfaces is  
not going to lead to rapid agreement on putting the ES WebIDL bindings  
in Ecma vs. leaving them in W3C. It's a rathole, IMHO.


Both points of view have merit, but precedent and possession matter  
too, and Ecma can't plausibly fork or steal the binding spec. We're  
trying to collaborate, so let's get on with that hard work instead of  
trying to assail one another with principles that can't encompass the  
whole picture.


Hope this helps,

/be

RE: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Allen Wirfs-Brock

+1

-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Brendan Eich
Sent: Friday, September 25, 2009 9:56 AM
To: Anne van Kesteren
Cc: public-webapps@w3.org; HTML WG; es-discuss
Subject: Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

Three distinct topics are being mixed up here:

1. Whether to use WebIDL or some unproposed alternative.

2. Whether to use catchall patterns in new WebIDL-defined interfaces.

3. Whether the JS WebIDL bindings should be standardized by Ecma or W3C.

The straw man (0. Whether to remove catchall patterns from existing
WebIDL interfaces required for backward compatibility) is nonsense and
I'm going to ignore it from here on.

My positions are:

1. WebIDL, the bird in the hand (I agree with Sam: go invent something
better, come back when you're done).

2. Don't keep perpetuating catchall patterns, they are confusing for
developers and costly for implementors and static analysis tools, even
if implementable in some future ES edition.

3. Don't care.

I differ from Mark on 3, but that's ok. What is not ok is to waste a
lot of time arguing from divergent premises that need to be unpacked
or else let alone for now, when we could be collaborating on concrete
issues such as split windows, execution model, catchall policing, etc.

Mark's Joe with his JoeLang bindings for WebIDL vs. Anne's point about
the primacy of JavaScript bindings for WebIDL-defined interfaces is
not going to lead to rapid agreement on putting the ES WebIDL bindings
in Ecma vs. leaving them in W3C. It's a rathole, IMHO.

Both points of view have merit, but precedent and possession matter
too, and Ecma can't plausibly fork or steal the binding spec. We're
trying to collaborate, so let's get on with that hard work instead of
trying to assail one another with principles that can't encompass the
whole picture.

Hope this helps,

/be
___
es-discuss mailing list
es-disc...@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Jonas Sicking

On Fri, Sep 25, 2009 at 9:56 AM, Brendan Eich bren...@mozilla.com wrote:
 Three distinct topics are being mixed up here:

 1. Whether to use WebIDL or some unproposed alternative.

 2. Whether to use catchall patterns in new WebIDL-defined interfaces.

 3. Whether the JS WebIDL bindings should be standardized by Ecma or W3C.

 The straw man (0. Whether to remove catchall patterns from existing WebIDL
 interfaces required for backward compatibility) is nonsense and I'm going to
 ignore it from here on.

 My positions are:

 1. WebIDL, the bird in the hand (I agree with Sam: go invent something
 better, come back when you're done).

 2. Don't keep perpetuating catchall patterns, they are confusing for
 developers and costly for implementors and static analysis tools, even if
 implementable in some future ES edition.

 3. Don't care.

Regarding 2. How do you feel about index accessors? I.e. for example you can do:

myNode.children[5]

which returns the same as

myNode.children.item(5)

This seems equally impossible to implement in ECMAScript, but is
something that I think is helpful to authors so not something that I
want to stop adding to new interfaces.

/ Jonas

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination


On Sep 25, 2009, at 12:08 PM, Jonas Sicking wrote:

On Fri, Sep 25, 2009 at 9:56 AM, Brendan Eich bren...@mozilla.com  
wrote:

My positions are:

1. WebIDL, the bird in the hand (I agree with Sam: go invent  
something

better, come back when you're done).

2. Don't keep perpetuating catchall patterns, they are confusing for
developers and costly for implementors and static analysis tools,  
even if

implementable in some future ES edition.

3. Don't care.


Regarding 2. How do you feel about index accessors? I.e. for example  
you can do:


myNode.children[5]

which returns the same as

myNode.children.item(5)

This seems equally impossible to implement in ECMAScript, but is
something that I think is helpful to authors so not something that I
want to stop adding to new interfaces.


Good point. I have mixed feelings, to be honest. See the ArrayLike  
thread on es-discuss:


https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html

and followups. The one from Travis Leithead of Microsoft at:

https://mail.mozilla.org/pipermail/es-discuss/2009-May/009363.html

links to http://dev.w3.org/2006/webapi/WebIDL/#es-sequence, which has  
words about an Array host object:


http://dev.w3.org/2006/webapi/WebIDL/#dfn-array-host-object

This is new and different from the legacy collection/nodelist stuff,  
which we can't change. Is it the new-model solution for index  
accessors, or are you still wanting to make live tree cursors with  
indexed getter and setter catchalls?


The live tree cursors always seemed like a mixed bag at best. Folks  
want to use Array generic methods on them, and sometimes find the  
liveness a problem. I've not heard anyone saying the liveness was a  
crucial win.


/be

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Jonas Sicking

On Fri, Sep 25, 2009 at 12:35 PM, Brendan Eich bren...@mozilla.com wrote:
 On Sep 25, 2009, at 12:08 PM, Jonas Sicking wrote:

 On Fri, Sep 25, 2009 at 9:56 AM, Brendan Eich bren...@mozilla.com wrote:

 My positions are:

 1. WebIDL, the bird in the hand (I agree with Sam: go invent something
 better, come back when you're done).

 2. Don't keep perpetuating catchall patterns, they are confusing for
 developers and costly for implementors and static analysis tools, even if
 implementable in some future ES edition.

 3. Don't care.

 Regarding 2. How do you feel about index accessors? I.e. for example you
 can do:

 myNode.children[5]

 which returns the same as

 myNode.children.item(5)

 This seems equally impossible to implement in ECMAScript, but is
 something that I think is helpful to authors so not something that I
 want to stop adding to new interfaces.

 Good point. I have mixed feelings, to be honest. See the ArrayLike thread on
 es-discuss:

 https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html

 and followups. The one from Travis Leithead of Microsoft at:

 https://mail.mozilla.org/pipermail/es-discuss/2009-May/009363.html

 links to http://dev.w3.org/2006/webapi/WebIDL/#es-sequence, which has words
 about an Array host object:

 http://dev.w3.org/2006/webapi/WebIDL/#dfn-array-host-object

 This is new and different from the legacy collection/nodelist stuff, which
 we can't change. Is it the new-model solution for index accessors, or are
 you still wanting to make live tree cursors with indexed getter and setter
 catchalls?

This isn't just related to the Node tree. Two examples of new objects
that are Array like are:

FileList[1]. Returned from HTMLInputElement.files [2] and allows you
to access the File objects for reading file data etc without
roundtripping to the server. Since default behavior for input elements
is to allow only one file to be picked, lots of code do: file =
myInputElement.files[0]

DOMTokenList[3]. Returned from HTMLElement.classList and allows access
to the parsed class list for an element. Lets you iterate over the
classes using myDivElement.classList[0].

 The live tree cursors always seemed like a mixed bag at best. Folks want to
 use Array generic methods on them, and sometimes find the liveness a
 problem. I've not heard anyone saying the liveness was a crucial win.

Array accessors are now used even for non-live objects, such as the
NodeList returned from querySelectorAll[5]. So this applies even for
APIs where we're moving away from the liveness misstakes of the past.

[1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html#FileList-if
[2] 
http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#htmlinputelement
[3] http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#domtokenlist
[4] http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#htmlelement
[5] http://www.w3.org/TR/selectors-api/#nodeselector

/ Jonas

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination


I will stop the over-citing madness here and now :-P.

The struggle to formalize ArrayLike, which seems like a common goal  
for ES the core language and for WebIDL's ES bindings, makes me want  
to give an exception to the catchalls considered harmful for new  
interfaces injunction. I agree that indexing into array-likes, with  
no liveness magic, seems containable and desirable. ES folks haven't  
nailed down ArrayLike yet (our fault) and we would benefit from  
collaboration with WebIDL folks here.


So if you are doing more ArrayLike interfaces, let's keep talking.  
Don't let at least my catchalls-considered-harmful statements stop  
progress on ArrayLikes.


I expect some ES folks may demur now :-).

/be

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Cameron McCormack

Hi Brendan.

Brendan Eich:
 The struggle to formalize ArrayLike, which seems like a common goal
 for ES the core language and for WebIDL's ES bindings, makes me want
 to give an exception to the catchalls considered harmful for new
 interfaces injunction. I agree that indexing into array-likes, with
 no liveness magic, seems containable and desirable. ES folks haven't
 nailed down ArrayLike yet (our fault) and we would benefit from
 collaboration with WebIDL folks here.

So currently in Web IDL there are three ways to get objects with
properties that have non-negative integer names: sequences, arrays and
regular interfaces with index getters.  The definitions for sequenceT
and T[] types in Web IDL are relatively recent, but they are probably
more in line with the kinds of thing you’re looking for with ArrayLike
(without having re-read that thread yet).

The main difference between sequences and arrays is that sequence types
are effectively pass-by-value and use native Array objects, while array
types are host objects that act similarly to native Arrays, but with
appropriate IDL ↔ ECMAScript type conversions.  IDL arrays have the
native Array prototype object in their prototype chain.  A given IDL
array an be designated as read only, so that assigning to length or
array index properties has no effect.

There are no ES implementations of IDL sequences or arrays yet as far as
I know.

The third way, defining a regular interface with an index getter (and
maybe a setter) is currently used.  It’s implemented with special
[[Get]] (and [[Put]]) behaviour, which I guess is what you would like to
avoid.  However it’s not just a simple catchall – such objects are
defined to gain and lose properties with the appropriate index names as
appropriate for the interface.  This is done pretty much just so that
‘in’ and hasOwnProperty return true for array index properties, which is
needed for HTMLCollection and the like.


(Cross-posting to these three lists makes me feel funny, although I
recognise that these issues involve all three groups.)

-- 
Cameron McCormack ≝ http://mcc.id.au/

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Maciej Stachowiak



On Sep 25, 2009, at 3:34 PM, Krzysztof Maczyński wrote:


Do we need a WindowProxy in the core language? I'm not sure, but if
not then there has to be some other way of specifying how |this| in
global code binds to the outer window rather than the inner (Ecma
global). We didn't try to make something up here for ES5.


ECMAScript could just allow host embeddings to make the outermost
scope chain entry be something other than the global object. The main
downside is that this is more loose than is needed and could
technically allow crazy unreasonable things. But it may not be
possible to fully specify the behavior at the ECMAScript level, since
it depends on the notion of navigation. There may be a way to provide
a more narrowly tailored hook.

Regards,
Maciej
ECMA-262 allows (in 15.1) the prototype of the global object to be  
anything (including a host object with catchall semantics, or with  
properties existing for all names, just with value undefined, custom  
[[Put]] and [[Get]], etc.). Would implementing WindowProxy on that  
object and Window on the global object solve the use cases?
Is there actually a comprehensive list of use cases for this  
splitting anywhere, to facilitate checking any potential solutions  
against them?


ECMAScript requires the outermost scope chain entry and the object  
that is used as this for global function calls to be the same  
object. But the scope chain entry cannot be directly observed, so the  
only observable difference is in property access behavior. Nothing  
requires this to be stable and consistent for a host object.


But ECMAScript doesn't have a way to distinguish normal property  
access from property access via lexical scoping. It's unclear whether  
you could say an object is actually the same but happens to give  
different answers for scope chain access and direct property access,  
and possibly even different answers depending on which scope chain it  
was found in. I would think that strains host object exemptions to the  
breaking point.


Regards,
Maciej

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination


On Sep 25, 2009, at 4:57 PM, Maciej Stachowiak wrote:


On Sep 25, 2009, at 1:18 PM, Brendan Eich wrote:

So if you are doing more ArrayLike interfaces, let's keep talking.  
Don't let at least my catchalls-considered-harmful statements stop  
progress on ArrayLikes.


Perhaps when catchalls are considered for ECMAScript, there could b  
a way to encapsulate the specific pattern of index access, so you  
can have magical getters and setters for all index properties  
(integer numbers in range to be an array index) without having to  
install a full catchall for all properties.


Good point -- implementing array-likes via catchalls has been on our  
minds since the ES4 meta days [1], although we never split hooks  
based on property name being non-negative (possibly also = 2^32 - 1  
-- or is it = 2^32 - 2?!).


With WebIDL folks' help we will probably take down ArrayLike first,  
without going whole-hog for catchalls. The catchalls climb the meta  
ladder problem is more profound than the index/length magic (even the  
awful uint32 domain) of array-likes. I agree with Waldemar, we should  
make progress on array-likes without getting hung up on catchalls.


/be

[1] http://wiki.ecmascript.org/doku.php?id=proposals:catchalls

RE: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Allen Wirfs-Brock

-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
...
But ECMAScript doesn't have a way to distinguish normal property
access from property access via lexical scoping.

In the ES5 specification it does.  Reference that that resolve to property 
accesses
are explicitly distinguished from those that resolve to environment records.  
This includes
object environments such as the global environment and with environments.

It's unclear whether
you could say an object is actually the same but happens to give
different answers for scope chain access and direct property access,
and possibly even different answers depending on which scope chain it
was found in. I would think that strains host object exemptions to the
breaking point.

Accesses to the global object are mediated through a object environment record, 
but the
actual access to the global object's properties take place using internal 
methods [[Get]], [[Put]],
[[DefineOwnProperty]], etc. regardless of whether the access was initiated via 
a direct
property reference or via an environment record.  However, because neither ES3 
or ES5 (except for a
only a couple new requirements) really define or require specific semantics for 
host
object internal methods virtually anything goes. Even behavior that differs 
depending upon
the calling context of the internal method. (although internal methods 
aren't real and
aren't actually called).

When ECMAScript says host object it is really saying arbitrary 
implementation dependent magic
could happen here.

Allen

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Cameron McCormack

Maciej Stachowiak:
  Now, there may be pragmatic reasons for avoiding catchall getters and
  setters:
  …

Mark S. Miller:
 Yes. As an obvious example of #3, what happens when a Storage
 http://dev.w3.org/html5/webstorage/ key is toString?

It’s a good example of something that’s not obvious, though it is
defined.  If [OverrideBuiltins] is on the interface, then toString is
taken as a a named property; otherwise, it’s the property from the
Storage prototype object.  This is handled by the host object [[Get]]
method:

  http://dev.w3.org/2006/webapi/WebIDL/#get

-- 
Cameron McCormack ≝ http://mcc.id.au/

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-24 Thread James Graham


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.

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

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

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

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

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 bren...@mozilla.com
wrote:

On Sep 24, 2009, at 7:55 AM, Maciej Stachowiak wrote:

It seems like this is a Web IDL issue. I don't see any reason for
Web IDL to move to ECMA. It is a nominally language-independent
formalism that's being picked up by many W3C specs, and which
happens to have ECMAScript as one of the target languages. Much of
it is defined by Web compatibility constraints which would be
outside the core expertise of TC39.

Some of us on TC39 have lots of Web compatibility experience :-P.

Probably the best thing to do is to provide detailed technical
review of Web IDL via the W3C process.

Expertise on both sides of the artificial standards body divide may
very well be needed. The rest of this message convinces me it is
needed.

One problem with inviting review via the W3C process is getting
attention and following too many firehose-like mailing lists. es-disc...@mozilla.org
is at most a garden hose, which is an advantage.

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

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

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

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

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

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

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

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

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

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

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

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

Mandatory try-locks in JS, just say no.

I'm not sure what the other concerns about execution scope are -
seems hard to discuss

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination



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 m...@apple.com  
wrote:


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

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


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


Regards,
Maciej

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




-- Yehuda

On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich bren...@mozilla.com  
wrote:

On Sep 24, 2009, at 7:55 AM, Maciej Stachowiak wrote:

It seems like this is a Web IDL issue. I don't see any reason for  
Web IDL to move to ECMA. It is a nominally language-independent  
formalism that's being picked up by many W3C specs, and which  
happens to have ECMAScript as one of the target languages. Much of  
it is defined by Web compatibility constraints which would be  
outside the core expertise of TC39.


Some of us on TC39 have lots of Web compatibility experience :-P.



Probably the best thing to do is to provide detailed technical  
review of Web IDL via the W3C process.


Expertise on both sides of the artificial standards body divide may  
very well be needed. The rest of this message convinces me it is  
needed.


One problem with inviting review via the W3C process is getting  
attention and following too many firehose-like mailing lists. es-disc...@mozilla.org 
 is at most a garden hose, which is an advantage.


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


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




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

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

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


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

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


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


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


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




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


There was extensive recent email discussion of local storage  
locking on the wha...@whatwg.org mailing list. We could continue  
here if it would be helpful. I'm not sure it's useful to discuss in  
person without being up to speed on the email discussion. Here are  
some relevant threads:

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination



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


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


The converse of all these problems would arise if the spec became  
an ECMA spec.


I'm not advocating that, personally -- I'm explicitly encouraging  
some kind of collaboration across an artificial divide.


This may be difficult for many reasons, but where the spec ends up  
is less important to me (and if you make me choose either-or, I  
prefer w3's RF to Ecma's RAND on first principles) than that we have  
good collaboration without requiring every TC39 member to join w3c  
(if possible).


Any TC39 members whose employers can't join could perhaps become  
Invited Experts to the W3C Web Applications Working Group, if that  
facilitates review.


Do we have to agree on where the spec ends up before collaborating?  
I hope not, especially since it seems likely both ES specs and W3C  
ones may need to contain sub-specs that hook together, possibly  
involving common pieces duplicated among the specs.


We already have a spec in progress and it already has a home, so  
starting the conversation with a suggestion to move the work elsewhere  
struck me as odd and potentially disruptive.



We could recommend avoiding catch-alls as a best practice. However,  
many legacy DOM interfaces require catch-all behavior, so it can't  
be completely eliminated. If we want to restrict host objects to  
what WebIDL allows, but not break the Web, then catch-all getters  
and putters have to be among the things it allows.


The problem is containing the old patterns, heading off the  
temptation to use them in new APIs.


That would probably best be done via a recommendation not to use  
catchalls  in new APIs (in the Web IDL spec perhaps).





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


Yes, linearization of multiply-inherited interfaces (and multiple  
interfaces that are present but not inherited) is something that  
could use careful review and a better design. When I said these  
are largely Web IDL issues I mean not directly issues for the  
HTML Working Group. I did not mean to imply that TC 39 shouldn't  
have input - it should.


There's probably a better future beyond prototype chains, and I  
think the odds of finding that world and colonizing it are greater  
if we collaborate somehow. The current situation is making the best  
of de-facto standards, rationalizing what's out there.


Indeed, because the variance in what's out there makes life more  
difficult for authors. I expect it's not possible to get rid of  
prototypes from ECMAScript DOM bindings given the constraints of Web  
compatibility.




Possibly TC39 members need to do the main work on mixins, and then  
propose something coherent for WebIDL to bind to. But I know of  
folks not active in TC39 or not even Ecma mebmers, who are able to  
participate in the public HTML5 lists (and of course in whatwg.org),  
who do want mixins a la Ruby modules in JS, and their input would  
help us make some kind of progress.


But this separation of producers and consumers is artificial,  
and it may miss critical information not expressed in mythical  
waterfall requirements docs one might imagine the parties exchange.  
Systems RD 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

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination



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 m...@apple.com  
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 m...@apple.com  
wrote:


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

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


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


Regards,
Maciej

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




-- Yehuda

On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich  
bren...@mozilla.com wrote:

On Sep 24, 2009, at 7:55 AM, Maciej Stachowiak wrote:

It seems like this is a Web IDL issue. I don't see any reason for  
Web IDL to move to ECMA. It is a nominally language-independent  
formalism that's being picked up by many W3C specs, and which  
happens to have ECMAScript as one of the target languages. Much of  
it is defined by Web compatibility constraints which would be  
outside the core expertise of TC39.


Some of us on TC39 have lots of Web compatibility experience :-P.



Probably the best thing to do is to provide detailed technical  
review of Web IDL via the W3C process.


Expertise on both sides of the artificial standards body divide  
may very well be needed. The rest of this message convinces me it  
is needed.


One problem with inviting review via the W3C process is getting  
attention and following too many firehose-like mailing lists. es-disc...@mozilla.org 
 is at most a garden hose, which is an advantage.


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


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




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

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

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


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

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


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


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


Beyond this tarpit, we're interested in the best way to linearize  
multiply-inherited WebIDL interfaces onto prototype chains, or  
whether to use prototype

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-24 Thread Sam Ruby

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 bren...@mozilla.com wrote:

 Are invited experts time-bound in some way? We learned in Ecma that experts
 were to be invited to one meeting only.

In general, no.  There is a time limit mentioned in #4 above, but that
is just for exceptional circumstances, ones that are not likely to
apply in this situation.

- Sam Ruby

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination



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

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-24 Thread Sam Ruby


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

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination