Re: [selectors-api] matchesSelector() Proposal (was: Call for Consensus - Selectors Last Call)
Sean Hogan wrote: Lachlan Hunt wrote: Sean Hogan wrote: Gregory Reimer (the author of reglib) points out that Element.matchesSelector would be useful for event delegation. See http://blogs.sun.com/greimer/entry/opera_10_will_suport_selector It would also neatly tie in with NodeFilter in DOM-Traversal, facilitating something like a live querySelectorAll() during document load. I forgot to mention before that I already have an open bug for tracking this issue. http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865 It would be useful if you could elaborate upon those use cases. Are you asking for a better explanation of the concepts or more specific examples? Well, you already explained the concept of event delegation below, but some examples would also be useful, especially real world examples. Do any JavaScript libraries implement functionality similar to the matchesSelector proposal? If so, then examples of those would also be useful. How is that nonsensical? Without having use cases presented, it's hard to justify the feature and even harder to make sure it's designed in the most optimal way for those use cases. - The feature is already justified by the first paragraph of the specification. It facilitates the performing of DOM operations on an element that matches a selector. There are other potential features that fit that description, but which weren't included in this version. For example, NodeList filtering, scoped methods and namespace resolution, each of which will be reconsidered for the next version. - The feature is already defined in the specification as part of the querySelector* methods. The term 'matching Element node' refers to an Element node that matches the group of selectors (selectors) that was passed to the method. The only decision to be made is about the name. That just means it will be somewhat easier to specify. Although there are lots of other issues to consider which can make it slightly more complex, either for the spec and/or implementations. e.g. * Defining how it works with :scope (as mentioned previously) * Any potential security issues (there may not be any, but we need to be sure) And potentially many others that get raised during implementation. Also, don't underestimate the cost of choosing an appropriate method name. - Event delegation plus Element.matchesSelector is a better match for event registration that querySelectorAll. Say you want to add event handlers to elements that match a selector. If you perform document.querySelectorAll(S1) and then addEventListener on each found element, and then one such element (E1) is relocated in the document in such a way that it no longer matches S1 then (presumably) the handlers attached on E1 become invalid and need to be removed (and perhaps different ones added). Sure, if you're using event delegation, then I agree that a matchesSelector method could be useful. But be aware that event delegation is just one possible solution to that problem. XBL2 is another more flexible solution with features designed specifically for that. Hopefully that will become available within a few years, but unfortunately, implementing it isn't yet a priority for implementers. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Call for Consensus - Selectors Last Call
Sean Hogan wrote: - All the getElement* selectors are matched by straight-forward ways for checking if an element-node matches the desired constraint. e.g. getElementsByTagName and tagName, getElementById and id, getElementsByClassName and className / classList Honestly, className is not a straight-forward way to check whether an element matches getElementsByClassName. Similarly, getElementById and id doesn't work if xml:id is supported. This is not to say that having a way to check whether an element matches a given selector might not be nice in some cases, but let's not overstate the case here. These features aren't just in the specs and provided by the browsers, they are used frequently (well, not the last one). The last one isn't used much because it basically doesn't work. To not have Element.matchesSelector is to go against current standards and (I'm sure you will find) programmer expectations. The latter, maybe. The former, no (in the realistic sense of violating current standards). It's interesting that I have never heard any of the JS framework authors (who are some of the primary target audience for this specification) mention anything about matchesSelector... In any case, I think Lachlan is right. This sounds like a reasonable addition for a future spec version, but not this one. (Specs need to have a feature freeze just like software does, and I think this is unarguably a feature.) -Boris -Boris
Re: Call for Consensus - Selectors Last Call
Gregory Reimer (the author of reglib) points out that Element.matchesSelector would be useful for event delegation. See http://blogs.sun.com/greimer/entry/opera_10_will_suport_selector It would also neatly tie in with NodeFilter in DOM-Traversal, facilitating something like a live querySelectorAll() during document load. Unfortunately I had assumed it was in the spec. I've looked now and seen that it wasn't considered due to a lack of presented use cases, which seems non-sensical. matchesSelector() is to querySelectorAll() as tagName is to getElementsByTagName(). The only reason for it not to be in the spec is if it is harmful. The only complication I can see is supporting the :scope pseudo-attribute. cheers, Sean Charles McCathieNevile wrote: Hi, Lachy thinks the latest editor's draft[1] is ready for Last Call, after responding to all the comments from last time (and removing the NSResolver). The disposition of comments[2] explains what happened to those comments. So this is a call for Consensus to publish the Editor's Draft [1] of the Selectors API spec as a Last Call. Please respond before Monday November 10. As always, silence is taken as assent but an explicit response is preferred. Opera supports publication of this draft as a Last Call. [1] http://dev.w3.org/2006/webapi/selectors-api/ [2] http://dev.w3.org/2006/webapi/selectors-api/disposition-of-comments.html cheers Chaals
Re: Call for Consensus - Selectors Last Call
Sean Hogan wrote: Gregory Reimer (the author of reglib) points out that Element.matchesSelector would be useful for event delegation. See http://blogs.sun.com/greimer/entry/opera_10_will_suport_selector It would also neatly tie in with NodeFilter in DOM-Traversal, facilitating something like a live querySelectorAll() during document load. It would be useful if you could elaborate upon those use cases. Unfortunately I had assumed it was in the spec. I've looked now and seen that it wasn't considered due to a lack of presented use cases, which seems non-sensical. How is that nonsensical? Without having use cases presented, it's hard to justify the feature and even harder to make sure it's designed in the most optimal way for those use cases. The only reason for it not to be in the spec is if it is harmful. AFAIK, no-one said it was harmful. It is too late for this proposal to be added to this version of the spec, but it will be considered for the next version. The only complication I can see is supporting the :scope pseudo-attribute. Assuming the CSSWG includes the :scope proposal in the next version of Selectors, and if there are use cases for which :scope would be useful in a matchesSelector() function, we can investigate solutions to address the issue. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Call for Consensus - Selectors Last Call
Lachlan Hunt: OK, I have updated the spec based on this suggestion. You can review the changes in the latest editor's draft. http://dev.w3.org/2006/webapi/selectors-api/#nodeselector Please let me know if you are satisfied with this response. I’m satisfied with the response. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Call for Consensus - Selectors Last Call
Cameron McCormack: * In section 6, I don’t think it’s necessary to explicitly mention undefined, since it’s already handled by the annotation in the IDL. If you do want to include this in the prose, I think it needs to be qualified to say that this applies to an ECMAScript language binding of the interface. (null’s OK, since you can talk about null at the level of IDL values so it’s applicable to any language.) Lachlan Hunt: I don't see why this is a problem. Technically both null and undefined are handled by the IDL, but stating it implicitly in the prose makes it clearer. I don’t mind it being repeated. My problem is more of talking about undefined, which is an ECMAScript value, in the same context as null, which here (presumably) is being used to refer to the IDL value. There is no IDL value undefined. I would be happy if the start of that sentence were changed to: If the selectors parameter is set to null (or undefined, in the ECMAScript language binding), … Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: Call for Consensus - Selectors Last Call
Lachlan Hunt [EMAIL PROTECTED] wrote: Stewart Brodie wrote: [a few issues snipped] [see http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0216.html ] Thank you. I'd be pleased to see this document progress to LC. -- Stewart Brodie Software Engineer ANT Software Limited
Re: Call for Consensus - Selectors Last Call
Cameron McCormack wrote: * In the first sentence of section 6, I’d do /either/any of/, since there are more than two interfaces listed. Fixed. * There’s a newer Web IDL WD available than the one referenced (with the new name) so it might be good to reference that. Then you can use [WEBIDL] as the reference link text instead. This will happen as soon as Bert updates the bibliographic database for the spec generator. I've emailed him to let him know. * In section 6, I don’t think it’s necessary to explicitly mention undefined, since it’s already handled by the annotation in the IDL. If you do want to include this in the prose, I think it needs to be qualified to say that this applies to an ECMAScript language binding of the interface. (null’s OK, since you can talk about null at the level of IDL values so it’s applicable to any language.) I don't see why this is a problem. Technically both null and undefined are handled by the IDL, but stating it implicitly in the prose makes it clearer. I haven't made this change yet, because I want to avoid making non-editorial changes at this stage. But feel free to convince me during this next LC period. * s/an an asterisk/an asterisk/ in section 6.1. Fixed. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Call for Consensus - Selectors Last Call
Cameron McCormack: * In section 6, I don’t think it’s necessary to explicitly mention undefined, since it’s already handled by the annotation in the IDL. If you do want to include this in the prose, I think it needs to be qualified to say that this applies to an ECMAScript language binding of the interface. (null’s OK, since you can talk about null at the level of IDL values so it’s applicable to any language.) Lachlan Hunt: I don't see why this is a problem. Technically both null and undefined are handled by the IDL, but stating it implicitly in the prose makes it clearer. I haven't made this change yet, because I want to avoid making non-editorial changes at this stage. But feel free to convince me during this next LC period. OK, will do. :) -- Cameron McCormack ≝ http://mcc.id.au/
Re: Call for Consensus - Selectors Last Call
Hear hear! Charles McCathieNevile wrote: Hi, Lachy thinks the latest editor's draft[1] is ready for Last Call, after responding to all the comments from last time (and removing the NSResolver). The disposition of comments[2] explains what happened to those comments. So this is a call for Consensus to publish the Editor's Draft [1] of the Selectors API spec as a Last Call. Please respond before Monday November 10. As always, silence is taken as assent but an explicit response is preferred. Opera supports publication of this draft as a Last Call. [1] http://dev.w3.org/2006/webapi/selectors-api/ [2] http://dev.w3.org/2006/webapi/selectors-api/disposition-of-comments.html cheers Chaals
Re: Call for Consensus - Selectors Last Call
Kartikaya Gupta [EMAIL PROTECTED] wrote:
On Fri, 31 Oct 2008 16:06:23 +0100, Charles McCathieNevile
[EMAIL PROTECTED] wrote:
So this is a call for Consensus to publish the Editor's Draft [1] of the
Selectors API spec as a Last Call. Please respond before Monday November
10. As always, silence is taken as assent but an explicit response is
preferred.
Opera supports publication of this draft as a Last Call.
[1] http://dev.w3.org/2006/webapi/selectors-api/
[2]
http://dev.w3.org/2006/webapi/selectors-api/disposition-of-comments.html
Is it just me or is the scope element somewhat under-defined in the
spec? The only mentions of it are in this sentence:
If the context node is a Document node, then the scope element is the
documentElement of the given document. If the context node is an Element
node, then the scope element is the same as the context node.
However, it doesn't say what the scope element does or why it's relevant,
nor does it have a reference to any other spec that explains this. I did a
quick search through the list archives (I haven't been following it too
closely) and it looks like the :scope pseudo-class will be defined in
another spec. I think that should be clarified, because otherwise it just
looks like a completely random sentence that would be better taken out
altogether.
I concur.
I've just read the spec through the start to finish for the first time in
many months, prompted by these announcements, and came up with a number of
questions. Then I've read through all the articles in the disposition of
comments, and found that the same issues have already been raised and
discussed at length, but it seems that in some cases, no changes or
clarifications have been made to the document in response. Perhaps the
meaning of the spec is obvious to those who have been actively working on
the document who know what assumptions to make, but they aren't clear to me.
I really think that the spec needs to nail down the answers to these
questions - just a simple sentence (or non-normative example) will do.
The specific questions I had (which I think I found the definitive answers
for in the mail archives):
1) What is the scope element for - it's only mentioned in one sentence?
2) Is an empty string actually a valid selector? If not, then the whole
null/undefined is an empty string discussion is irrelevant - it's simply a
syntax error.
3) Does the matching algorithm work on based on the entire tree that
contains the context node or just the sub-tree rooted at the context node? I
think this is easiest fixed by adding an example like the one in the
previous e-mail that I'm quoting and stating the expected result:
Also, since the scope element stuff was deferred to another spec, this
spec remains somewhat ambiguous (at least to me) about exactly what gets
selected in the following case:
html
body
div class=bar
div id=foo
div class=baz/div
/div
/div
/body
/html
document.getElementById('foo').querySelector('.bar .baz')
I believe the above querySelector call should return the baz div as
opposed to NULL, but it took me a few close readings of the spec to decide
on that. A clarifying example in the spec would be quite helpful on this
one.
After trawling through the comments, I also think that the answer is that it
works on the entire tree, and consequently the baz div should be the one and
only result.
--
Stewart Brodie
Software Engineer
ANT Software Limited
Re: Call for Consensus - Selectors Last Call
Kartikaya Gupta wrote:
On Fri, 31 Oct 2008 16:06:23 +0100, Charles McCathieNevile
[EMAIL PROTECTED] wrote:
[1] http://dev.w3.org/2006/webapi/selectors-api/ [2]
Is it just me or is the scope element somewhat under-defined in the
spec? The only mentions of it are in this sentence:
If the context node is a Document node, then the scope element is
the documentElement of the given document. If the context node is an
Element node, then the scope element is the same as the context
node.
However, it doesn't say what the scope element does or why it's
relevant, nor does it have a reference to any other spec that
explains this. I did a quick search through the list archives (I
haven't been following it too closely) and it looks like the :scope
pseudo-class will be defined in another spec.
It was added with the intention of referencing whichever spec :scope (or
whatever it gets called) gets defined in, which will most likely be
Selectors Level 4. The statement itself makes sense when read in the
context of the :scope proposal.
http://lists.w3.org/Archives/Public/www-archive/2008Jul/att-0025/Overview.html
But I suppose I could comment it out for now, until :scope is defined in
a real spec and the statement is actually needed.
Also, since the scope element stuff was deferred to another spec,
this spec remains somewhat ambiguous (at least to me) about exactly
what gets selected in the following case:
html
body
div class=bar
div id=foo
div class=baz/div
/div
/div
/body
/html
document.getElementById('foo').querySelector('.bar .baz')
This is covered in the spec by the statement:
Selectors are evaluated against a given element in the context the
entire DOM tree in which the element is located.
I believe the above querySelector call should return the baz div as
opposed to NULL, but it took me a few close readings of the spec to
decide on that. A clarifying example in the spec would be quite
helpful on this one.
Yeah, I suppose it's not too late to add a small example illustrating that.
I've made those changes in the current editor's draft. Though I'd
rather not make too many additional changes now as I don't want to hold
up publication. Any other issues like this can wait till after this
Last Call draft is published and can be fixed before it goes to CR.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Call for Consensus - Selectors Last Call
Stewart Brodie wrote: 1) What is the scope element for - it's only mentioned in one sentence? That statement has now been commented out (see my previous mail [1]) 2) Is an empty string actually a valid selector? If not, then the whole null/undefined is an empty string discussion is irrelevant - it's simply a syntax error. Selectors defines what's considered valid or invalid, and an empty string is invalid. So having the spec say to treat null and undefined as empty strings is effectively an indirect way of saying it's a syntax error. 3) Does the matching algorithm work on based on the entire tree that contains the context node or just the sub-tree rooted at the context node? I think this is easiest fixed by adding an example like the one in the previous e-mail that I'm quoting and stating the expected result: Already added (see previous mail). [1] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0216.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Call for Consensus - Selectors Last Call
I support the publication as Last Call. On Oct 31, 2008, at 8:06 AM, Charles McCathieNevile wrote: Hi, Lachy thinks the latest editor's draft[1] is ready for Last Call, after responding to all the comments from last time (and removing the NSResolver). The disposition of comments[2] explains what happened to those comments. So this is a call for Consensus to publish the Editor's Draft [1] of the Selectors API spec as a Last Call. Please respond before Monday November 10. As always, silence is taken as assent but an explicit response is preferred. Opera supports publication of this draft as a Last Call. [1] http://dev.w3.org/2006/webapi/selectors-api/ [2] http://dev.w3.org/2006/webapi/selectors-api/disposition-of-comments.html 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: Call for Consensus - Selectors Last Call
Charles McCathieNevile: So this is a call for Consensus to publish the Editor's Draft [1] of the Selectors API spec as a Last Call. Please respond before Monday November 10. As always, silence is taken as assent but an explicit response is preferred. I’m in favour of publishing. A few comments though (since this consensus call prompted me to look at it), mostly editorial, before the LC period begins: * In the first sentence of section 6, I’d do /either/any of/, since there are more than two interfaces listed. * There’s a newer Web IDL WD available than the one referenced (with the new name) so it might be good to reference that. Then you can use [WEBIDL] as the reference link text instead. * In section 6, I don’t think it’s necessary to explicitly mention undefined, since it’s already handled by the annotation in the IDL. If you do want to include this in the prose, I think it needs to be qualified to say that this applies to an ECMAScript language binding of the interface. (null’s OK, since you can talk about null at the level of IDL values so it’s applicable to any language.) * s/an an asterisk/an asterisk/ in section 6.1. Thanks, Cameorn -- Cameron McCormack ≝ http://mcc.id.au/
