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

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

2009-09-26 Thread Maciej Stachowiak



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

2009-09-25 Thread Brendan Eich


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

2009-09-25 Thread Brendan Eich


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

2009-09-25 Thread Brendan Eich


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

2009-09-25 Thread Brendan Eich


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

2009-09-24 Thread Maciej Stachowiak

On Sep 24, 2009, at 5:36 AM, Sam Ruby wrote:

At the upcoming TPAC, there is an opportunity for F2F coordination
between these two groups, and the time slot between 10 O'Clock and
Noon on Friday has been suggested for this.

To help prime the pump, here are four topics suggested by ECMA TC39
for discussion. On these and other topics, there is no need to wait
for the TPAC, discussion can begin now on the es-discuss mailing list.

- - -

The current WebIDL binding to ECMAScript is based on ES3... this
needs to more closely track to the evolution of ES, in particular it
needs to be updated to ES5 w.r.t the Meta Object Protocol. In the
process, we should discuss whether this work continues in the W3C,
is done as a joint effort with ECMA, or moves to ECMA entirely.

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

- - -

A concern specific to HTML5 uses WebIDL in a way that precludes
implementation of these objects in ECMAScript (i.e., they can only
be implemented as host objects), and an explicit goal of ECMA TC39
has been to reduce such. Ideally ECMA TC39 and the W3C HTML WG
would jointly develop guidance on developing web APIs, and the W3C
HTML WG would apply that guidance in HTML5.

Meanwhile, I would encourage members of ECMA TC 39 who are aware of
specific issues to open bug reports:

http://www.w3.org/Bugs/Public/

And I would encourage members of the HTML WG who are interested in
this topic to read up on the following emails (suggested by Brendan
Eich):

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

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

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

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

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

- - -

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

There was extensive recent email discussion of local storage locking
on the 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

2009-09-24 Thread Maciej Stachowiak

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

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

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

Regards,
Maciej

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

-- Yehuda

On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich 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

2009-09-24 Thread Maciej Stachowiak



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

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


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


Regards,
Maciej



-- Yehuda

On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak 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

2009-09-24 Thread Maciej Stachowiak



On Sep 24, 2009, at 11:25 AM, Brendan Eich wrote:


On Sep 24, 2009, at 10:48 AM, Maciej Stachowiak wrote:


On Sep 24, 2009, at 9:47 AM, Brendan Eich wrote:

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


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


One problem with inviting review via the W3C process is getting  
attention and following too many firehose-like mailing lists. es-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

2009-09-24 Thread Maciej Stachowiak



On Sep 24, 2009, at 12:00 PM, Yehuda Katz wrote:

I'll think about it. I was mostly hoping to start a discussion about  
alternatives. I think the bottom line here is that while the spec is  
well-optimized for implementors, it is not very well optimized for  
consumers. I suppose it would be possible to say that this stuff is  
*only* for implementors. I'd prefer if it were also readable for  
those trying to use the specification.


My inclination would be to address this by improving the current Web  
IDL spec,  or to write an informative primer style document to  
accompany it. I also think some of the complexity of the Web IDL spec  
can probably be removed without losing anything important - I think it  
offers some constructs that are not used by any spec relying on it.


 - Maciej



-- Yehuda

On Thu, Sep 24, 2009 at 11:17 AM, Maciej Stachowiak 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

2009-09-24 Thread Maciej Stachowiak



On Sep 24, 2009, at 2:16 PM, Sam Ruby wrote:


On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:


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

review.


Unfortunately, no.  See #2 and #3 below:

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


It depends on the nature of the employer, and the reason they are  
unable to join. Historically there have been Invited Experts in W3C  
Working Groups who are employed by such organizations as universities  
or small start-ups. We even have some in the HTML Working Group. So it  
would probably be more accurate to say it depends and that it may be  
subject to the judgment of the W3C Team.


Regards,
Maciej

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

2009-09-24 Thread Maciej Stachowiak



On Sep 24, 2009, at 2:37 PM, Sam Ruby wrote:


Maciej Stachowiak wrote:

On Sep 24, 2009, at 2:16 PM, Sam Ruby wrote:

On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:


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

review.


Unfortunately, no.  See #2 and #3 below:

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.


I didn't know that there was a specific case driving this concern. I  
thought this was a general worry about, e.g., university researchers.  
I would not ask the W3C Team to reconsider specific cases where they  
have already rendered a judgment.


Regards,
Maciej

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

2009-09-24 Thread Brendan Eich

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.