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

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

[Mark S. Miller]

On Fri, Sep 25, 2009 at 8:27 PM, Mark S. Miller  wrote:
> OTOH, if our resolution of the need for array-like generic indexes is
> to allow overloading of [], then perhaps the resolution for new APIs
> is to annotate them somehow, to distinguish them from the
> legacy-namespace-confused-APIs-we-can't-fix, so that, for example,
>
>storage['toString'] is equivalent to storage.getItem('toString'),
> and neither is considered a property access (other than access to the
> getItem property).
>storage.toString accesses storage's toString property, and is not
> affected by the alternate getter annotation we'd use instead of the
> above.

I withdraw that alternate suggestion. It would require any code
attempting to access genuine properties of the storage object by
computed name to resort to indirect and inconvenience means, like
using Object.getOwnPropertyDescriptor() and simulating the [[Get]]
algorithm.


-- 
Cheers,
--MarkM

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

[Mark S. Miller]

On Fri, Sep 25, 2009 at 4:54 PM, Maciej Stachowiak  wrote:
> On Sep 25, 2009, at 7:26 AM, Mark S. Miller wrote:
> I think there are two possible perspectives on what constitutes
> "magnify[ing] tthe 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 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. Avoiding it in new APIs
> would provide a small amount of temporary relief for the brave person who
> seeks to implement the whole Web platform in pure ECMAScript, but in the
> long run would make no difference to the feasibility of the overall goal.

A good distinction. I agree that the #A problem is worse. I also do
not know of cases of #A.

Regarding #B, I also think these are best avoided. Various existing
systems that try to emulate DOM object behavior using JavaScript code
may fail to emulate some of these, creating leaky abstractions that
their users live with. Each additional case adds another headache.
However, your split below of Array-like vs catchalls is nice, and your
enumeration of the reasons to avoid APIs that need general catchalls
is great.


> Now, there may be pragmatic reasons for avoiding catchall getters and
> setters:
>
> 1) Difficulty of efficient implementation (this is less true for index-only
> catchall getters).
> 2) Potential confusingness to authors (probably also less true for index
> access).
> 3) Namespace collisions between the magical attributes and the object's
> built-in attributes and methods - this makes it harder to specify and
> explain the interface and creates hazards for use (does not apply to the
> index access pattern afaict).


Yes. As an obvious example of #3, what happens when a Storage
 key is "toString"?

I note that WebIDL already distinguishes between requiring catchalls
for any property name, as in getItem(), vs requiring only index
access, as in key() below.

interface Storage {
  readonly attribute unsigned long length;
  getter any key(in unsigned long index);
  getter any getItem(in DOMString key);
  setter creator void setItem(in DOMString key, in any data);
  deleter void removeItem(in DOMString key);
  void clear();
};


> I think these are reasonable arguments (though I wouldn't rule out a priori
> that there may be situations where the API convenience of catchalls
> outweighs these concerns).

Of course nothing should be ruled out a priori. But your issue #3 is
quite serious. Do you know of any cases where the API convenience
justifies creating yet another such namespace confusion? IMO, Storage
does not and the getter/setter/deleter annotations on it, being a
non-legacy API, should be removed from all but key(). The
inconvenience of tracking down the resulting bugs outweigh the
convenience of saving a few characters in source.

OTOH, if our resolution of the need for array-like generic indexes is
to allow overloading of [], then perhaps the resolution for new APIs
is to annotate them somehow, to distinguish them from the
legacy-namespace-confused-APIs-we-can't-fix, so that, for example,

storage['toString'] is equivalent to storage.getItem('toString'),
and neither is considered a property access (other than access to the
getItem property).
storage.toString accesses storage's toString property, and is not
affected by the alternate getter annotation we'd use instead of the
above.


> But I think these are totally separate from the "implementability in pure
> ECMAScript" concern. And in particular, I think index access to array-like
> objects is a good pattern that we should not stop using in APIs just because
> it's not implementable in pure ECMAScript today. Past interfaces use this
> pattern, and future interfaces should clearly use it once ECMAScript
> supports it. A temporary moratorium on using it would not be a wise
> tradeoff.

These are good distinctions. I do not disagree.

Regarding named properties, I think such a moratorium is justified.

-- 
Cheers,
--MarkM

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

[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

[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

[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

[Maciej Stachowiak]

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


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.


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.


Regards,
Maciej

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

[Maciej Stachowiak]

On Sep 25, 2009, at 7:26 AM, 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.


The design of Web IDL itself is highly informed by the ECMAScript  
language binding - in fact, many Web IDL constructs exist solely for  
modeling ECMAScript APIs. So I don't think this split is useful



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.


I think there are two possible perspectives on what constitutes  
"magnify[ing] tthe 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 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. Avoiding it in new APIs would provide a small amount of  
temporary relief for the brave person who seeks to implement the whole  
Web platform in pure ECMAScript, but in the long run would make no  
difference to the feasibility of the overall goal.


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


1) Difficulty of efficient implementation (this is less true for index- 
only catchall getters).
2) Potential confusingness to authors (probably also less true for  
index access).
3) Namespace collisions between the magical attributes and the  
object's built-in attributes and methods - this makes it harder to  
specify and explain the interface and creates hazards for use (does  
not apply to the index access pattern afaict).


I think these are reasonable arguments (though I wouldn't rule out a  
priori that there may be situations where the API convenience of  
catchalls outweighs these concerns).


But I think these are totally separate from the "implementability in  
pure ECMAScript" concern. And in particular, I think index access to  
array-like objects is a good pattern that we should not stop using in  
APIs just because it's not implementable in pure ECMAScript today.  
Past interfaces use this pattern, and future interfaces should clearly  
use it once ECMAScript supports it. A temporary moratorium on using it  
would not be a wise tradeoff.


Regards,
Maciej

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

[Krzysztof Maczyński]

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

Best regards,

Krzysztof
HTML WG

Re: [selectors-api] Scoped Selectors

[Sean Hogan]

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
pseudo-class


Yes, this is effectively the same as option #2 that I described, 
except you haven't provided a way to support implied scope there.


That's because implied scope is incompatible with ":scope ~ p" or "~ p" 
should we want to support those. I think it will be confusing to have 
implied and explicit forms for :scope.



element.querySelector*() limits selection to descendants of elements,
and element.queryScopedSelector*() should be consistent.
If element is the scope then element.queryScopedSelector*("~p") will
return no elements.
If we want to support sibling queries then we need to provide a scope
explicitly, so:

element.parentNode.queryScopedSelector*("~p", element);

Notes:
1. I don't think browsers should provide queryScopedSelector*()


This seems contradictory.  You seemed to be proposing that we use 
queryScopedSelector, and now you're saying we shouldn't.  Personally, 
I agree that we shouldn't.  It's my least favourite solution of them all.




I don't think implied ":scope" selector text should be supported at all. 
It's a whim of the JS libraries. I'm just concerned that if we do have 
it then at least it doesn't screw up the core functionality.



2. I think :context is a better name than :scope


Yeah, the name of :scope is a complicated issue. :context isn't ideal 
either.  It would be slightly confusing because selectors API defines 
the term "context node" as being the node upon which the method is 
being invoked.  Maybe something like :ref or :reference might work.




Yeah.


3. If the context argument of these methods could be an element or a
NodeList it might satisfy some of the other feature requests.


Yes, the reference elements parameter will accept either a single 
element, Array or NodeList.


I have checked in a new draft containing my first attempt at 
supporting scoped selectors, with support for both :scope (or whatever 
it gets called) and implied scope selectors.  I've opted for a 
combination of options 1 and 2 that I previously described, using the 
createSelector() and SelectorExpression object for being able to 
represent implied scoped selectors easily, and optional refNodes 
parameters on querySelector*() and matchesSelector() methods for 
supplying contextual reference elements (that match :scope).


Basically, for the simple case, it works as illustrated in these 
examples:


elm.querySelector(":scope>p");
document.querySelectorAll(":scope>p", elm);
document.querySelectorAll(":scope>p", [elm1, elm2]);

To provide the functionality of JS libraries supporting implied scope 
selectors, you first create a SelectorExpression object like this:


document.createSelector(">em,>strong", true);

That object can then be passed to either the querySelector*() or 
matchesSelector() methods.


The effect of this is basically that JavaScript libraries can mostly 
use document.createSelector(str, true) as a direct replacement their 
own custom selector parsing libraries (except for the cases where 
they're using custom pseudo-classes not supported by the browser)


One possible modification I'm considering is introducing a separate 
factory method for creating implied scope selectors: 
createScopedSelector(selector); rather than using a boolean parameter.





Looks okay, except I don't think there should be implied contextual 
reference elements.
What are the chances that we will have to extend createSelector in the 
future? e.g. namespaces

Re: [widgets] Widgets test creation event

[Arthur Barstow]

Hi All,

Thanks very much for this summary [1] and your good work and to  
Christian and VF for hosting this event!


-Regards, Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/ 
1337.html

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

[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 sequence
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

[Jonas Sicking]

On Fri, Sep 25, 2009 at 1:18 PM, Brendan Eich  wrote:
> 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.

Sounds great!

I don't know of any new interfaces we're designing that are ArrayLike,
(unless you count the not-yet-finalized HTML5 and FileAPI specs). But
I'm sure more will arrive so support from ES would be great!

/ Jonas

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

[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

[Jonas Sicking]

On Fri, Sep 25, 2009 at 12:35 PM, Brendan Eich  wrote:
> On Sep 25, 2009, at 12:08 PM, Jonas Sicking wrote:
>
>> On Fri, Sep 25, 2009 at 9:56 AM, Brendan Eich  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

[Brendan Eich]

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

On Fri, Sep 25, 2009 at 9:56 AM, Brendan Eich   
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

[Jonas Sicking]

On Fri, Sep 25, 2009 at 9:56 AM, Brendan Eich  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

[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: ISSUE-104: supporting structured clones [XHR2]

[Jonas Sicking]

On Fri, Sep 25, 2009 at 10:09 AM, Jeremy Orlow  wrote:
> On Fri, Sep 25, 2009 at 7:25 AM, Web Applications Working Group Issue
> Tracker  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 to support the HTML5 concept of structured clones for
>> both sending and receiving. Prerequisite of that is getting a serialization
>> format defined and preferably some kind of media type for it. (I think this
>> would be better than supporting JSON.)
>
> I can't access the issue tracker, so I'm replying here.
> What's the use case for this?  As far as I can tell, everything that
> Structured Clones support is either 1) easy to serialize into JSON, 2)
> expensive to serialize, or 3) silly to serialize.
> An example of 2 would be ImageData.  An example of 3 would be RegEx's.  File
> and FileData would fit either in 2 or 3 depending on how you implemented
> them.
> My point is that I don't see a strong reason why Structured Clones would be
> useful outside of the browser.  And thus I'm not sure it's worth the effort
> to create a standardized way of serializing it.
> But maybe I'm missing something?

Yeah, I'm not entirely convinced of structured clones as a network
format either. The one use-case beyond JSON i can see is Files and
FileData. I'm sort of thinking that we should support only that.

/ Jonas

Re: [selectors-api] Scoped Selectors

[John Resig]

> 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 all of the nodes in the collection,
> running the query on each of them and then merging the results.
>

I don't see the purpose of making a distinction between the root node used
for the query and the node being used for the scope - they should be one and
the same.

// Doesn't make sense:
document.querySelectorAll("div div", document.body)

// Does make sense
document.body.querySelectorAll("div div")

Also, I don't think it's been made clear in the discussion thus far but
while cases like handling "> div" are nice - we're mostly concerned about
cases like "div div" (that escape outside the original root of the query).

Given this DOM:


  

  


// All of these should return nothing
document.getElementById("one").querySelelctor("div div")
document.getElementById("one").querySelelctor("body div")
document.getElementById("one").querySelelctor("div #two")



> *Problems*
>
> 1. Need a way to allow the browser to parse implicitly scoped selectors
> beginning with combinators and imply the presence of :scope before each in
> the group.
>
> 2. Need to allow :scope to be used within the selector strings, and specify
> one or more scope elements that will be matched by :scope.  This needs to be
> useable with all of the querySelector(), querySelectorAll() and
> matchesSelector() methods, or others with equivalent functionality.
>
> 3. Ideally, there would be an easy, reliable way for scripts to test if the
> implementation supports scoped selectors (at least, implicitly scoped
> selectors. Those using :scope could only be discovered by capturing the
> SYNTAX_ERR exception)  For legacy browsers that don't, they can fall back to
> their own selector engines.
>
>
> *Possible Solutions*
>
> 1. Define a Selector object that can be used to parse and store a
>selector, and which can handle pre-parsing the selector and
>specifying the scope elements upon creation.  This selector object
>can then be passed anywhere that accepts a selector string. (This is
>basically part of the createSelector() and Selector interface
>proposal from earlier).
>
> 2. Add parameters to the querySelector(), querySelectorAll() and
>matchesSelector() methods for:
>a. Indicating whether the selectors parameter should be processed
>   with an implied scope.
>b. Specifying one or more reference elements that would match :scope.
>
> 3. Create new scoped versions of the existing methods that accept one
>or more reference elements that would match the implied scope.
>Add an optional parameter to the existing querySelector*() methods
>that would Allow one or more reference elements to be specified to
>match the explicit use of :scope in the selector.
>
>
> Option 2 doesn't provide an easy way to detect browser support.  Option 3
> creates an additional queryScopedSelector*() and matchesScopedSelector()
> methods, but this could get quite verbose if we also add equivalent NS
> methods to handle the namespace issue, to both the scoped and non-scoped
> versions.  This would create an unreasonable number of different methods
> that would make understanding the API quite complex.  Option 1 is
> syntactically messy, and requires the creation of a new object just to
> handle a scoped selector, even if that selector is only used once.
>
> I'm not sure which alternative would be best, and I'm kind of hoping
> there's a 4th alternative I haven't thought of yet that can address the use
> cases easliy enough.
>

There doesn't need to be scoping for matchesSelector. matchesSelector
implies that it it's starting from the specified node and doing a match.
Additionally the use case of .matchesSelector("> div") doesn't really exist.

With that in mind, option #3 looks the best to me. It's lame that the API
will be longer but we'll be able to use basic object detection to see if it
exists. Unfortunately the proper scoping wasn't done the first time the
Selectors API was implemented so we kind of have to play the hand we've been
dealt.

Thus there would be two new methods:
queryScopedSelectorAll
queryScopedSelector

Same length as getElementsByClassName - long but not untenable.

--John

Re: ISSUE-104: supporting structured clones [XHR2]

[Jeremy Orlow]

On Fri, Sep 25, 2009 at 7:25 AM, Web Applications Working Group Issue
Tracker > 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 to support the HTML5 concept of structured clones for both
> sending and receiving. Prerequisite of that is getting a serialization
> format defined and preferably some kind of media type for it. (I think this
> would be better than supporting JSON.)
>

I can't access the issue tracker, so I'm replying here.
What's the use case for this?  As far as I can tell, everything that
Structured Clones support is either 1) easy to serialize into JSON, 2)
expensive to serialize, or 3) silly to serialize.

An example of 2 would be ImageData.  An example of 3 would be RegEx's.  File
and FileData would fit either in 2 or 3 depending on how you implemented
them.

My point is that I don't see a strong reason why Structured Clones would be
useful outside of the browser.  And thus I'm not sure it's worth the effort
to create a standardized way of serializing it.

But maybe I'm missing something?

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

[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: CfC: to publish the FPWD of the Web Simple Database API spec; deadline 25 September

[Jonas Sicking]

On Fri, Sep 25, 2009 at 2:46 AM, Charles McCathieNevile
 wrote:
> On Fri, 18 Sep 2009 13:25:59 +0200, Arthur Barstow 
> 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 response is preferred and encouraged and
>> silence will be assumed to be assent. The deadline for comments is September
>> 25.
>
> Opera is in favour of publishing a draft.

So am I.

/ Jonas

Re: [widgets] Widgets test creation event

[Robin Berjon]

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 about 9 people met from as far away as India to complete
the test suite for Widgets P&C 1.0 in Düsseldorf, Germany.

By the end of the first day of the three day event, we surprisingly
achieved 100% coverage of all UA product widget tests. We begun with
only about a third of them.

The next two days we concentrated on reviewing, checking in the tests
from http://git.webvm.net/?p=wgtqa into CVS (quite painful) and adding
more tests to covered test assertions.

The second day featured an in depth look at testing Widgets 1.0:
Digital Signatures http://www.w3.org/TR/widgets-digsig/ and work has
begun on a test plan.
http://dev.w3.org/2006/waf/widgets-digsig/tests/

Signed widget tests will be generated from a set of scripted available
here: http://dev.w3.org/2006/waf/widgets-digsig/tests/tools/

In summary the P&C coverage meeting goals have been met and we all
agreed that the event was a productive one.

I would like to especially thank Dominique Hazael-Massieux's
organisational skills and Christian Breitschwerdt for hosting the
event at the Vodafone offices.
"""

Additionally we found some issues in the specification that were  
reported. Some smaller ones should be documented in the test suite  
(they are mostly about redundant normative assertions, and things that  
can't really be tested easily such as those involving features, or  
things that may change between when the implementation has finished  
reading the config.xml document and when the start document is  
processed, such as width and height).



Apart from P&C, which other specs were tested?


We started work on DigSig. We looked at how to test TWI (fka A+E), and  
discussed testing WARP.



Is test-suite-problems.txt [1] up to date and what is the purpose of
that file? Are those things that I need to fix or were they fixed
already?


It was up to date last I checked it in. This is where we documented  
all the issues we found when we reviewed the tests that had been  
submitted. Those that remain are either 1) tests that haven't been  
checked in yet (some were missing from you at some point, not sure if  
you added them all; and Kai still had some leftover tests from  
webvm.net to move over); 2) buggy, or hard to test things.



When will the tests from wgt.webvm.net be moved over to the W3C?


I believe most have been, but some are left.

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

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

[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: [selectors-api] Summary of Feature Requests for v2

[Boris Zbarsky]

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 mobile device with 128 MB of RAM the RAM is a lot
more likely to be a problem than the CPU in some ways.  Running out of
memory is strictly worse than being a little bit slower.  So a lookup table
may be more of a loss than a win, depending.


An internal cache for matchesSelector (a lookup table) would be an
implementation detail, wouldn't it?


Sure.  Sean was just saying there probably is one already; I was saying 
there isn't, along with a brief explanation of why.  You apparently 
objected to part of this explanation, but at this point I'm not quite 
sure what your objection was, exactly.  I made two statements:


1)  There seem to be no current parsed-selector caches in Webkit and
Gecko's querySelector implementation.
2)  On my particular hardware, parsing a particular selector in Gecko
takes approximately 5.5us.

Any conclusions to be drawn for other rendering engines, other 
selectors, or other hardware setups should be qualified appropriately 
(for example, Gecko on an N810 would probably end up closer to 500us for 
that same operation, if I recall the typical performance ratios correctly).



The idea for QuerySelector.create is the result would be an object
that the program could hang on to. It would not be recreated and
garbage collected each time.


Yes, I understand the proposal.

-Boris

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

[Anne van Kesteren]

On Fri, 25 Sep 2009 16:26:21 +0200, 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.


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: [selectors-api] Scoped Selectors

[Boris Zbarsky]

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 webidl 
question, not a selectors API question, is what makes something an 
element, array, or nodelist.  First off, what if some spec introduces 
objects that implement both the Element and NodeList interfaces? 
Second, what if I do:


  function foo() {
  }
  foo.prototype = Array.prototype
  var myObj = new foo();

Is that an array?  How should the callee be able to determine this?

What about:

  var elm = document.createElement("div");
  function foo() {
  }
  foo.prototype = elm;
  var myObj = new foo();

For what it's worth, it looks like in this case 
myObj.appendChild(document.createTextNode("test")) appends to |elm| in 
Gecko and Google Chrome, throws WRONG_THIS_ERR in Opera, and throws 
"Type error" in Safari.  Doing document.body.appendChild(myObj) throws 
WRONG_ARGUMENTS_ERR in Opera, throws NOT_FOUND_ERR in Safari and Chrome, 
and throws HIERARCHY_REQUEST_ERR in Gecko  How is this case 
different from the array case, if at all?


-Boris

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

[Mark S. Miller]

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

ISSUE-104: supporting structured clones [XHR2]

[Web Applications Working Group Issue Tracker]

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 format 
defined and preferably some kind of media type for it. (I think this would be 
better than supporting JSON.)

ISSUE-103: accessing status/statusText/getResponseHeader()/getAllResponseHeaders() [XHR]

[Web Applications Working Group Issue Tracker]

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 probably also in general when no request has been 
made yet.)

Firefox apparently does not. Someone from WebKit conveyed to me that they would 
like to change to match Firefox.

I personally have these requirements:

a) All implementations should end up doing the same in the end.
b) I would like to know exactly what needs to be changed in the current 
specification so there is a lot less chance of me making a mistake.

Of course, all of this depends on everyone agreeing with changes being needed 
in the first place.

[webdatabase] wording on "Parsing and processing SQL statements" section

[João Eiras]

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
I've seen, about people thinking it might be related to some sort of
concatenation, although the specification clearly clarifies that's not the
intended result.

I would reword step 2 and the clarification as:

"Bind each ? placeholder with the value of the argument in the arguments
array with the same position. (So the first ? placeholder is bound the
first value in the arguments array, and generally the nth ? placeholder
gets bound by the nth value in the arguments array.)
By binding, the result of the query must be the same as if the arguments
had been literally replaced on the sql string, although this later
practice is not recommended because it may risk SQL injection attacks."

Using Bind for Replace makes it much more clear.


--

João Eiras
Core Developer, Opera Software ASA, http://www.opera.com/

Re: [selectors-api] Scoped Selectors

[Lachlan Hunt]

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 effectively the same as option #2 that I described, except 
you haven't provided a way to support implied scope there.



To check if the :scope pseudo-class is available, use:

try { document.body.matchesSelector(":scope", document.body); }
catch (error) { /* not supported */ }


I'm not sure that relying on exceptions for feature testing is an ideal 
way to provide that functionality.



Now, querySelector*() can't accept selectors with implied :scope because
while "> em" is unambiguously ":scope > em", "p em" would become
ambiguous. (is it "p em" or ":scope p em")
So we need a new method, such as queryScopedSelector*().


Well, we at least need some way to tell the implementation to 
pre-process the selector to imply the presence of :scope. 
queryScopedSelector*() would do this, as would providing an explicit 
pre-processing step, the result of which can be passed to the 
querySelector*() methods.



element.querySelector*() limits selection to descendants of elements,
and element.queryScopedSelector*() should be consistent.
If element is the scope then element.queryScopedSelector*("~p") will
return no elements.
If we want to support sibling queries then we need to provide a scope
explicitly, so:

element.parentNode.queryScopedSelector*("~p", element);

Notes:
1. I don't think browsers should provide queryScopedSelector*()


This seems contradictory.  You seemed to be proposing that we use 
queryScopedSelector, and now you're saying we shouldn't.  Personally, I 
agree that we shouldn't.  It's my least favourite solution of them all.



2. I think :context is a better name than :scope


Yeah, the name of :scope is a complicated issue. :context isn't ideal 
either.  It would be slightly confusing because selectors API defines 
the term "context node" as being the node upon which the method is being 
invoked.  Maybe something like :ref or :reference might work.



3. If the context argument of these methods could be an element or a
NodeList it might satisfy some of the other feature requests.


Yes, the reference elements parameter will accept either a single 
element, Array or NodeList.


I have checked in a new draft containing my first attempt at supporting 
scoped selectors, with support for both :scope (or whatever it gets 
called) and implied scope selectors.  I've opted for a combination of 
options 1 and 2 that I previously described, using the createSelector() 
and SelectorExpression object for being able to represent implied scoped 
selectors easily, and optional refNodes parameters on querySelector*() 
and matchesSelector() methods for supplying contextual reference 
elements (that match :scope).


Basically, for the simple case, it works as illustrated in these examples:

elm.querySelector(":scope>p");
document.querySelectorAll(":scope>p", elm);
document.querySelectorAll(":scope>p", [elm1, elm2]);

To provide the functionality of JS libraries supporting implied scope 
selectors, you first create a SelectorExpression object like this:


document.createSelector(">em,>strong", true);

That object can then be passed to either the querySelector*() or 
matchesSelector() methods.


The effect of this is basically that JavaScript libraries can mostly use 
document.createSelector(str, true) as a direct replacement their own 
custom selector parsing libraries (except for the cases where they're 
using custom pseudo-classes not supported by the browser)


One possible modification I'm considering is introducing a separate 
factory method for creating implied scope selectors: 
createScopedSelector(selector); rather than using a boolean parameter.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

ISSUE-75 and ISSUE-91: closing

[Anne van Kesteren]

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  
specifications at this point.



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

ISSUE-77: loadend

[Anne van Kesteren]

I'm closing ISSUE-77 because the loadend attribute has been part of  
XMLHttpRequest Level 2 for a while now and when it is supposed to be  
dispatched is defined too. The final details depend on the progress events  
specification but that goes for all events.



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

[widgets] Widgets test creation event

[Marcos Caceres]

Hi All,
Firstly, as editor, I want to personally say thanks to everyone that
participated in creating tests for P&C 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
the testing workshop. I assume a short report will be created?

In the meantime, it would be really helpful to know:

Apart from P&C, which other specs were tested?

Is test-suite-problems.txt [1] up to date and what is the purpose of
that file? Are those things that I need to fix or were they fixed
already?

When will the tests from wgt.webvm.net be moved over to the W3C?

Kind regards,
Marcos

[1] http://dev.w3.org/2006/waf/widgets/tests/test-suite-unstable.xml

-- 
Marcos Caceres
http://datadriven.com.au

Re: [selectors-api] Scoped Selectors

[Sean Hogan]

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 check if the :scope pseudo-class is available, use:

try { document.body.matchesSelector(":scope", document.body); }
catch (error) { /* not supported */ }

 OR

try { document.querySelector(":scope", document.body); }
catch (error) { /* not supported */ }

Sorry. Replace document.body with document.documentElement. That should 
be more efficient for the querySelector test.

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

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


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

[Anne van Kesteren]

On Fri, 25 Sep 2009 11:38:08 +0200, Sam Ruby   
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?

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.



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

Re: skipping and ignoring

[Marcos Caceres]

2009/9/24 Robin Berjon :
> On Sep 23, 2009, at 16:51 , Marcos Caceres wrote:
>>>
>>> But instead of ignored it says skipped — and it's not clear
>>> whether skipped has the same meaning.
>>
>> Good point. The second must not be processes because it is not the
>> first. It don't matter that is serviceable. It might just be that I
>> used ignore where skip was intended.
>
> That's not a very strong versioning approach.
>
>>> If the second element is not taken into account, then we have a potential
>>> problem with forward compatibility. Let's imagine that we have v2 out, for
>>> which the following is correct:
>>>
>>>  
>>>  
>>>
>>> Clearly the desired behaviour is for v2 runtimes to process the first, and
>>> v1 runtimes to fallback to the second.
>>
>> IMO the correct behavior would be for src attributes to take URIs and
>> for the second to be skipped. However, I'm sure you can dream up other
>> examples.
>
> Yes, I can.
>
>> The "only ever use the first, even if b0rked" behavior is based on
>> HTML's behavior (particularly the  element). I'm happy to break
>> ranks with HTML parsing if that is what the WG thinks would be best.
>> However, it's a pretty big change to the parsing model, but if it
>> future proofs us, then it might be worth it.
>
> HTML has that behaviour to unify the mess that browsers are — there's a 
> rationale there. We don't have to stick to the same thing because we really 
> don't have that baggage. And thankfully this affects not at all the parsing 
> model, but only processing — which is a lot easier.
>
> Furthermore I'm not convinced it's a change — we'd have to ask implementers 
> which one they picked.

It's a change.

>>> The same issue applies to other elements that refer to the skip/ignore
>>> distinction. We believe that some editorial improvements to those
>>> definitions would be welcome.
>>
>> Agreed. I'll work on improving those but that depends on if we change
>> the parsing behavior or not to match what you suggested above.
>
> The definitions need to be improved either way. I don't have a strong opinion 
> as to whether the change should go through or not so long as it's clarified. 
> The modification concerns cases that aren't all that common. I have a 
> preference for the more versioning-friendly approach of just skipping (which 
> is also slightly simpler to implement since you don't need to remember 
> anything). But if it risks being considered substantial I don't want it.
>

Well, you can easily see how substantial it is given the number of
tests that have been written into the test suite to specifically test
this behavior (use the first, skip the rest).

Now I am concerned about screwing forward comparability. Personally, I
want the format to be as forward compatible as possible.

I'll see if I can check what Windows Mobile 6.5 does (I think PPK has
a Windows Mobile phone) and also check what Opera's internal
implementation does.

Until then, unsure how to proceed:(

Kind regards,
Marcos

-- 
Marcos Caceres
http://datadriven.com.au

Re: [selectors-api] Scoped Selectors

[Sean Hogan]

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 pseudo-class is available, use:

try { document.body.matchesSelector(":scope", document.body); }
catch (error) { /* not supported */ }

 OR

try { document.querySelector(":scope", document.body); }
catch (error) { /* not supported */ }


Now, querySelector*() can't accept selectors with implied :scope because 
while "> em" is unambiguously ":scope > em", "p em" would become 
ambiguous. (is it "p em" or ":scope p em")

So we need a new method, such as queryScopedSelector*().
element.querySelector*() limits selection to descendants of elements, 
and element.queryScopedSelector*() should be consistent.
If element is the scope then element.queryScopedSelector*("~p") will 
return no elements.
If we want to support sibling queries then we need to provide a scope 
explicitly, so:


   element.parentNode.queryScopedSelector*("~p", element);

Notes:
1. I don't think browsers should provide queryScopedSelector*()
2. I think :context is a better name than :scope
3. If the context argument of these methods could be an element or a 
NodeList it might satisfy some of the other feature requests.




Lachlan Hunt wrote:

Hi,
   I'm trying to find a suitable solution for the scoped selector
issues, but figuring out what the most suitable API is proving 
challenging.



*Use Cases*

1. JS libraries like JQuery and others, accept special selector 
strings beginning with combinators. e.g. ">em,+strong". These 
libraries behave as if there was a selector that matched the context 
node.


e.g. In JQuery:

$("+p", elm);

This would select the p element that is a sibling of elm.

2. It would be useful to be able to check if an a given element 
matches a selector in relation to a specified reference element 
(:scope).  For example, check if an event target is a sibling of a 
specific element, and if the parent element has a specifc class name set.


e.g. Matches the selector: ".foo>:scope~input[type=text]"

This may be particularly useful for event delgation.

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 all of the nodes in 
the collection, running the query on each of them and then merging the 
results.



*Problems*

1. Need a way to allow the browser to parse implicitly scoped 
selectors beginning with combinators and imply the presence of :scope 
before each in the group.


2. Need to allow :scope to be used within the selector strings, and 
specify one or more scope elements that will be matched by :scope.  
This needs to be useable with all of the querySelector(), 
querySelectorAll() and matchesSelector() methods, or others with 
equivalent functionality.


3. Ideally, there would be an easy, reliable way for scripts to test 
if the implementation supports scoped selectors (at least, implicitly 
scoped selectors. Those using :scope could only be discovered by 
capturing the SYNTAX_ERR exception)  For legacy browsers that don't, 
they can fall back to their own selector engines.



*Possible Solutions*

1. Define a Selector object that can be used to parse and store a
selector, and which can handle pre-parsing the selector and
specifying the scope elements upon creation.  This selector object
can then be passed anywhere that accepts a selector string. (This is
basically part of the createSelector() and Selector interface
proposal from earlier).

2. Add parameters to the querySelector(), querySelectorAll() and
matchesSelector() methods for:
a. Indicating whether the selectors parameter should be processed
   with an implied scope.
b. Specifying one or more reference elements that would match :scope.

3. Create new scoped versions of the existing methods that accept one
or more reference elements that would match the implied scope.
Add an optional parameter to the existing querySelector*() methods
that would Allow one or more reference elements to be specified to
match the explicit use of :scope in the selector.


Option 2 doesn't provide an easy way to detect browser support.  
Option 3 creates an additional queryScopedSelector*() and 
matchesScopedSelector() methods, but this could get quite verbose if 
we also add equivalent NS methods to handle the namespace issue, to 
both the scoped and non-scoped versions.  This would create an 
unreasonable number of different methods that would make understanding 
the API quite complex.  Option 1 is syntactically messy, and requires 
the creation of a new object just to handle a scoped select

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

[Sam Ruby]

On Fri, Sep 25, 2009 at 5:57 AM, Anne van Kesteren  wrote:
> On Fri, 25 Sep 2009 11:38:08 +0200, Sam Ruby  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: CfC: to publish the FPWD of the Web Simple Database API spec; deadline 25 September

[Charles McCathieNevile]

On Fri, 18 Sep 2009 13:25:59 +0200, Arthur Barstow   
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 response is preferred and encouraged  
and silence will be assumed to be assent. The deadline for comments is  
September 25.


Opera is in favour of publishing a draft.

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

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

[Sam Ruby]

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.


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.


- Sam Ruby

Re: Progress Events - Credits Edits

[Charles McCathieNevile]

On Fri, 25 Sep 2009 05:17:59 +0200, Bjoern Hoehrmann   
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 Höhrmann]

Thanks, noted.

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com