On Sep 29, 2009, at 08:17 , Maciej Stachowiak wrote:
On Sep 28, 2009, at 2:06 AM, Robin Berjon wrote:
On Sep 28, 2009, at 01:19 , Maciej Stachowiak wrote:
On Sep 27, 2009, at 12:35 PM, Robin Berjon wrote:
If at all possible I'd rather it went to LC ASAP, and if needed
that new stuff be done
On Sep 28, 2009, at 2:06 AM, Robin Berjon wrote:
On Sep 28, 2009, at 01:19 , Maciej Stachowiak wrote:
On Sep 27, 2009, at 12:35 PM, Robin Berjon wrote:
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
On Sep 28, 2009, at 01:19 , Maciej Stachowiak wrote:
On Sep 27, 2009, at 12:35 PM, Robin Berjon wrote:
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
On Mon, Sep 28, 2009 at 2:02 AM, Robin Berjon ro...@berjon.com wrote:
I'm not sure what you're getting at here. WebIDL isn't just for HTML5, it's
used throughout WebApps and DAP, and by a number of other groups as well,
which have deliverables at various levels of completion. By depending on
Allen Wirfs-Brock:
The internal methods such as [[Delete]] aren't an actual extension
mechanism. They are a specification device used to define the
semantics of ECMAScript. As such they are subject to change (there
are significant changes in the ES5 spec.) and could even completely
disappear
On Sep 26, 2009, at 11:16 PM, Cameron McCormack wrote:
OK, that is indeed what I’m hearing from you guys. “Host objects may
implement these [internal] methods in any manner unless specified
otherwise” in ES3 doesn’t sound like it’s particularly discouraging of
the different behaviour that Web
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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.
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
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
-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
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
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
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
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
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
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
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
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
+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
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
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
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
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
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,
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
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
-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
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,
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
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
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
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
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
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
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
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
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.
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
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
Maybe this would be a good opportunity to revisit the utility of WebIDL in
specifications (as formal specifications were re-examined for ES-Harmony).
The WebIDL spec is pretty large, and I personally have found its use a
confounding factor in understanding other specs (like HTML5).
-- Yehuda
On
Is it really true that WebIDL and the vague way DOM2 was described are the
only two options? Surely that's a false dilemma?
-- Yehuda
On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak m...@apple.com wrote:
On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:
Maybe this would be a good
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.
On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:
This may be difficult for many reasons, but where the spec ends up
is less important to me (and if you make me choose either-or, I
prefer w3's RF to Ecma's RAND on first principles) than that we
have good collaboration without
Hi everyone.
Sam Ruby:
At the upcoming TPAC, there is an opportunity for F2F coordination
between these two groups, and the time slot between 10 O'Clock and
Noon on Friday has been suggested for this.
I'm travelling at the moment, so apologies for the delay in replying.
Unfortunately I
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
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 {
60 matches
Mail list logo
