On Fri, 25 Sep 2009 05:17:59 +0200, Bjoern Hoehrmann derhoe...@gmx.net
wrote:
* Charles McCathieNevile wrote:
More to the point, Bjoern, what is your preferred spelling?
The proper spelling of my name is explicitly specified in RFC 4329.
[for those who haven't read that, it's Björn
On Fri, 18 Sep 2009 13:25:59 +0200, Arthur Barstow art.bars...@nokia.com
wrote:
This is a Call for Consensus (CfC) to publish the First Public Working
Draft (FPWD) of the Web Simple Database API spec:
http://dev.w3.org/2006/webapi/WebSimpleDatabase/
As with all of our CfCs, positive
Hi Lachy,
Here's a proposal.
querySelector*(selector, context) // allows selectors with :scope
pseudo-class
queryScopedSelector*(selector, context) // allows selectors with implied
:scope
matchesSelector(selector, context) // allows selectors with :scope
pseudo-class
To check if the :scope
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
Sean Hogan wrote:
Hi Lachy,
Here's a proposal.
querySelector*(selector, context) // allows selectors with :scope
pseudo-class
queryScopedSelector*(selector, context) // allows selectors with
implied :scope
matchesSelector(selector, context) // allows selectors with :scope
pseudo-class
To
Hi All,
Firstly, as editor, I want to personally say thanks to everyone that
participated in creating tests for PC in Dusseldorf! (and a huge
thanks to Vodafone for hosting). Hope the spec was not too painful to
write tests for:)
I'm wondering if we can get a quick summary of what happened during
I once raised ISSUE-75 (on the old XMLHttpRequest document pointer) and
ISSUE-91 (redirect issue in CORS) and believe I resolved both issues to my
satisfaction so I closed them. Feel free to appeal but given all the
changes it is probably better to raise specific issues against the
Sean Hogan wrote:
Here's a proposal.
querySelector*(selector, context) // allows selectors with :scope
pseudo-class
queryScopedSelector*(selector, context) // allows selectors with implied
:scope
matchesSelector(selector, context) // allows selectors with :scope
pseudo-class
Yes, this is
Hi.
In section 4.2 Parsing and processing SQL statements, point 2 starts as
Replace each ? placeholder but then says later Note: Substitutions for
? placeholders are done at the literal level, not as string
concatenations.
By using the word replace, that execution step may cause confusion, as
ISSUE-103: accessing
status/statusText/getResponseHeader()/getAllResponseHeaders() [XHR]
http://www.w3.org/2008/webapps/track/issues/103
Raised by: Anne van Kesteren
On product: XHR
After invoking abort() Internet Explorer throws for getting these members as
per the specification. (And
ISSUE-104: supporting structured clones [XHR2]
http://www.w3.org/2008/webapps/track/issues/104
Raised by: Anne van Kesteren
On product: XHR2
It would be nice to support the HTML5 concept of structured clones for both
sending and receiving. Prerequisite of that is getting a serialization
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 9/25/09 9:59 AM, Lachlan Hunt wrote:
Yes, the reference elements parameter will accept either a single
element, Array or NodeList.
What about HTMLCollection? Or have we finally made that interface
inherit from NodeList?
Another question I just had reading this, and this is probably a
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
On 9/25/09 1:35 AM, Garrett Smith wrote:
No, you did not say it is slow. I'm saying that your laptop is
probably a lot more powerful than a mobile device with a browser, such
as Blackberry9000. Do you agree with that?
Sure. It's a pretty self-evidently true claim.
that said, note that on a
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
On Sep 25, 2009, at 12:42 , Marcos Caceres wrote:
I'm wondering if we can get a quick summary of what happened during
the testing workshop. I assume a short report will be created?
Kai posted this to MWTS, here it is for WebApps:
http://www.flickr.com/photos/hendry/3947857456/
Last Monday
On Fri, Sep 25, 2009 at 2:46 AM, Charles McCathieNevile
cha...@opera.com wrote:
On Fri, 18 Sep 2009 13:25:59 +0200, Arthur Barstow art.bars...@nokia.com
wrote:
This is a Call for Consensus (CfC) to publish the First Public Working
Draft (FPWD) of the Web Simple Database API spec:
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
On Fri, Sep 25, 2009 at 7:25 AM, Web Applications Working Group Issue
Tracker sysbot+trac...@w3.org sysbot%2btrac...@w3.org wrote:
ISSUE-104: supporting structured clones [XHR2]
http://www.w3.org/2008/webapps/track/issues/104
Raised by: Anne van Kesteren
On product: XHR2
It would be nice
3. Obtain a collection of elements based on their relation to more than one
specified reference elements.
e.g.
Query to the document to obtain elements matching :scope+span, where
:scope is intended to match any of the elements in a specific collection.
This would be simpler than iterating
On Fri, Sep 25, 2009 at 10:09 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Sep 25, 2009 at 7:25 AM, Web Applications Working Group Issue
Tracker sysbot+trac...@w3.org wrote:
ISSUE-104: supporting structured clones [XHR2]
http://www.w3.org/2008/webapps/track/issues/104
Raised by:
+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,
Lachlan Hunt wrote:
Sean Hogan wrote:
Here's a proposal.
querySelector*(selector, context) // allows selectors with :scope
pseudo-class
queryScopedSelector*(selector, context) // allows selectors with implied
:scope
matchesSelector(selector, context) // allows selectors with :scope
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,
34 matches
Mail list logo
