More questions about contextual reference nodes
I have two questions about http://www.w3.org/TR/selectors-api2/#determine-contextual-reference-nodes 1) What are the use cases for supplying more than one contextual reference node, exactly? It seems weird to allow more than one node to match :scope. 2) If we do want to allow the multiple node thing, can we please do it in IDL instead of the (currently pretty vague) prose? Something like: Element querySelector(in DOMString selectors, in optional Element refElement); Element querySelector(in DOMString selectors, in optional NodeList refElements); Element querySelector(in DOMString selectors, in optional sequenceElement refElements); or some such? It's not quite clear to me whether we want a sequenceElement or a T[]; that's worth checking. In either case, the prose will need to define what happens with the NodeList or sequence/array cases, but there will be no ambiguity about how one gets Elements out of what's passed in. The one difference is that in the array case if non-elements are present in the array an exception will be thrown. I think that's fine, myself. -Boris
CfC: publish new Working Draft of Indexed Database API; deadline April 16
The Editors of the Indexed Database API would like to publish a new Working Draft of their spec and this is a Call for Consensus to do so: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html If one agrees with this proposal, it: a) indicates support for publishing a new WD; and b) does not necessarily indicate support for the contents of the WD. If you have any comments or concerns about this proposal, please send them to public-webapps by April 16 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. -Art Barstow
[IndexedDB] Features not included in the first version of the spec
Jonas created a list of IndexedDB features that are not included in the first version of the spec. Those features are documented in the following wiki page: http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures Comments on this document are welcome. -Art Barstow
Re: More questions about contextual reference nodes
On 2011-04-09 10:12, Boris Zbarsky wrote: I have two questions about http://www.w3.org/TR/selectors-api2/#determine-contextual-reference-nodes 1) What are the use cases for supplying more than one contextual reference node, exactly? It seems weird to allow more than one node to match :scope. There were cases in JQuery where the script wanted to iteratively run a selector on all nodes in a collection, and return elements that are descendants of those elements. This allows :scope to be used in those cases by passing the collection as the refNodes. There was previous discussion of this somewhere in the public-webapps archive. 2) If we do want to allow the multiple node thing, can we please do it in IDL instead of the (currently pretty vague) prose? Something like: I know the draft is quite poorly written with regards to how to deal with collections right now. Element querySelector(in DOMString selectors, in optional Element refElement); Element querySelector(in DOMString selectors, in optional NodeList refElements); Element querySelector(in DOMString selectors, in optional sequenceElement refElements); I also have to include one for HTMLCollection, which doesn't inherit from NodeList. But if that would be better, then yes, we can do that. It just makes the IDL 4 times longer, as that has to be repeated for each method of the 3 methods. Ive made this change now. I also dropped queryScopedSelector at the same time, since it wasn't able meet the original requirements that it was being designed for and so not worth keeping. or some such? It's not quite clear to me whether we want a sequenceElement or a T[]; that's worth checking. WebIDL says sequences are passed by value and arrays are passed by reference. So I suspect using an array is better here so that it doesn't have to create a copy. In either case, the prose will need to define what happens with the NodeList or sequence/array cases, but there will be no ambiguity about how one gets Elements out of what's passed in. The one difference is that in the array case if non-elements are present in the array an exception will be thrown. I think that's fine, myself. Yes, I would like feedback about the best way to define this, particularly for Arrays. In particular, how to address the following cases. var ref = []; ref[0] = el1; ref[100] = el2; That will contain almost a million empty cells. Will iterating through that cause any unwanted performance issues? Should we require arrays to contain contiguous Elements and only iterate up to the first empty or non-Element cell, ignoring anything beyond that? ref[1] = string; Should passing this now throw an exception, or should it just accept that ref[0] was an element and use that? For NodeLists, should it accept any NodeList and only use the Element nodes? e.g. element.childNodes may contain text or comment nodes. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: CfC: publish new Working Draft of Indexed Database API; deadline April 16
On Sat, Apr 9, 2011 at 4:22 AM, Arthur Barstow art.bars...@nokia.com wrote: The Editors of the Indexed Database API would like to publish a new Working Draft of their spec and this is a Call for Consensus to do so: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html If one agrees with this proposal, it: a) indicates support for publishing a new WD; and b) does not necessarily indicate support for the contents of the WD. If you have any comments or concerns about this proposal, please send them to public-webapps by April 16 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. I support publishing this document. ~TJ
Re: [widgets] localizing author
On Sat, 09 Apr 2011 01:22:07 +0200, Scott Wilson scott.bradley.wil...@gmail.com wrote: On 8 Apr 2011, at 09:42, Charles McCathieNevile wrote: Hi, I just realised that I actually localise my own name in certain languages ... But I cannot do that in config.xml. Likewise, I would like to localise the href ... I guess the workaround at present is to use the element to do something like author王密 (Michelle Wang)/author ... which is not completely ideal as you don't get different hrefs. Right. It's also not ideal in general, since in a localised presentation it makes sense to present the localised information, and this requires you to choose which one is going to predominate for e.g. sorting. I presume the change would be to make Author multiple with xml:lang. That's what I had in mind. I think a risk is that developers might reasonably interpret this as meaning one author element for each person rather than one author element per locale. Hmm. Given the way localisation works, I think it would take a particularly dumb reading of an example to assume that - although I agree it is possible, and therefore someone will do it at some point. It would also be reasonable if we want to restrict to one author to allow internationalised author elements, while maintaining that only the first match *for a given language* will be used. 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: More questions about contextual reference nodes
On 4/9/11 6:27 AM, Lachlan Hunt wrote: There were cases in JQuery where the script wanted to iteratively run a selector on all nodes in a collection, and return elements that are descendants of those elements. This allows :scope to be used in those cases by passing the collection as the refNodes. There was previous discussion of this somewhere in the public-webapps archive. Hmm... ok. But is jquery's collection a JS Array? I also have to include one for HTMLCollection, which doesn't inherit from NodeList. Yeah, that's broken... I wonder whether we can just fix that in Web DOM Core or something WebIDL says sequences are passed by value and arrays are passed by reference. So I suspect using an array is better here so that it doesn't have to create a copy. The by reference thing only happens for array host objects, which a JS Array is not. So the copy would effectively happen in either case, I believe, for JS Array. Yes, I would like feedback about the best way to define this, particularly for Arrays. In particular, how to address the following cases. var ref = []; ref[0] = el1; ref[100] = el2; That will contain almost a million empty cells. Will iterating through that cause any unwanted performance issues? I believe my current Gecko implementation (using our existing variant facilities, since that's all we have to deal with overloads for the moment) will allocate a C array with 101 entries, then ignore it because not everything in the array is an Element. A DOM binding implementation using WebIDL arrays or sequences would allocate a C++ array with 101 entries, all of which except for the first and last are null. Then the actual implementation of the selectors API will walk this array and add only the first and last entry to the set of scope elements. I think. I'm pretty sure this is true for Array; the behavior for sequence is less clear to me. And maybe this can all be optimized in implementations, somehow... Ccing Cameron for his input. Should we require arrays to contain contiguous Elements and only iterate up to the first empty or non-Element cell, ignoring anything beyond that? If using webidl array/sequence types, that would help with the iteration, but not the large allocation. ref[1] = string; Should passing this now throw an exception, or should it just accept that ref[0] was an element and use that? Webidl array/sequence would throw in this case, I think. For NodeLists, should it accept any NodeList and only use the Element nodes? e.g. element.childNodes may contain text or comment nodes. I think that's the right thing to do, yes. -Boris
Re: CfC: publish new Working Draft of Indexed Database API; deadline April 16
I support this. On Sat, Apr 9, 2011 at 4:22 AM, Arthur Barstow art.bars...@nokia.com wrote: The Editors of the Indexed Database API would like to publish a new Working Draft of their spec and this is a Call for Consensus to do so: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html If one agrees with this proposal, it: a) indicates support for publishing a new WD; and b) does not necessarily indicate support for the contents of the WD. If you have any comments or concerns about this proposal, please send them to public-webapps by April 16 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. -Art Barstow
