Re: What type should .findAll return

[Jonas Sicking]

On Fri, Nov 11, 2011 at 5:59 PM, Tab Atkins Jr.  wrote:
> On Fri, Nov 11, 2011 at 5:52 PM, Rick Waldron  wrote:
>> Right, but I'm saying: why create yet more "stuff" in the DOM?
>>
>>  findAll will return a "NodeArray" while querySelectorAll and friends return 
>> static and live NodeLists? No thanks.
>
> I'm not sure what you would prefer.  Make findAll return an Array? (We
> miss out on a *lot* of cool and useful stuff we could do.)  Make
> findAll return immutable live NodeLists? (Ditto, but for different
> reasons.)  Change qSA to return a NodeArray or Array? (Would be nice,
> but probably not doable for compat reasons.)

Actually, if we add .item to NodeArray then it's entirely possible
that we can make qSA return a NodeArray. I'm not entirely convinced
that's worth it though.

/ Jonas

Re: What type should .findAll return

[Tab Atkins Jr.]

On Fri, Nov 11, 2011 at 5:52 PM, Rick Waldron  wrote:
> Right, but I'm saying: why create yet more "stuff" in the DOM?
>
>  findAll will return a "NodeArray" while querySelectorAll and friends return 
> static and live NodeLists? No thanks.

I'm not sure what you would prefer.  Make findAll return an Array? (We
miss out on a *lot* of cool and useful stuff we could do.)  Make
findAll return immutable live NodeLists? (Ditto, but for different
reasons.)  Change qSA to return a NodeArray or Array? (Would be nice,
but probably not doable for compat reasons.)

~TJ

Re: What type should .findAll return

[Rick Waldron]

Right, but I'm saying: why create yet more "stuff" in the DOM?

 findAll will return a "NodeArray" while querySelectorAll and friends return 
static and live NodeLists? No thanks.

/Rick 

On Nov 11, 2011, at 8:38 PM, "Tab Atkins Jr."  wrote:

> On Fri, Nov 11, 2011 at 5:35 PM, Rick Waldron  wrote:
>> Any DOM NodeList/"NodeArray" could be converted into a "real" array by 
>> passing to Array.from( array like )
>> 
>> http://wiki.ecmascript.org/doku.php?id=strawman:array_extras
>> 
>> Avoids creating yet another DOM "NodeThing".
> 
> Jonas explains very well why we don't want a "real" Array, but rather
> something that just acts like an Array.
> 
> ~TJ

Re: What type should .findAll return

[Tab Atkins Jr.]

On Fri, Nov 11, 2011 at 5:35 PM, Rick Waldron  wrote:
> Any DOM NodeList/"NodeArray" could be converted into a "real" array by 
> passing to Array.from( array like )
>
> http://wiki.ecmascript.org/doku.php?id=strawman:array_extras
>
> Avoids creating yet another DOM "NodeThing".

Jonas explains very well why we don't want a "real" Array, but rather
something that just acts like an Array.

~TJ

Re: What type should .findAll return

[Rick Waldron]

Any DOM NodeList/"NodeArray" could be converted into a "real" array by passing 
to Array.from( array like )

http://wiki.ecmascript.org/doku.php?id=strawman:array_extras

Avoids creating yet another DOM "NodeThing".

/Rick 

On Nov 11, 2011, at 6:57 PM, Jonas Sicking  wrote:

> On Fri, Nov 11, 2011 at 3:07 PM, Allen Wirfs-Brock
>  wrote:
>> 
>> On Nov 11, 2011, at 2:16 PM, Jonas Sicking wrote:
>> 
>>> On Fri, Nov 11, 2011 at 1:22 PM, Allen Wirfs-Brock
>>>  wrote:
 
 BTW, I think that either the immutable or mutable approach would work.  
 However, since the collection is not "live" I don't see why you would 
 really care whether or not a client mutated it.  If they want to process 
 it by deleting elements after they are examined, so what?
>>> 
>>> Exactly, this is why I'm proposing that it should be mutable.
>>> 
>>> This does still leave the problem of making Array.filter(myNodeArray,
>>> function(el) { ... }) "work" though. I.e. I think we'd like it to
>>> return a NodeArray rather than a plain Array.
>> 
>> This is a problem for ES<=5.  Filter and all the other similar 
>> Array.prototype functions are specified to produce an object created as if 
>> by calling: new Array();
>> 
>> I have a scheme that we can probably get in place for ES.next that would 
>> allow filter and friends to produce NodeArray's for you, but I don't see how 
>> that helps right now.
> 
> Well, if we can get implementations to implement this new scheme for
> the existing filter-like functions at the same time as they implement
> .findAll, then we should be golden.
> 
>>> More importantly, we want myNodeArray.filter(function(el){ ... }) to
>>> return a NodeArray. This would be doable by putting a special version
>>> of filter on NodeArray.prototype which would shadow
>>> Array.prototype.filter.
>> 
>> 
>> It isn't just filter that creates new instances that you would probably want 
>> to be NodeArrays. Also at least(I might have missed other when I just 
>> checkeds): concat, slice, splice, map
> 
> Indeed, I was just using filter as an example.
> 
>> Over-riding them explicitly for NodeArray would be an immediate fix, but 
>> wouldn't solve the problem for future additions to Array.prototype.  
>> However, if you assume that ES.next is going to provide the needed extension 
>> mechanism then you should also assume that it will use it for any new 
>> Array.prototype methods and they should pretty much just work.
> 
> Indeed. If we went down this path we would have to continuously update
> the spec to make NodeArray override any filter-like methods that are
> added to Array.
> 
>>> This would make myNodeArray.filter "work", but
>>> not Array.filter.
>> 
>> An inherent problem with this approach. But if your NodeArrays supplies 
>> correctly working over-rides there is probably little reason somebody would 
>> try to use the Array.prototype versions  with NodeArrays.
> 
> Note that I was saying Array.filter and not Array.prototype.filter. My
> assumption was that if people call Array.prototype with an Array as
> the first argument, they would also do so with a NodeArray as first
> argument.
> 
>> I don't see a way around this short of modifying the specification of the 
>> Array.prototype methods.  That seems like a job for ES.next rather than a 
>> DOM spec.
> 
> Definitely, hence the cc :)
> 
>>> I'm happy to start a separate thread on es-discuss about this, but I'm
>>> worried that it'll fragment the current thread.
>> 
>> In theory, public-script-coord exists for exactly this sort of discussion 
>> and the ESdiscuss people who care should be subscripted. Rather than 
>> starting a new thread, perhaps should should just post to es-discuss a 
>> pointer to this thread.
> 
> Will do!
> 
> / Jonas
> 

RE: [indexeddb] Keypath attribute lookup question

[Israel Hilerio]

On Wednesday, November 09, 2011 4:47 PM, Joshua Bell wrote:
>On Wed, Nov 9, 2011 at 3:35 PM, Israel Hilerio  wrote:
>>In section "4.7 Steps for extracting a key from a value using a key path" 
>>step #4 it states that:
>>* If object does not have an attribute named attribute, then skip the rest of 
>>these steps and no value is returned.

>>We want to verify that the attribute lookup is taking place on the immediate 
>>object attributes and the prototype chain, correct?

>My reading of the spec: In 3.2.5 the description of add (etc) says that 
>the method creates a structured clone of value then runs the store 
>operation with that cloned value. The steps for storing a record (5.1) are the 
>context where the key path is evaluated, which would imply that it is done 
>against the cloned value. The structured cloning algorithm doesn't walk the 
>prototype chain, so this reading would indicate that the attribute lookup only 
>occurs against the immediate object.

>I believe there's a spec issue in that in section 3.2.5 the list of 
>cases where DataError is thrown are described without reference to the 
>value parameter (it's implied, but not stated), followed by "Otherwise 
>this method creates a structured clone of the value parameter". That 
>implies that these error cases apply to the value, whereas the storage 
>operations apply to the structured clone of the value. (TOCTOU?)

>We (Chrome) believe that the structured clone step should occur prior to the 
>checks and the cloned value be used for these operations.

What you're saying makes sense!  The scenario we are worried about is the one 
in which we want to be able to index on the size, type, name, and 
lastModifiedDate attributes of a File object.  Given the current SCA 
serialization logic, I'm not sure this is directly supported.  This could 
become an interoperable problem if we allow these properties to be serialized 
and indexed in our implementation but FF or Chrome don't. We consider Blobs and 
Files to be host objects and we treat those a little different from regular 
JavaScript Objects. 

We feel that the ability to index these properties enables many useful 
scenarios and would like to see all browsers support it.

What do you and Jonas think?

Israel

RE: "We just ran out of time ..." [Was: Re: Component Model f2f: Actionable things]

[Adrian Bateman]

On Tuesday, November 08, 2011 5:37 AM, Robin Berjon wrote:
> On Nov 3, 2011, at 05:38 , Arthur Barstow wrote:
> > Well, we may get together more frequently than just the annual TPAC meeting
> week. If folks think that would be useful (e.g. in 6 months), please speak up
> and we can take it from there. Otherwise, WebApps' next f2f meeting is during
> the 2012 TPAC meeting in Lyon, FR Oct 29 - Nov 2.
> 
> I think that it would be useful for WebApps to get together more frequently
> (without overdoing it). I'm a big fan of async work in general, but getting
> people in the same room once in a while helps bang long standing issues into
> shape and also release whatever pent up tension may have been building.

I agree. At the W3C Offline workshop last Saturday there was also a sense from
some of the participants that some kind of get together, perhaps in BarCamp 
style,
would be helpful to, at the very least, allow people to share their concerns and
get requirements on the table. While we're not chartered to make decisions
synchronously, synchronous communication can help to remove misunderstandings.
Perhaps in 6 months (twice a year) would be reasonable.

On Saturday, November 05, 2011 11:03 AM, James Hawkins wrote:
> Agreed.  What little time we did have was quite productive, and getting to 
> know
> non-Google WG members outside of a work context was extremely helpful for me.

I think getting to know each other better is also helpful in improving how we
all work together.


Cheers,

Adrian.

RE: Identifying "Test Spec Editors"; deadline Nov 11

[Adrian Bateman]

On Friday, November 04, 2011 4:59 PM, Arthur Barstow wrote:
> One of the topics discussed this week was to designate a "Test Spec
> Editor(s)" for each of our specs.

We're supportive of this idea.

> (BTW, the title of "Test Spec Editor" is a bit of a straw-man, so
> proposals for other titles are also welcome.)

I wonder if Test Suite Facilitator (or similar) is a better title. We use 
"Facilitator"
in HTML WG and I think it may be more of a coordination role than a person that 
does
all the editing work of the test suite (that's how it seems to work in HTML at 
the
moment).

Cheers,

Adrian.

Re: What type should .findAll return

[Allen Wirfs-Brock]

On Nov 11, 2011, at 3:57 PM, Jonas Sicking wrote:

> On Fri, Nov 11, 2011 at 3:07 PM, Allen Wirfs-Brock
>  wrote:
>> 
>>> ...
>> 
>> This is a problem for ES<=5.  Filter and all the other similar 
>> Array.prototype functions are specified to produce an object created as if 
>> by calling: new Array();
>> 
>> I have a scheme that we can probably get in place for ES.next that would 
>> allow filter and friends to produce NodeArray's for you, but I don't see how 
>> that helps right now.
> 
> Well, if we can get implementations to implement this new scheme for
> the existing filter-like functions at the same time as they implement
> .findAll, then we should be golden.

the scheme depends upon other Es.next features including private names. It 
isn't clear that if you start pulling that thread how far it extends. But 
perhaps, it might fly...


> ...
> 
>>> This would make myNodeArray.filter "work", but
>>> not Array.filter.
>> 
>> An inherent problem with this approach. But if your NodeArrays supplies 
>> correctly working over-rides there is probably little reason somebody would 
>> try to use the Array.prototype versions  with NodeArrays.
> 
> Note that I was saying Array.filter and not Array.prototype.filter. My
> assumption was that if people call Array.prototype with an Array as
> the first argument, they would also do so with a NodeArray as first
> argument.

Array.filter and friends (in contrast to Array.prototype.filter) are not in ES5 
and, so far, have not made the ES.next cut.  Personally, I'm not a bit fan of 
them for exactly this reason.  If you are building object-oriented "class" 
hierarchies you want to use methods, not global function that can't easily be 
virtually dispatched.  

Allen

Re: What type should .findAll return

[Brendan Eich]

On Nov 11, 2011, at 3:07 PM, Allen Wirfs-Brock wrote:

>> I'm happy to start a separate thread on es-discuss about this, but I'm
>> worried that it'll fragment the current thread.
> 
> In theory, public-script-coord exists for exactly this sort of discussion and 
> the ESdiscuss people who care should be subscripted. Rather than starting a 
> new thread, perhaps should should just post to es-discuss a pointer to this 
> thread.
> 

Turns out (thanks Jake!) we do have an es-discuss thread of interest:

https://mail.mozilla.org/pipermail/es-discuss/2011-November/018242.html

/be

Re: What type should .findAll return

[Jonas Sicking]

On Fri, Nov 11, 2011 at 3:07 PM, Allen Wirfs-Brock
 wrote:
>
> On Nov 11, 2011, at 2:16 PM, Jonas Sicking wrote:
>
>> On Fri, Nov 11, 2011 at 1:22 PM, Allen Wirfs-Brock
>>  wrote:
>>>
>>> BTW, I think that either the immutable or mutable approach would work.  
>>> However, since the collection is not "live" I don't see why you would 
>>> really care whether or not a client mutated it.  If they want to process it 
>>> by deleting elements after they are examined, so what?
>>
>> Exactly, this is why I'm proposing that it should be mutable.
>>
>> This does still leave the problem of making Array.filter(myNodeArray,
>> function(el) { ... }) "work" though. I.e. I think we'd like it to
>> return a NodeArray rather than a plain Array.
>
> This is a problem for ES<=5.  Filter and all the other similar 
> Array.prototype functions are specified to produce an object created as if by 
> calling: new Array();
>
> I have a scheme that we can probably get in place for ES.next that would 
> allow filter and friends to produce NodeArray's for you, but I don't see how 
> that helps right now.

Well, if we can get implementations to implement this new scheme for
the existing filter-like functions at the same time as they implement
.findAll, then we should be golden.

>> More importantly, we want myNodeArray.filter(function(el){ ... }) to
>> return a NodeArray. This would be doable by putting a special version
>> of filter on NodeArray.prototype which would shadow
>> Array.prototype.filter.
>
>
> It isn't just filter that creates new instances that you would probably want 
> to be NodeArrays. Also at least(I might have missed other when I just 
> checkeds): concat, slice, splice, map

Indeed, I was just using filter as an example.

> Over-riding them explicitly for NodeArray would be an immediate fix, but 
> wouldn't solve the problem for future additions to Array.prototype.  However, 
> if you assume that ES.next is going to provide the needed extension mechanism 
> then you should also assume that it will use it for any new Array.prototype 
> methods and they should pretty much just work.

Indeed. If we went down this path we would have to continuously update
the spec to make NodeArray override any filter-like methods that are
added to Array.

>> This would make myNodeArray.filter "work", but
>> not Array.filter.
>
> An inherent problem with this approach. But if your NodeArrays supplies 
> correctly working over-rides there is probably little reason somebody would 
> try to use the Array.prototype versions  with NodeArrays.

Note that I was saying Array.filter and not Array.prototype.filter. My
assumption was that if people call Array.prototype with an Array as
the first argument, they would also do so with a NodeArray as first
argument.

> I don't see a way around this short of modifying the specification of the 
> Array.prototype methods.  That seems like a job for ES.next rather than a DOM 
> spec.

Definitely, hence the cc :)

>> I'm happy to start a separate thread on es-discuss about this, but I'm
>> worried that it'll fragment the current thread.
>
> In theory, public-script-coord exists for exactly this sort of discussion and 
> the ESdiscuss people who care should be subscripted. Rather than starting a 
> new thread, perhaps should should just post to es-discuss a pointer to this 
> thread.

Will do!

/ Jonas

Re: What type should .findAll return

[Allen Wirfs-Brock]

On Nov 11, 2011, at 2:16 PM, Jonas Sicking wrote:

> On Fri, Nov 11, 2011 at 1:22 PM, Allen Wirfs-Brock
>  wrote:
>> 
>> BTW, I think that either the immutable or mutable approach would work.  
>> However, since the collection is not "live" I don't see why you would really 
>> care whether or not a client mutated it.  If they want to process it by 
>> deleting elements after they are examined, so what?
> 
> Exactly, this is why I'm proposing that it should be mutable.
> 
> This does still leave the problem of making Array.filter(myNodeArray,
> function(el) { ... }) "work" though. I.e. I think we'd like it to
> return a NodeArray rather than a plain Array.

This is a problem for ES<=5.  Filter and all the other similar Array.prototype 
functions are specified to produce an object created as if by calling: new 
Array();

I have a scheme that we can probably get in place for ES.next that would allow 
filter and friends to produce NodeArray's for you, but I don't see how that 
helps right now.

> 
> More importantly, we want myNodeArray.filter(function(el){ ... }) to
> return a NodeArray. This would be doable by putting a special version
> of filter on NodeArray.prototype which would shadow
> Array.prototype.filter.


It isn't just filter that creates new instances that you would probably want to 
be NodeArrays. Also at least(I might have missed other when I just checkeds): 
concat, slice, splice, map

Over-riding them explicitly for NodeArray would be an immediate fix, but 
wouldn't solve the problem for future additions to Array.prototype.  However, 
if you assume that ES.next is going to provide the needed extension mechanism 
then you should also assume that it will use it for any new Array.prototype 
methods and they should pretty much just work.

> This would make myNodeArray.filter "work", but
> not Array.filter.

An inherent problem with this approach. But if your NodeArrays supplies 
correctly working over-rides there is probably little reason somebody would try 
to use the Array.prototype versions  with NodeArrays.

I don't see a way around this short of modifying the specification of the 
Array.prototype methods.  That seems like a job for ES.next rather than a DOM 
spec.

> 
> I'm happy to start a separate thread on es-discuss about this, but I'm
> worried that it'll fragment the current thread.

In theory, public-script-coord exists for exactly this sort of discussion and 
the ESdiscuss people who care should be subscripted. Rather than starting a new 
thread, perhaps should should just post to es-discuss a pointer to this thread.

Allen

Re: What type should .findAll return

[Jonas Sicking]

On Fri, Nov 11, 2011 at 1:22 PM, Allen Wirfs-Brock
 wrote:
> However, if you want the object to be mutable and to act like a real array, 
> then it has to have the array specialness.  The specialness comes, not from 
> the [[Class]] property but from its alternative definitions of 
> [[DefineOwnProperty]] (see ES5.1 spec. 15.4.5.1).

The Array-like thing discussed in this thread is going to be mutable.

> In ES.next a JS programmer will be able to easily define such an object.  But 
> for ES5 it takes special implementation level intervention.    Since this 
> capability is going to ultimately be in ES.next I don't see why you couldn't 
> do it now, assuming the the engine implementors are all willing to cooperate.
>
> Basically, you would specify that the [[Prototype]] of the instances inherits 
> from Array.prototype and that the instances use the [[DefineOwnProperty]] 
> specification from ES5 section 15.4.5.1.
>
> In either case, you would be specifying a new kind of ES "native object" 
> rather than a "host object'.
>
> BTW, I think that either the immutable or mutable approach would work.  
> However, since the collection is not "live" I don't see why you would really 
> care whether or not a client mutated it.  If they want to process it by 
> deleting elements after they are examined, so what?

Exactly, this is why I'm proposing that it should be mutable.

This does still leave the problem of making Array.filter(myNodeArray,
function(el) { ... }) "work" though. I.e. I think we'd like it to
return a NodeArray rather than a plain Array.

More importantly, we want myNodeArray.filter(function(el){ ... }) to
return a NodeArray. This would be doable by putting a special version
of filter on NodeArray.prototype which would shadow
Array.prototype.filter. This would make myNodeArray.filter "work", but
not Array.filter.

I'm happy to start a separate thread on es-discuss about this, but I'm
worried that it'll fragment the current thread.

/ Jonas

Re: Last Call Comments on Web Storage

[Charles Pritchard]

On 11/11/2011 12:24 PM, Tab Atkins Jr. wrote:

On Fri, Nov 11, 2011 at 11:54 AM, ashok malhotra
  wrote:

o One use of local storage might be to store personal preferences,
such as travel preferences or personal information such as medical
history.  In such cases, you may want to allow several sites access
to this information (I prefer aisle seats; I would like to stay at
Marriott hotels.)  Local storage is governed by the same-origin
policy but in some cases it may be wise to carefully relax this and
allow multiple sites to access the data.

It seems that these are *not* the sort of thing you want to leave to
ad-hoc data storage.  Instead, this should be approached from a
standardization perspective.


This is something being examined with web intents, I'm sure, as an 
extension of the postMessage concept. AFAIK, postMessage works
just fine for this. Site (a)  receives messages and checks storage, and 
sends responses, Site (b) includes Site (a) in an iframe. Everybody wins.
More exciting is that postMessage can work with typed arrays and it 
seems blob uris can be shared across sites.


I'd expect something to catch-on, in the open market, much as 
gravatar.com has.

I think this is going to be simpler than OpenID in the long run.



o When updating local storage, transactional semantics or, at
least, a transactional option would be desirable.

IndexedDB is intended to be the "better" version of localStorage, and
utilizes transactional semantics.


IndexedDB is certainly better than localStorage.
It'd be nice if IDB had a default key/value store already setup or a 
shortcut to create one.
It takes a good 10 lines to prepare things for a simple key/value table, 
where localStorage does not.


Those are for: open, version, create, transaction, error callbacks. 
They're all necessary of course,
for heavy work. But as a replacement for localStorage, it's an 
additional 40 lines of code.




o It would be very useful to be able to map from other forms of
data storage, such as RDF or Relational data to RDF.  Mapping from
RDF would be simple.  Mapping from Relational is more challenging.

What's the use-case for taking in RDF and storing it in localStorage?
One can always just store RDF directly as a localStorage *value*.



I agree, these seem like serialization issues, nothing much related to 
data storage.

I am looking forward to creative uses of IDB to handle relational data.



o If local storage is used to store personal preferences or
personal information it would be very useful to be able to move it
from one device to another, say my laptop to my phone.

This is left to either the app or the browser to achieve.


There's certainly a big gray area on how UAs are going to approach this. 
Some part

of this profile / preferences talk may belong in the DAP working group.

As a tangent:

Will UAs offer remote storage of localStorage, IndexedDB, applciation 
cache and the like?
I've certainly read from engineers that backup is something that 
applications can do better than any general mechanism.


Even with poor efficiency, it might be a value-added service that UAs 
decide to jump into.
In the meantime, big vendors are already offering "cloud" storage for 
application vendors.




o Question: The values in the key-value pairs are typed as strings
but I presume they can be URIs and be interpreted as URIs.  Or they
can be large files.  Perhaps this could be clarified.

They are always strings, but of course they can represent any type of
data that can be stringified and revived.  The application can choose
to interpret them as urls or files if it wishes.  However, storing
large files is better done through the FileSystem API or through
IndexedDB.


Is IndexedDB working with array buffers / blobs yet?

It's been a rough few years with local storage; sending base64 encoded 
binary strings into a UTF-16 encoded database.

I can't even use the browser's btoa and atob methods.


-Charles

Re: What type should .findAll return

[Allen Wirfs-Brock]

Note that the only specialness of Array instances relates to what happens when 
you add new array elements or dynamically change the value of the "length" 
property.

If the array instance is immutable you can't do any of those things so its 
specialness essentially disappears.

So, if you want the objects to be an immutable, array-like object that inherits 
from array.prototype through an intermediate prototype there really is no 
problem.  A JS programmer could express this today in ES5:

var DOMFindResultProto = Object.create(Array.prototype);  //make it inherit 
from Object.prototype
DOMFondResultProto.someMethod = function O() { ...};
//other prototype methods
//...

function FindResultFactory(nodes) {
   var obj = Object.create(DOMFindResultProto);
   for (var i=0; i On 11/11/11 10:05 PM, Jonas Sicking wrote:
>> In other words, the returned object is exactly what you'd get if you did:
>> 
>> a = new Array;
>> a.__proto__ = [some type].prototype;
>> [some type].prototype.__proto__ = Array.prototype;
> 
> For what it's worth, at least some JITs deoptimize |a| if you do that. We'd 
> probably need to do something to make sure that _doesn't_ happen in this 
> case, right?
> 
> -Boris
> 

Re: What type should .findAll return

[Allen Wirfs-Brock]

On Nov 11, 2011, at 7:46 AM, Tab Atkins Jr. wrote:

> On Fri, Nov 11, 2011 at 1:05 AM, Jonas Sicking  wrote:
>> And to ensure that the object acts as much as possible as an array it
>> should also have it's [[Class]] set to that of an array. This has
>> subtle effects on a number of functions. For example it affects what
>> Object.toString() and Array.isArray returns, it affects how
>> Array.concat behaves, and it affects the JSON serializer.
> 
> Could you point me to an explanation of what [[Class]] represents in
> ecmascript?  It's a little hard to search for.
> 

this turns out to not be such a simple question see 
https://docs.google.com/document/d/1sSUtri6joyOOh23nVDfMbs1wDS7iDMDUFVVeHeRdSIw/edit?authkey=CI-FopgC
 

[[Class]] has been (mis-??)used for many things.  This is why we want to 
cleanup up for the future.

Allen 

Re: What type should .findAll return

[Brendan Eich]

On Nov 11, 2011, at 10:44 AM, Jonas Sicking wrote:

> On Fri, Nov 11, 2011 at 10:06 AM, Brendan Eich  wrote:
>> On Nov 11, 2011, at 1:05 AM, Jonas Sicking wrote:
>> 
>>> And to ensure that the object acts as much as possible as an array it
>>> should also have it's [[Class]] set to that of an array.
>> 
>> This is not something to do lightly -- at least cross-post the first message 
>> to es-disc...@mozilla.org and set reply-to followups-to. Cc'ing Allen.
>> 
>> Note that [[Class]] is going away in ES.next.
>> 
>> The internal methods and properties of ECMA-262 are not arbitrary extension 
>> points for other specs to use without consultation.
> 
> Yup, that's why i cc'ed public-script-coord.

That's why I'm asking you to cc: es-discuss. I expect Allen will catch up with 
this thread, but you may get more prompt responses from various people by using 
es-discuss for the initial message.


> Note that what I'm suggesting in this thread is to create a real
> normal Array. "Just" one with an extra object inserted in it's
> prototype chain.

That's not a "real normal Array" then. Boris mentioned one issue 
(optimization). Let's call it an extended array. ES.next should support 
user-extended arrays via the <| operator, so this isn't something "bad", but 
it's not exactly an array.


> So if [[Class]] is going away in ES.next that shouldn't be a problem.
> Whatever will happen to Arrays when that happens, should happen to
> NodeArrays.

Allen analyzed how [[Class]] is used in ES1-5, and broke down the cases. Some 
of these change to a different or more generic way of discriminating on 
"class". Others still need an internal property. Notable among the latter is 
the string name disclosed by Object.prototype.toString.call(anArray).

The deeper issue for arrays is the custom [[DefineOwnProperty]] (ES5) or 
[[Put]] (ES1-3) that maintains length to be one greater than greatest index 
provided the index is < 2^31 - 1.


> The separate issue of making .filter and friends work can be solved in
> multiple ways. At least some of which require no changes to
> Array.filter if that is preferable from a language point of view.

This sounds right.

/be

[postmsg] Moving back to LC

[Arthur Barstow]

I'd like to get Web Messaging moving on the REC track but it currently 
is blocked by one open bug:


* 13686 - Remove the special case from onmessage (to call start())

There has been considerable debate (e.g. re-opened six times) but some 
of the later comments kinda' indicate there may be some movement toward 
convergence.


How can we move forward on getting consensus on this bug?

-Thanks, AB

13686 

Re: Last Call Comments on Web Storage

[Tab Atkins Jr.]

On Fri, Nov 11, 2011 at 11:54 AM, ashok malhotra
 wrote:
> o One use of local storage might be to store personal preferences,
> such as travel preferences or personal information such as medical
> history.  In such cases, you may want to allow several sites access
> to this information (I prefer aisle seats; I would like to stay at
> Marriott hotels.)  Local storage is governed by the same-origin
> policy but in some cases it may be wise to carefully relax this and
> allow multiple sites to access the data.

It seems that these are *not* the sort of thing you want to leave to
ad-hoc data storage.  Instead, this should be approached from a
standardization perspective.


> o When updating local storage, transactional semantics or, at
> least, a transactional option would be desirable.

IndexedDB is intended to be the "better" version of localStorage, and
utilizes transactional semantics.


> o It would be very useful to be able to map from other forms of
> data storage, such as RDF or Relational data to RDF.  Mapping from
> RDF would be simple.  Mapping from Relational is more challenging.

What's the use-case for taking in RDF and storing it in localStorage?
One can always just store RDF directly as a localStorage *value*.


> o If local storage is used to store personal preferences or
> personal information it would be very useful to be able to move it
> from one device to another, say my laptop to my phone.

This is left to either the app or the browser to achieve.


> o Question: The values in the key-value pairs are typed as strings
> but I presume they can be URIs and be interpreted as URIs.  Or they
> can be large files.  Perhaps this could be clarified.

They are always strings, but of course they can represent any type of
data that can be stringified and revived.  The application can choose
to interpret them as urls or files if it wishes.  However, storing
large files is better done through the FileSystem API or through
IndexedDB.

~TJ

Re: What type should .findAll return

[Boris Zbarsky]

On 11/11/11 10:05 PM, Jonas Sicking wrote:

In other words, the returned object is exactly what you'd get if you did:

a = new Array;
a.__proto__ = [some type].prototype;
[some type].prototype.__proto__ = Array.prototype;


For what it's worth, at least some JITs deoptimize |a| if you do that. 
We'd probably need to do something to make sure that _doesn't_ happen in 
this case, right?


-Boris

Last Call Comments on Web Storage

[ashok malhotra]

DISCLAIMER:  The opinions expressed below are mine and may not reflect the 
opinions of
my employer or the W3C TAG

Comments:

o One use of local storage might be to store personal preferences, such as 
travel
preferences or personal information such as medical history.  In such cases, 
you may
want to allow several sites access to this information (I prefer aisle seats; I 
would like
to stay at Marriott hotels.)  Local storage is governed by the same-origin 
policy but
in some cases it may be wise to carefully relax this and allow multiple sites 
to access
the data.

o When updating local storage, transactional semantics or, at least, a 
transactional
option would be desirable.

o It would be very useful to be able to map from other forms of data storage, 
such as RDF
or Relational data to RDF.  Mapping from RDF would be simple.  Mapping from 
Relational
is more challenging.

o If local storage is used to store personal preferences or personal 
information it would be
very useful to be able to move it from one device to another, say my laptop to 
my phone.

The last two comments involve tools built around the spec and not the spec 
itself.  Other tools
that would make local storage more useful and more convenient can be envisaged.

o Question: The values in the key-value pairs are typed as strings but I 
presume they can
be URIs and be interpreted as URIs.  Or they can be large files.  Perhaps this 
could be clarified.

[Bug 12859] An IDL block for window.postMessage is lacking from the W3C spec.

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12859

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||NEEDSINFO

--- Comment #7 from Ian 'Hixie' Hickson  2011-11-11 19:48:20 UTC 
---
NEEDSINFO is fine by me. My guess is that this was originally just referring to
the Window IDL block, but that's already in a W3C spec IIRC so it shouldn't be
an issue.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 12859] An IDL block for window.postMessage is lacking from the W3C spec.

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12859

Art Barstow  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #6 from Art Barstow  2011-11-11 19:41:10 UTC 
---
Ooops. I accidentally closed this bug so I am reopening it now.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 12859] An IDL block for window.postMessage is lacking from the W3C spec.

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12859

Art Barstow  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Art Barstow  2011-11-11 19:38:30 UTC 
---
Hixie - I just looked at this again and I agree it's not clear what IDL block
is/was missing (I don't recall what I was thinking last June).

Perhaps this should be Resolved as NeedsInfo. WDYT?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[XHR2] Disable new response types for sync XHR in Window context

[Olli Pettay]

Hi all,

I think we should strongly encourage web devs to move away from
sync XHR (in Window context, not in Workers). It is bad for UI
responsiveness.

Unfortunately sync XHR has been used quite often with the old
text/xml types. But maybe we could disable sync XHR for the new
types, and also make .response to throw if it is used with
sync XHR.

Comments?



-Olli


http://www.w3.org/Bugs/Public/show_bug.cgi?id=14773
https://bugzilla.mozilla.org/show_bug.cgi?id=701787
https://bugs.webkit.org/show_bug.cgi?id=72154

[Bug 14773] New: Investigate if synchronous XHR in window context should not support new XHR responseTypes

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14773

   Summary: Investigate if synchronous XHR in window context
should not support new XHR responseTypes
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: XHR 2.0
AssignedTo: ann...@opera.com
ReportedBy: olli.pet...@gmail.com
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


See also
https://bugzilla.mozilla.org/show_bug.cgi?id=701787
https://bugs.webkit.org/show_bug.cgi?id=72154
and WebApps mailing list

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[workers] Moving back to LC

[Arthur Barstow]

I'd like to get Web Workers moving on the REC track but it currently is 
blocked by two open bugs:


* 14086 "When performing AJAX type queries ..."

What, if anything, should we do with this bug?

Given it is marked as an "enhancement", does anyone consider this 
mandatory to address before publishing a LC? If yes, what is your 
proposed resolution?


Would anyone object to moving to LC/CR with this bug open?

* 14214 "missing definition of Transferable". This editorial bug can be 
fixed in a LC snapshot so I don't think it needs to block LC.


-AB

14086 
14214 

Re: What type should .findAll return

[Jonas Sicking]

On Fri, Nov 11, 2011 at 10:06 AM, Brendan Eich  wrote:
> On Nov 11, 2011, at 1:05 AM, Jonas Sicking wrote:
>
>> Hi All,
>>
>> So, we've debated a lot the exact syntax for .find/.findAll. However I
>> intentionally requested that we split out the discussions about return
>> type for .findAll to a separate thread. So I'm starting that thread
>> here.
>>
>> There are a few goals for the return'ed object that I've envisioned
>> based on discussions so far:
>>
>> 1. It should have at least all of the non-mutating Array methods on
>> it. Possibly the mutating methods too if we allow the returned object
>> to be mutable.
>> 2. It should have a object on the prototype chain where we can insert
>> functions that are specifically useful for lists of nodes. Examples
>> include .find/.findAll/.matchesSelector/.remove/.addEventListener
>> 3. It would be good if it had the Array prototype object on it's
>> prototype chain so that if Array.prototype was extended, it would
>> affect this object too.
>> 4. The object will *not* be live since live results from selector
>> matching is slow.
>>
>> Since the returned object won't be live, I don't see a reason to make
>> it immutable. Hence it seems like we could put Array.prototype on the
>> prototype chain which would immediately make all non-mutating as well
>> as mutating functions available on the object.
>>
>> We should also insert a new prototype object in the prototype chain.
>> Hence we end up with something like:
>>
>> object -> [some type].prototype -> Array.prototype -> Object.prototype.
>>
>> And to ensure that the object acts as much as possible as an array it
>> should also have it's [[Class]] set to that of an array.
>
> This is not something to do lightly -- at least cross-post the first message 
> to es-disc...@mozilla.org and set reply-to followups-to. Cc'ing Allen.
>
> Note that [[Class]] is going away in ES.next.
>
> The internal methods and properties of ECMA-262 are not arbitrary extension 
> points for other specs to use without consultation.

Yup, that's why i cc'ed public-script-coord.

Note that what I'm suggesting in this thread is to create a real
normal Array. "Just" one with an extra object inserted in it's
prototype chain.

So if [[Class]] is going away in ES.next that shouldn't be a problem.
Whatever will happen to Arrays when that happens, should happen to
NodeArrays.

The separate issue of making .filter and friends work can be solved in
multiple ways. At least some of which require no changes to
Array.filter if that is preferable from a language point of view.

Granted, it would be nice if Array.filter(elem.findAll(...),
function(element) { ... }) worked too, and that *would* require
changes to ES.

/ Jonas

Re: What type should .findAll return

[Brendan Eich]

On Nov 11, 2011, at 1:05 AM, Jonas Sicking wrote:

> Hi All,
> 
> So, we've debated a lot the exact syntax for .find/.findAll. However I
> intentionally requested that we split out the discussions about return
> type for .findAll to a separate thread. So I'm starting that thread
> here.
> 
> There are a few goals for the return'ed object that I've envisioned
> based on discussions so far:
> 
> 1. It should have at least all of the non-mutating Array methods on
> it. Possibly the mutating methods too if we allow the returned object
> to be mutable.
> 2. It should have a object on the prototype chain where we can insert
> functions that are specifically useful for lists of nodes. Examples
> include .find/.findAll/.matchesSelector/.remove/.addEventListener
> 3. It would be good if it had the Array prototype object on it's
> prototype chain so that if Array.prototype was extended, it would
> affect this object too.
> 4. The object will *not* be live since live results from selector
> matching is slow.
> 
> Since the returned object won't be live, I don't see a reason to make
> it immutable. Hence it seems like we could put Array.prototype on the
> prototype chain which would immediately make all non-mutating as well
> as mutating functions available on the object.
> 
> We should also insert a new prototype object in the prototype chain.
> Hence we end up with something like:
> 
> object -> [some type].prototype -> Array.prototype -> Object.prototype.
> 
> And to ensure that the object acts as much as possible as an array it
> should also have it's [[Class]] set to that of an array.

This is not something to do lightly -- at least cross-post the first message to 
es-disc...@mozilla.org and set reply-to followups-to. Cc'ing Allen.

Note that [[Class]] is going away in ES.next.

The internal methods and properties of ECMA-262 are not arbitrary extension 
points for other specs to use without consultation.

/be


> This has
> subtle effects on a number of functions. For example it affects what
> Object.toString() and Array.isArray returns, it affects how
> Array.concat behaves, and it affects the JSON serializer.
> 
> I'm not sure if setting the [[Class]] to that of an array also gives
> the object the magical .length property, but if it doesn't, we need to
> also define that the returned object has such a property. Note that
> for Arrays, .length doesn't live on the prototype chain, but is rather
> a special property on the object itself.
> 
> In other words, the returned object is exactly what you'd get if you did:
> 
> a = new Array;
> a.__proto__ = [some type].prototype;
> [some type].prototype.__proto__ = Array.prototype;
> 
> and then filled a with the set of nodes which matched the selector
> passed to .findAll.
> 
> 
> So the remaining question is, what should we use for [some type]. One
> option is to use NodeList. However this would result in NodeLists
> having Array.prototype on it's prototype chain. Including all mutating
> functions. This is iffy in general since NodeLists are returned from
> several APIs which return objects which represent a live result of a
> query. For example .getElementsByTagName, .getElementsByClassName and
> .childNodes.
> 
> An additional source of iffiness with this idea is that several of the
> mutating methods on Array.prototype don't throw if called on a
> immutable objects. For example .pop, .shift, .sort and .reverse all
> would not throw if called on an empty immutable list.
> 
> Hence I propose that we add a new type. I don't care much for naming
> things so I'll just suggest NodeArray for now and let others fight it
> out over the name.
> 
> For now we can leave NodeArray as empty and just let it be an
> extension point for page authors. We can discuss separately if
> .findAll/.matchesSelector should be added to NodeArray, and if so how
> they should behave.
> 
> However, we should probably use NodeArray to "fix" one of the problems
> with some of the functions on Array.prototype. For example
> Array.prototype.filter always returns a new Array object. This would
> mean that:
> 
> elem.findAll(...).filter(function(node) { ... });
> 
> will return a plain Array and not a NodeArray. However we could make
> NodeArray override all such functions and keep their behavior
> identical except that they return NodeArrays.
> 
> Another way to fix this problem would be to change the definition of
> Array.prototype.filter, but I have no idea if that's doable, or how
> that would be done.
> 
> 
> What do people think?
> 
> / Jonas
> 

Re: Consolidating charter changes

[Arthur Barstow]

On 11/11/11 12:41 PM, ext Anne van Kesteren wrote:
On Tue, 08 Nov 2011 09:37:55 -0800, Arthur Barstow 
 wrote:
During the October 31 meeting, we discussed [1] various additions, 
changes and deletions for WebApps' current charter [2]. To 
consolidate the various proposals, I created the following doc:




My expectation is that Doug will this information when he drafts our 
updated charter.


I thought we agreed to put Web Notifications on there and see what 
comes back from AC review.


Yes we did agree to that but Chaals and I were thinking that if the 
Member(s) that originally objected to Web Notifications' specs being 
included in WebApps sustained their objection, then we could eliminate 
some additional round-trips/e-mails/discussion by simply removing it 
from the Draft charter that is proposed to the AC.


So, if we get a sustained objection on one of WebApps' mail lists, I 
would prefer we just drop it. If we don't get such an objection, we can 
include it.


-AB

Re: [DRAFT] Web Intents Task Force Charter

[Clarke Stevens]

When can we get the TF tools set up so we can move these conversations to
the official forum?

Šbut addressing your scenario...

I got a slight headache from your "simple" case. :) Fortunately, the home
networking discovery piece of this puzzle is very simple. Any device that
implements a specific service (such as volume adjustment) can be
discovered and manipulated directly. The rest of your scenario is out of
scope for the interface to UPnP, Zeroconf, etc.

Web Intents may need to take some of these factors into account, but the
home networking interface piece can probably ignore them.

-Clarke

On 11/10/11 4:59 PM, "timeless"  wrote:

>That sounds like a different intent. And really UC gathering should be
>done on the TF list not here. But since people are ignoring that...
>
>Let's look at my Apartment as configured in Finland:
>
>A. Classic Speakers with copper input
>B. Desktop speakers with power, audio adjust using 3.5" input
>C. Digital mixer with optical, rca, other inputs, source selector and
>copper output
>D. DVD player w/ scart in+out, optical audio output
>E. Digital Cable w/ scart out, optical audio output
>F. PC with usb (tv converter in), mic in, line in; vga, 3.5" output
>G. G5 with usb, firewire, line in; two dvi outs, 3.5" and optical audio
>output
>(Hand waving about dvi/displayport)
>H. Cinema display with dvi in (carries audio)
>I. LCD TV with dvi in, scart in (carries audio)
>
>B1. Analog adjust
>C1. Analog adjust
>C2. Remote control
>D1. Remote control
>E1. Remote control
>F1. Usb Keyboard+mouse
>G1. Usb Keyboard+mouse
>I1. Buttons adjust
>
>E scart => D
>D scart => I
>E opt => C
>D opt => C
>G opt => C
>G 3.5 => B
>G dvi => H
>G dvi => I
>F vga => I
>F 3.5 => B
>
>This is a rough graph. Some things act as dumb pass-throughs
>(especially D in my graph).
>
>Let's take a "simple" case:
>0. Imagine there was a UPnP/DLNA control path from my G to C.
>1. Set the source input on C to E.
>2. Set the source input on I to E.
>Now I have a picture and sound - for E.
>3. As a bookmark, sample the sound level from A for source E.
>4. Set the source input on C to D.
>5. Set the source input on I to D.
>Now I have a picture and sound - for D.
>6. As a bookmark, sample the sound level from A for source D. 7.
>Adjust the audio level of C using G.
>8. As a bookmark, sample the sound level from A for source D.
>9. Set the source input on C to E.
>10. Set the source input on I to E.
>Now I have a picture and sound - for E.
>11. As a bookmark, sample the sound level from A for source E.
>
>Did the act at step 7 change the values between steps 3 and 11?
>
>Using D1 or E1 would not affect the output at A of E/D respectively.
>
>If the adjustment by 7 is global, then the intent is like a bad remote
>C2 and thus should be an independent intent from an intent to play
>video D for which an acceptable behavior is a D1 remote.
>
>This doesn't remotely cover the problem space, but it's a start.
>Generally, a volume adjust on NetFlix shouldn't affect my next visit
>to YouTube.
>
>On 11/10/11, Clarke Stevens  wrote:
>> Ah, but the difference here is that the web page actually does change
>>the
>> volume on the viewing device. That's the beauty of these home networking
>> protocols.
>>
>> -Clarke
>>
>> On 11/10/11 2:53 PM, "timeless"  wrote:
>>
>>>Some of this really should wait until there's a list.
>>>
>>>I believe that generally one wants to adjust audio as close to the
>>>source as possible, in which case the TV doesn't know anything.
>>>
>>>Some parallels:
>>>A. If you have a cable box => vcr => tv in old serial fashion and use
>>>old fashion remotes, changing the audio w/ the cable box remote
>>>adjusts the audio sent by that box to the vcr, the tv's audio level
>>>isn't affected (but the cable box can insert an overlay indicating
>>>level and hide it after some interval).
>>>B. If you use digital audio out on your Mac to an external device,
>>>volume controls disappear from the mac (it expects you to use your
>>>stereo's mixer instead).
>>>- here if an intent user decides you're using a tv, it could choose to
>>>hide audio controls (deferring to the tv). Note that I consider this
>>>more of a bug than a feature, but...
>>
>>
>
>-- 
>Sent from my mobile device

Re: What type should .findAll return

[Jake Verbaten]

On Fri, Nov 11, 2011 at 3:46 PM, Tab Atkins Jr. wrote:

> On Fri, Nov 11, 2011 at 1:05 AM, Jonas Sicking  wrote:
> > And to ensure that the object acts as much as possible as an array it
> > should also have it's [[Class]] set to that of an array. This has
> > subtle effects on a number of functions. For example it affects what
> > Object.toString() and Array.isArray returns, it affects how
> > Array.concat behaves, and it affects the JSON serializer.
>
> Could you point me to an explanation of what [[Class]] represents in
> ecmascript?  It's a little hard to search for.
>

[[Class]] is simply an internal property
containing a string like "Array",
"String", "Object", etc. It's mainly
used throughout the ES specification to determine how internal methods
should behave to inputs.

For example JSON.parse  checks for the
[[Class]] of Array and adjusts the output accordingly. A quick string
search on "Array" will find you all occurrences of the internals relying on
[[Class]] being set to "Array"


>
>
> > Another way to fix this problem would be to change the definition of
> > Array.prototype.filter, but I have no idea if that's doable, or how
> > that would be done.
>
> I prefer this if possible.
>
>
> > What do people think?
>
> +1
>
> ~TJ
>
>

Re: What type should .findAll return

[Bjoern Hoehrmann]

* Tab Atkins Jr. wrote:
>Could you point me to an explanation of what [[Class]] represents in
>ecmascript?  It's a little hard to search for.

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
Section 8.6.2. for instance.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: What type should .findAll return

[Tab Atkins Jr.]

On Fri, Nov 11, 2011 at 1:05 AM, Jonas Sicking  wrote:
> And to ensure that the object acts as much as possible as an array it
> should also have it's [[Class]] set to that of an array. This has
> subtle effects on a number of functions. For example it affects what
> Object.toString() and Array.isArray returns, it affects how
> Array.concat behaves, and it affects the JSON serializer.

Could you point me to an explanation of what [[Class]] represents in
ecmascript?  It's a little hard to search for.


> Another way to fix this problem would be to change the definition of
> Array.prototype.filter, but I have no idea if that's doable, or how
> that would be done.

I prefer this if possible.


> What do people think?

+1

~TJ

Re: innerHTML in DocumentFragment

[Tab Atkins Jr.]

On Fri, Nov 11, 2011 at 3:17 AM, Henri Sivonen  wrote:
> On Fri, Nov 11, 2011 at 1:11 PM, Jonas Sicking  wrote:
>> Have you ever actually talked to the SVG WG about this specific issue?
>
> Yes, at the time foreign lands were being specced in HTML and the SVG
> WG had to be dragged in kicking and screaming, because they didn't
> want to SVG-in-HTML to be supported at all at first.

The SVGWG's opinion today is the opposite - we'd like SVG and HTML to
live together as nicely as possible.  Getting 

Re: innerHTML in DocumentFragment

[Henri Sivonen]

On Fri, Nov 11, 2011 at 1:42 PM, Henri Sivonen  wrote:
> As a bonus, developers would need to call createDocumentFragement() first.

Doh. Would *not* need to call createDocumentFragement() first.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: What type should .findAll return

[Jake Verbaten]

As a web developer, having DOM methods which return "real arrays" so we no
longer have to call `toArray(nodeList)` or `[].slice.call(nodeList)` would
be awesome.

On Fri, Nov 11, 2011 at 9:05 AM, Jonas Sicking  wrote:

> Hi All,
>
> So, we've debated a lot the exact syntax for .find/.findAll. However I
> intentionally requested that we split out the discussions about return
> type for .findAll to a separate thread. So I'm starting that thread
> here.
>
> There are a few goals for the return'ed object that I've envisioned
> based on discussions so far:
>
> 1. It should have at least all of the non-mutating Array methods on
> it. Possibly the mutating methods too if we allow the returned object
> to be mutable.
> 2. It should have a object on the prototype chain where we can insert
> functions that are specifically useful for lists of nodes. Examples
> include .find/.findAll/.matchesSelector/.remove/.addEventListener
> 3. It would be good if it had the Array prototype object on it's
> prototype chain so that if Array.prototype was extended, it would
> affect this object too.
> 4. The object will *not* be live since live results from selector
> matching is slow.
>
> Since the returned object won't be live, I don't see a reason to make
> it immutable. Hence it seems like we could put Array.prototype on the
> prototype chain which would immediately make all non-mutating as well
> as mutating functions available on the object.
>
> We should also insert a new prototype object in the prototype chain.
> Hence we end up with something like:
>
> object -> [some type].prototype -> Array.prototype -> Object.prototype.
>
> And to ensure that the object acts as much as possible as an array it
> should also have it's [[Class]] set to that of an array. This has
> subtle effects on a number of functions. For example it affects what
> Object.toString() and Array.isArray returns, it affects how
> Array.concat behaves, and it affects the JSON serializer.
>
> I'm not sure if setting the [[Class]] to that of an array also gives
> the object the magical .length property, but if it doesn't, we need to
> also define that the returned object has such a property. Note that
> for Arrays, .length doesn't live on the prototype chain, but is rather
> a special property on the object itself.
>
> In other words, the returned object is exactly what you'd get if you did:
>
> a = new Array;
> a.__proto__ = [some type].prototype;
> [some type].prototype.__proto__ = Array.prototype;
>
> and then filled a with the set of nodes which matched the selector
> passed to .findAll.
>
>
> So the remaining question is, what should we use for [some type]. One
> option is to use NodeList. However this would result in NodeLists
> having Array.prototype on it's prototype chain. Including all mutating
> functions. This is iffy in general since NodeLists are returned from
> several APIs which return objects which represent a live result of a
> query. For example .getElementsByTagName, .getElementsByClassName and
> .childNodes.
>

Not to mention, that there must be a ton of code out there that assumes a
nodeList is not an array (mediocre feature detection code).


>
> An additional source of iffiness with this idea is that several of the
> mutating methods on Array.prototype don't throw if called on a
> immutable objects. For example .pop, .shift, .sort and .reverse all
> would not throw if called on an empty immutable list.
>
> Hence I propose that we add a new type. I don't care much for naming
> things so I'll just suggest NodeArray for now and let others fight it
> out over the name.
>
> For now we can leave NodeArray as empty and just let it be an
> extension point for page authors. We can discuss separately if
> .findAll/.matchesSelector should be added to NodeArray, and if so how
> they should behave.
>
> However, we should probably use NodeArray to "fix" one of the problems
> with some of the functions on Array.prototype. For example
> Array.prototype.filter always returns a new Array object. This would
> mean that:
>
> elem.findAll(...).filter(function(node) { ... });
>
> will return a plain Array and not a NodeArray. However we could make
> NodeArray override all such functions and keep their behavior
> identical except that they return NodeArrays.
>
> Another way to fix this problem would be to change the definition of
> Array.prototype.filter, but I have no idea if that's doable, or how
> that would be done.
>

That would involve hackling with es-discuss. I send an email to their
mailing list
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018242.html


>
> What do people think?
>

overall it's a great idea. It is however a shame we duplicate functionality
with querySelectorAll


>
> / Jonas
>
>

Re: CfC: publish a Candidate Recommendation of WebSockets API; deadline Nov 9

[Arthur Barstow]

I created the following version of the spec as the basis of the CR:

  [1] http://dev.w3.org/html5/websockets/publish/CR-websockets-2011.html

This version includes a fix for [13700] and I added a reference to 
HTML5's Parsing URLs section as requested by Julian.


The only remaining bug is [12510]. This editorial bug was reopened after 
the CfC started. If anyone thinks those references are critical, they 
should please add a diff (based on [1]) to the bug and I will add them 
before the CR is published.


[Given Doug and I are traveling next week, we must schedule and hold a 
Director's call for the CR and US national holidays at the end of the 
month, I don't expect the CR to get published for a few weeks, possibly 
December.]


-AB

[13700] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13700
[12510] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12510

On 11/3/11 12:22 AM, ext Arthur Barstow wrote:
During the October 31 meeting [1], there was agreement to publish a 
Candidate Recommendation of the WebSockets API and this is a Call for 
Consensus to do so:


  http://dev.w3.org/html5/websockets/

The remaining open editorial bug [13700] will be fixed before 
publication.


I propose the CR exit criteria is the same as our last CR (Progress 
Events):


[[
To exit the Candidate Recommendation (CR) stage the following criteria 
must have been met:


1. There will be at least two interoperable implementations passing 
all test cases in the test suite for this specification. An 
implementation is to be available (i.e. for download), shipping (i.e. 
not private), and not experimental (i.e. intended for a wide 
audience). The working group will decide when the test suite is of 
sufficient quality to test interoperability and will produce an 
implementation report (hosted together with the test suite).


2. A minimum of three months of the CR stage will have elapsed (i.e. 
not until after DD MMM 2012). This is to ensure that enough time is 
given for any remaining major errors to be caught. The CR period will 
be extended if implementations are slow to appear.

]]

This CfC satisfies: a) the group's requirement to "record the group's 
decision to request advancement" to CR; and b) "General Requirements 
for Advancement on the Recommendation Track" as defined in the Process 
Document:


  http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs

As with all of our CfCs, positive response is preferred and encouraged 
and silence will be considered as agreeing with the proposal. The 
deadline for comments is November 9 and all comments should be sent to 
public-webapps at w3.org.


-AB

[1] http://www.w3.org/2011/10/31-webapps-minutes.html#item14
[13700] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13700

Re: [DRAFT] Web Intents Task Force Charter

[N.V.Balaji]

--
From: "Rich Tibbett" 
Sent: Friday, November 11, 2011 4:49 PM
To: "N.V.Balaji" 
Cc: "timeless" ; "Marcos Caceres" ; 
; 

Subject: Re: [DRAFT] Web Intents Task Force Charter




N.V.Balaji wrote:

-
From: "timeless" 
Sent: Friday, November 11, 2011 3:23 AM
To: "Marcos Caceres" ; ;

Subject: Re: [DRAFT] Web Intents Task Force Charter


Anyway, to your underlying question:
Android Intents and I believe some of the web Intents proposals have
two forms:
1. Fire and forget (mailto:, outbound video/audio/document)
2. Establish bidirectional communications link


I see two variants here. Simple request-response case (contact picker)
and a continuous dialog case. I am wondering should all intents expose
some UI. Can they just expose a URL and allow the caller to use those
URLs with XHR or EventSource.



So this was the exact concept behind our earlier proposal for Discovery:

http://people.opera.com/richt/release/specs/discovery/Overview.html


Yes. I agree.



At this point it would be beneficial to focus on how Web Intents can solve 
this problem rather than pushing two similar-but-slightly-different 
proposals. It doesn't necessarily need to expose that particular 
abstraction (i.e. HTTP URLs) if we can get a similar persistent data flow 
going via the Intents model.


Yes. We need to get web intent supporting non-UI services as well in some 
way.





It does help to set expectations early though and we should discuss 
further when the TF starts up. Seems we're all keen to get going.


- Rich

Re: innerHTML in DocumentFragment

[Henri Sivonen]

On Thu, Nov 10, 2011 at 7:32 PM, Jonas Sicking  wrote:
> I don't think we should make up rules for where it makes sense to
> insert DOM and where it doesn't. After all, we support .innerHTML on
> all HTML elements (and soon maybe all Elements), and not just a subset
> of them, right?

Yes, but with innerHTML on elements, we always have a context node, so
there isn't magic DWIM involved.

But you don't need to look far to find special cases with difficult
elements: We also support createContextualFragment with all possible
contexts except we special-case things so that if the context is html
in the (X)HTML namespace, the behavior is as if the context had been
body in the (X)HTML namespace.

On reasonable view is that solutions should always be complete and
make sense (for some notion of making sense) for all inputs. Another
reasonable view is that we shouldn't do anything with "for compleness"
as the rationale and that everything that needs notable additional
engineering needs to be justified by use cases. If no one really wants
to use DWIM parsing to create a DocumentFragment that has the html
element in the (X)HTML namespace as its child, why put the engineering
effort into supporting such a case?

Currently, per spec (and Ragnarök, Chrome and Firefox comply and
interoperate), if you take take an HTML document that has head and
body (as normal) and assign document.body.outerHTML =
document.body.outerHTML, you get an extra head so that the document
has 2 heads. Would you expend engineering effort, for the sake of
making sense in all cases for completeness, to get rid of the extra
head even though there are likely no use cases and 3 out of 4 engines
interoperate while complying with the spec?

> And requiring that a context node is passed in in all cases when HTML
> is parsed is terrible developer ergonomics.

One possibility is that instead of adding innerHTML to
DocumentFragment, we add three methods to Document:
DocumentFragment parseFragment(DOMString htmlMarkup);
DocumentFragment parseSvgFragment(DOMString svgMarkup);
DocumentFragment parseMathFragment(DOMString mathmlMarkup);

parseFragment would do roughly the kind of DWIM Yehuda suggested. That
is, you'd get to use  with it but not . parseSvgFragment
would invoke the HTML fragment parsing algorithm with svg in the SVG
namespace as the context. parseMathFragment would invoke the HTML
fragment parsing algorithm with math in the MathML namespace as the
context.

As a bonus, developers would need to call createDocumentFragement() first.

> frag.innerHTML = "";
> someSVGElement.appendChild(frag);
>
> seems very possible to make work

Making it work is a problem with .

I think we should have three DocumentFragment-returning parsing
methods instead of packing a lot of magic into innerHTML on
DocumentFragment, when having to obtain a DocumentFragment first and
filling it as a separate step sucks as far as developer ergonomics go.

> someTableElement.innerHTML = "...";
>
> will just drop the div on the floor.

By what mechanism? (It didn't implement and run Yehuda's suggestion,
but I'm pretty sure it wouldn't drop the div. Why would we put
additional effort into dropping the div?)

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Fwd: Head's up: Geolocation API Level 2 FPWD and LC

[Charles McCathieNevile]

Geolocation looking for reviews...

cheers

--- Forwarded message ---
From: "Lars Erik Bolstad" 
...

The Geolocation WG intend to publish the Geolocation API Level 2
specification as a First Public and Last Call working draft next week.

We plan to set the deadline for comments to 31 December, so the LC
period will last about 6 weeks.

The working draft can be found here:
http://www.w3.org/2008/geolocation/drafts/API/spec-source-v2.html

We would be particularly interested in feedback from the following
working groups and would appreciate if the chairs of these WGs could
comment on our planned schedule:

DAP, WebApps, I18N, TAG, HCG, WAI WCAG, SemWeb XG, POIWG.

Thanks,
Lars Erik Bolstad


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

Re: [DRAFT] Web Intents Task Force Charter

[Rich Tibbett]

N.V.Balaji wrote:

-
From: "timeless" 
Sent: Friday, November 11, 2011 3:23 AM
To: "Marcos Caceres" ; ;

Subject: Re: [DRAFT] Web Intents Task Force Charter


Anyway, to your underlying question:
Android Intents and I believe some of the web Intents proposals have
two forms:
1. Fire and forget (mailto:, outbound video/audio/document)
2. Establish bidirectional communications link


I see two variants here. Simple request-response case (contact picker)
and a continuous dialog case. I am wondering should all intents expose
some UI. Can they just expose a URL and allow the caller to use those
URLs with XHR or EventSource.



So this was the exact concept behind our earlier proposal for Discovery:

http://people.opera.com/richt/release/specs/discovery/Overview.html

At this point it would be beneficial to focus on how Web Intents can 
solve this problem rather than pushing two 
similar-but-slightly-different proposals. It doesn't necessarily need to 
expose that particular abstraction (i.e. HTTP URLs) if we can get a 
similar persistent data flow going via the Intents model.


It does help to set expectations early though and we should discuss 
further when the TF starts up. Seems we're all keen to get going.


- Rich

Re: innerHTML in DocumentFragment

[Henri Sivonen]

On Fri, Nov 11, 2011 at 1:11 PM, Jonas Sicking  wrote:
> Microsoft has expressed support for changing the parser here.

As a patch for IE9?

> Have you ever actually talked to the SVG WG about this specific issue?

Yes, at the time foreign lands were being specced in HTML and the SVG
WG had to be dragged in kicking and screaming, because they didn't
want to SVG-in-HTML to be supported at all at first.

> If not, please stop arguing that the SVG group wants the currently
> specced behavior.

I'm not arguing what they want it *today*. I'm saying what they wanted
earlier and why doing something different would be bad.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: innerHTML in DocumentFragment

[Jonas Sicking]

On Fri, Nov 11, 2011 at 3:00 AM, Henri Sivonen  wrote:
> On Fri, Nov 11, 2011 at 11:49 AM, Anne van Kesteren  wrote:
>>> Unfortunately 

Re: innerHTML in DocumentFragment

[Henri Sivonen]

On Fri, Nov 11, 2011 at 11:49 AM, Anne van Kesteren  wrote:
>> Unfortunately 

Re: innerHTML in DocumentFragment

[Jonas Sicking]

On Fri, Nov 11, 2011 at 1:49 AM, Anne van Kesteren  wrote:
> On Fri, 11 Nov 2011 10:44:10 +0100, Jonas Sicking  wrote:
>>
>> For all element names defined in SVG 1.1 (for now), make the parser
>> treat it just as it would have if it had parsed "...", except
>> that it obviously wouldn't output the  element.
>>
>> There are a few tags where this is a big problem. At least for ,
>> 

Re: [DRAFT] Web Intents Task Force Charter

[N.V.Balaji]

-
From: "timeless" 
Sent: Friday, November 11, 2011 3:23 AM
To: "Marcos Caceres" ; ; 


Subject: Re: [DRAFT] Web Intents Task Force Charter


Some of this really should wait until there's a list.

I believe that generally one wants to adjust audio as close to the
source as possible, in which case the TV doesn't know anything.

Some parallels:
A. If you have a cable box => vcr => tv in old serial fashion and use
old fashion remotes, changing the audio w/ the cable box remote
adjusts the audio sent by that box to the vcr, the tv's audio level
isn't affected (but the cable box can insert an overlay indicating
level and hide it after some interval).
B. If you use digital audio out on your Mac to an external device,
volume controls disappear from the mac (it expects you to use your
stereo's mixer instead).
- here if an intent user decides you're using a tv, it could choose to
hide audio controls (deferring to the tv). Note that I consider this
more of a bug than a feature, but...

Anyway, to your underlying question:
Android Intents and I believe some of the web Intents proposals have two 
forms:

1. Fire and forget (mailto:, outbound video/audio/document)
2. Establish bidirectional communications link




I see two variants here. Simple request-response case (contact picker) and a 
continuous dialog case. I am wondering should all intents expose some UI. 
Can they just expose a URL and allow the caller to use those URLs with XHR 
or EventSource.







Defining how to make #2 work should be in scope for the TF and Out Of
Scope while defining its Charter.

#2 is obviously more exciting for vendors trying to proxy to non web
things, but IMO that's an implementation detail or potentially a
supplemental Note/Specification.

On 11/10/11, Marcos Caceres  wrote:



--
Marcos Caceres


On Thursday, November 10, 2011 at 7:56 PM, Rich Tibbett wrote:


Marcos Caceres wrote:
>
> On Thursday, November 10, 2011 at 5:01 PM, Robin Berjon wrote:
>
> > It's important to separate Intents as currently proposed and what we
> > collectively want out of them. In order to move fast we probably 
> > don't

> > want to pile up a zillion features there, but we equally certainly
> > don't want this to turn into a rubber-stamping exercise. So bring 
> > the

> > UCs on!
> >
> > - Hide quoted message -
> > > Perhaps someone could take the time to describe exactly how a user
> > > could communicate with an existing TV device in their home from a
> > > web browser supporting web intents based on the above 
> > > requirements?

> >
> >
> >
> >
> > We actually agreed that folks in the Discovery/Home Networking gang
> > would do just that, to see if it flies.
> Also, a prototype might help here …. i.e., it's not up to the WG to
> explain how it does what you want, but up to you to show that it 
> doesn't

> do something you want through a prototype (or similar) to do. If your
> prototype breaks down because the intents system doesn't work without
> extensions, then we have something to work from.
>
> Agree?

Yes. I don't doubt this logic :)

A use case I keep thinking about is:

 1. I'm at Youtube.com, and I want to watch a video on my tv.
 2. I tell youtube, "hey, sent this to my TV".
 3. Video starts playing on my TV.
 4. I turn the audio up/down on the youtube video (or I scrub the 
timeline).
How does that work? Is that all still done over HTTP and the intent 
(i.e.,

the audio control)?

I guess it's like the "intent" is ongoing while some activity is 
happening
(watching the video on my tv). I don't know if the current proposal 
supports

such a thing or if it's more "fire and forget".

Anyway, just thinking out loud… guess we can pick this up in the new 
list.





--
Sent from my mobile device

Re: innerHTML in DocumentFragment

[Anne van Kesteren]

On Fri, 11 Nov 2011 10:44:10 +0100, Jonas Sicking  wrote:

For all element names defined in SVG 1.1 (for now), make the parser
treat it just as it would have if it had parsed "...", except
that it obviously wouldn't output the  element.

There are a few tags where this is a big problem. At least for ,

Re: innerHTML in DocumentFragment

[Jonas Sicking]

On Fri, Nov 11, 2011 at 12:27 AM, Simon Pieters  wrote:
> On Thu, 10 Nov 2011 18:32:36 +0100, Jonas Sicking  wrote:
>
>> And yes, this does create a lot of edge cases which needs to be
>> defined. But the goal should be to make sane calls sane, that seems
>> imminently possible. So
>>
>> frag.innerHTML = "";
>> someSVGElement.appendChild(frag);
>>
>> seems very possible to make work.
>
> How?

For all element names defined in SVG 1.1 (for now), make the parser
treat it just as it would have if it had parsed "...", except
that it obviously wouldn't output the  element.

There are a few tags where this is a big problem. At least for ,

What type should .findAll return

[Jonas Sicking]

Hi All,

So, we've debated a lot the exact syntax for .find/.findAll. However I
intentionally requested that we split out the discussions about return
type for .findAll to a separate thread. So I'm starting that thread
here.

There are a few goals for the return'ed object that I've envisioned
based on discussions so far:

1. It should have at least all of the non-mutating Array methods on
it. Possibly the mutating methods too if we allow the returned object
to be mutable.
2. It should have a object on the prototype chain where we can insert
functions that are specifically useful for lists of nodes. Examples
include .find/.findAll/.matchesSelector/.remove/.addEventListener
3. It would be good if it had the Array prototype object on it's
prototype chain so that if Array.prototype was extended, it would
affect this object too.
4. The object will *not* be live since live results from selector
matching is slow.

Since the returned object won't be live, I don't see a reason to make
it immutable. Hence it seems like we could put Array.prototype on the
prototype chain which would immediately make all non-mutating as well
as mutating functions available on the object.

We should also insert a new prototype object in the prototype chain.
Hence we end up with something like:

object -> [some type].prototype -> Array.prototype -> Object.prototype.

And to ensure that the object acts as much as possible as an array it
should also have it's [[Class]] set to that of an array. This has
subtle effects on a number of functions. For example it affects what
Object.toString() and Array.isArray returns, it affects how
Array.concat behaves, and it affects the JSON serializer.

I'm not sure if setting the [[Class]] to that of an array also gives
the object the magical .length property, but if it doesn't, we need to
also define that the returned object has such a property. Note that
for Arrays, .length doesn't live on the prototype chain, but is rather
a special property on the object itself.

In other words, the returned object is exactly what you'd get if you did:

a = new Array;
a.__proto__ = [some type].prototype;
[some type].prototype.__proto__ = Array.prototype;

and then filled a with the set of nodes which matched the selector
passed to .findAll.


So the remaining question is, what should we use for [some type]. One
option is to use NodeList. However this would result in NodeLists
having Array.prototype on it's prototype chain. Including all mutating
functions. This is iffy in general since NodeLists are returned from
several APIs which return objects which represent a live result of a
query. For example .getElementsByTagName, .getElementsByClassName and
.childNodes.

An additional source of iffiness with this idea is that several of the
mutating methods on Array.prototype don't throw if called on a
immutable objects. For example .pop, .shift, .sort and .reverse all
would not throw if called on an empty immutable list.

Hence I propose that we add a new type. I don't care much for naming
things so I'll just suggest NodeArray for now and let others fight it
out over the name.

For now we can leave NodeArray as empty and just let it be an
extension point for page authors. We can discuss separately if
.findAll/.matchesSelector should be added to NodeArray, and if so how
they should behave.

However, we should probably use NodeArray to "fix" one of the problems
with some of the functions on Array.prototype. For example
Array.prototype.filter always returns a new Array object. This would
mean that:

elem.findAll(...).filter(function(node) { ... });

will return a plain Array and not a NodeArray. However we could make
NodeArray override all such functions and keep their behavior
identical except that they return NodeArrays.

Another way to fix this problem would be to change the definition of
Array.prototype.filter, but I have no idea if that's doable, or how
that would be done.


What do people think?

/ Jonas

Re: Consolidating charter changes

[Anne van Kesteren]

On Tue, 08 Nov 2011 09:37:55 -0800, Arthur Barstow   
wrote:
During the October 31 meeting, we discussed [1] various additions,  
changes and deletions for WebApps' current charter [2]. To consolidate  
the various proposals, I created the following doc:




My expectation is that Doug will this information when he drafts our  
updated charter.


I thought we agreed to put Web Notifications on there and see what comes  
back from AC review.




[1] http://www.w3.org/2011/10/31-webapps-minutes.html
[2] http://www.w3.org/2010/webapps/charter/



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

Re: innerHTML in DocumentFragment

[Simon Pieters]

On Thu, 10 Nov 2011 18:32:36 +0100, Jonas Sicking  wrote:


And yes, this does create a lot of edge cases which needs to be
defined. But the goal should be to make sane calls sane, that seems
imminently possible. So

frag.innerHTML = "";
someSVGElement.appendChild(frag);

seems very possible to make work.


How?

--
Simon Pieters
Opera Software