Re: Publishing Selectors API Level 2 as an FPWD?
On Sun, Jan 10, 2010 at 11:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/11/10 1:24 AM, Sean Hogan wrote: That's correct. jQuery's $(element).find(div) is the equivalent of SelectorsAPI2's element.querySelectorAll(:scope div) or So in fact jquery can simply implement Element.find in terms of querySelectorAll by just prepending :scope to the selector string, right? Not if the selector contains a ,. Consider: $(element).find(div, p) / Jonas
Re: Publishing Selectors API Level 2 as an FPWD?
Boris Zbarsky wrote: On 1/10/10 11:58 PM, Sean Hogan wrote: Even if jQuery deprecates non-standard selectors, the current spec for queryScopedSelector*() doesn't support the jQuery implicitly scoped selector *. As I understand it, jquery selectors on elements are always scoped in the sense that they behave differently from the v1 Selectors API. In particular, if I understand correctly, the behavior of: element.querySelector(body div) in matching all divs that are descendants of |element| and also descendants of a body (which may be an _ancestor_ of |element|) is different from the selector behavior in jquery. Yes. All that said, I just read the draft at http://dev.w3.org/2006/webapi/selectors-api2/ and I can't make heads or tails of either what the new arguments to querySelector(All) are supposed to mean (are they just an enumaration of the things :scope is allowed to match during the selector evaluation?) When there's no reference nodes passed and no :scope selector used, the behaviour of querySelector and querySelectorAll is unchanged from v1. If there is a :scope selector used, then it matches the context node. If there are also additional reference nodes passed, then :scope will instead match any of the elements in given collection. or what queryScopedSelector(All) is supposed to do. Am I just missing something? Am I reading the wrong draft? (I'd link to the dated version of the draft, in case it changes, but that link is broken, sadly.) You can link to the CVS revision instead. The link to the dated version in the page header is generated automatically by the spec generator, regardless of whether it actually exists or not. In the following forms :scope is misleading: element.queryScopedSelector(:scope + *) element.queryScopedSelector(:scope ~ *) What's misleading about that? :scope would match the context node (what the element variable points to), and would return its sibling elements. and especially: element.querySelector(* :scope *, refNode) Again, how is that misleading? :scope matches whichever element refNode points to, and then follows the normal rules for evaluating querySelector. Given that selector, any descendents of refNode that are also descendents of element (the context node) will be matched, the first of which will be returned. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Publishing Selectors API Level 2 as an FPWD?
On 11/01/10 8:55 PM, Lachlan Hunt wrote: In the following forms :scope is misleading: element.queryScopedSelector(:scope + *) element.queryScopedSelector(:scope ~ *) What's misleading about that? :scope would match the context node (what the element variable points to), and would return its sibling elements. The definition of scope is (something like) an area in which something acts or operates or has power or control. The examples above can return nodes that are not within :scope. Therefore :scope is misleading. and especially: element.querySelector(* :scope *, refNode) Again, how is that misleading? :scope matches whichever element refNode points to, and then follows the normal rules for evaluating querySelector. Given that selector, any descendents of refNode that are also descendents of element (the context node) will be matched, the first of which will be returned. In this example, the node represented by :scope isn't the boundary for the selection at all. In one sense, element is the scope because any matched node must be descended from element. In another sense (the sense being used in this discussion), document is the scope, because document.documentElement is the upper bounds for matching the first * in the selector. In summary, the proposed :scope pseudo-class only acts as a scope for the query in special cases, not in the general case.
Re: Publishing Selectors API Level 2 as an FPWD?
On 1/11/10 4:55 AM, Lachlan Hunt wrote: When there's no reference nodes passed and no :scope selector used, the behaviour of querySelector and querySelectorAll is unchanged from v1. If there is a :scope selector used, then it matches the context node. If there are also additional reference nodes passed, then :scope will instead match any of the elements in given collection. Got it. We should really make this MUCH clearer in the spec text. or what queryScopedSelector(All) is supposed to do. Am I just missing something? Am I reading the wrong draft? (I'd link to the dated version of the draft, in case it changes, but that link is broken, sadly.) You can link to the CVS revision instead. The link to the dated version in the page header is generated automatically by the spec generator, regardless of whether it actually exists or not. That answers my complaint, but not my question: what is queryScopedSelector supposed to do? -Boris
Re: Publishing Selectors API Level 2 as an FPWD?
On 11/01/10 6:40 PM, Boris Zbarsky wrote:
On 1/11/10 1:24 AM, Sean Hogan wrote:
That's correct. jQuery's $(element).find(div) is the equivalent of
SelectorsAPI2's element.querySelectorAll(:scope div) or
So in fact jquery can simply implement Element.find in terms of
querySelectorAll by just prepending :scope to the selector string,
right? Note that this happens to work even for the div case (by
converting the selector to :scope div, which is what jquery means).
So the div thing doesn't seem to require preparsing (modulo commas
in the selector; was that the key point?). Of course the jquery
selectors that aren't in CSS do (or possibly post-parsing depending on
how it's implemented).
If we could assume that commas only ever delimit selectors in a
selector-string, and if jQuery didn't support selectors not implemented
by the browser then something like the following conversion would be
sufficient for all jQuery queries:
function preprocess(str) { return :scope + str.split(,).join(,
:scope ); }
Hence no value is added by queryScopedSelector*().
If we can't assume those things then jQuery will still need its current
selector parser.
Hence no value is added by queryScopedSelector*().
My point is that jQuery's $(element).find( div) isn't supported
(without pre-processing by the JS lib) by
element.queryScopedSelectorAll().
...
element.queryScopedSelectorAll(:scope div) generally becomes
element.parentNode.querySelectorAll(:scope div, element) which is
the same as
element.querySelectorAll(:scope div, element) or even
element.querySelectorAll(:scope div)
That's what I'm confused about. Does implementing element.find(
div) as element.queryScopedSelectorAll(:scope div) not do what
the current jquery code does? If not, how do they differ?
They will select the same list of elements.
As will element.querySelectorAll(:scope div)
I'm still confused about queryScopedSelectorAll, though. It sounds
from your example like queryScopedSelectorAll just prepends :scope
to the whole query string and then calls querySelectorAll on the
parentNode of the scope node, with the scope node passed in as the
optional argument. So:
element.queryScopedSelectorAll(myStr)
is the same as:
element.parentNode.querySelectorAll(:scope + myStr, element);
is that correct?
For some selector-strings yes.
More specifically, the parsing rules for scoped selectors are at:
http://dev.w3.org/2006/webapi/selectors-api2/#parse-a-scoped-selector
Scoped selectors must still be valid selectors, so div, + div, ~
div will all throw exceptions.
They must be explicitly written as :scope div, etc in the call to
element.queryScopedSelectorAll().
Thus the queryScopedSelectorAll call won't prepend them with :scope .
Re: Publishing Selectors API Level 2 as an FPWD?
On 1/11/10 12:13 PM, Boris Zbarsky wrote: I do wonder how useful queryScopedSelector is, since it can be implemented easily via querySelector... I guess the main value is in fact in situations when one is given a selector string already and not in situations where one is writing one's own selector strings -Boris
Re: Publishing Selectors API Level 2 as an FPWD?
Sean Hogan wrote: In summary, the proposed :scope pseudo-class only acts as a scope for the query in special cases, not in the general case. Yes, I'm aware of that. That was basically my reasoning for attempting to change it to :reference, but that name wasn't particularly well received either. However, keep in mind, I'd prefer to avoid having this turn into another naming debate. Selectors API has suffered enough in the past as a result of that. So if you have anything more to add, I'd request that you check the archives for this list and www-style for messages relating to :scope/:reference/:context, etc. to see what arguments have been raised previously. The most recent discussion of and objections to :reference are in this thread from www-style last September. There were also other objections raised with me on IRC and told to me directly. http://lists.w3.org/Archives/Public/www-style/2009Sep/thread.html#msg251 In particular, this one lists most of the alternatives have been considered, and it also sums up why the selector pre-processing for scoped selectors got watered down to its current state. http://lists.w3.org/Archives/Public/www-style/2009Sep/0317.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Publishing Selectors API Level 2 as an FPWD?
On 12/01/10 5:30 AM, Lachlan Hunt wrote: Sean Hogan wrote: In summary, the proposed :scope pseudo-class only acts as a scope for the query in special cases, not in the general case. Yes, I'm aware of that. That was basically my reasoning for attempting to change it to :reference, but that name wasn't particularly well received either. However, keep in mind, I'd prefer to avoid having this turn into another naming debate. Selectors API has suffered enough in the past as a result of that. So if you have anything more to add, I'd request that you check the archives for this list and www-style for messages relating to :scope/:reference/:context, etc. to see what arguments have been raised previously. The most recent discussion of and objections to :reference are in this thread from www-style last September. There were also other objections raised with me on IRC and told to me directly. http://lists.w3.org/Archives/Public/www-style/2009Sep/thread.html#msg251 In particular, this one lists most of the alternatives have been considered, and it also sums up why the selector pre-processing for scoped selectors got watered down to its current state. http://lists.w3.org/Archives/Public/www-style/2009Sep/0317.html Yes, it sounds like I have nothing to add. The new refNodes argument to querySelector*() will be useful, even if :scope is the place-holder for refNodes. The new queryScopedSelector*() methods add no value. I suspect that if / when they get removed there will be no objection to renaming :scope to something more appropriate. I've been an active part of discussion on this list. If you don't want to have the same arguments on two different lists you should reference the other list and discussion a bit more promptly.
Re: Publishing Selectors API Level 2 as an FPWD?
On 8/01/10 1:19 AM, Lachlan Hunt wrote: Hi, Now that Selectors API Level 1 is published and basically all but finalised (just waiting for some implementations to be officially released before taking it to REC), can we publish Selectors API Level 2 as an FPWD? It would be useful to have it more widely reviewed, especially since Mozilla and WebKit have begun their implementation of matchesSelector, which is defined in it. The editor's draft is here. http://dev.w3.org/2006/webapi/selectors-api2/ FYI, it seems the whole Status of this Document hasn't been updated for Selectors-API2. For instance: This document has been approved for publication as a Candidate Recommendation by the working group. However, in light of existing interoperable implementations, the group is considering requesting publication as a Proposed Recommendation. Also, the links to the W3C CVS are for Selectors-API, not Selectors-API2. I can't see the value of queryScopedSelector*() methods. The original rationale was that JS libs could potentially drop their selector engines, but this isn't facilitated by the proposed methods. Given that JS libs will still have to parse the selectors it is a trivial step to call querySelector*(rewrittenSelector, refNode) rather than queryScopedSelector*(rewrittenSelector) The queryScopedSelector*() methods have misleading names - they don't match the definition of scope. It would be ridiculous to stick with those names if there are no implementations already out there. Similarly, the :scope pseudo-class has a misleading name.
Re: Publishing Selectors API Level 2 as an FPWD?
Sean Hogan wrote: On 8/01/10 1:19 AM, Lachlan Hunt wrote: can we publish Selectors API Level 2 as an FPWD? http://dev.w3.org/2006/webapi/selectors-api2/ FYI, it seems the whole Status of this Document hasn't been updated for Selectors-API2. Yeah, that will get fixed up when I get the spec ready for publication and do all the PubRules checks, etc. Also, the links to the W3C CVS are for Selectors-API, not Selectors-API2. Likewise. I can't see the value of queryScopedSelector*() methods. The original rationale was that JS libs could potentially drop their selector engines, but this isn't facilitated by the proposed methods. Given that JS libs will still have to parse the selectors it is a trivial step to call querySelector*(rewrittenSelector, refNode) rather than queryScopedSelector*(rewrittenSelector) Personally, I agree and was initially hesitant about adding it, but there were some reasonable arguments put forth suggesting that lifting the burden of pre-processing the selector to prepend :scope from JS libs would be useful [1]. Evidence to the contrary would be helpful. John Resig also once told me he had an alternative proposal, but he hasn't yet shared it with me. The queryScopedSelector*() methods have misleading names - they don't match the definition of scope. It would be ridiculous to stick with those names if there are no implementations already out there. Do you have a better alternative suggestion? Similarly, the :scope pseudo-class has a misleading name. I've tried various alternative names, like :context, :reference, etc., but so far scope seems to be the least objectionable. But all things considered, I don't think :scope is a particularly bad name, since it's name somewhat describes it's purpose and relates it to its utility in scoped stylesheets. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Publishing Selectors API Level 2 as an FPWD?
On 11/01/10 8:29 AM, Lachlan Hunt wrote: Sean Hogan wrote: On 8/01/10 1:19 AM, Lachlan Hunt wrote: can we publish Selectors API Level 2 as an FPWD? http://dev.w3.org/2006/webapi/selectors-api2/ I can't see the value of queryScopedSelector*() methods. The original rationale was that JS libs could potentially drop their selector engines, but this isn't facilitated by the proposed methods. Given that JS libs will still have to parse the selectors it is a trivial step to call querySelector*(rewrittenSelector, refNode) rather than queryScopedSelector*(rewrittenSelector) Personally, I agree and was initially hesitant about adding it, but there were some reasonable arguments put forth suggesting that lifting the burden of pre-processing the selector to prepend :scope from JS libs would be useful [1]. Evidence to the contrary would be helpful. John Resig also once told me he had an alternative proposal, but he hasn't yet shared it with me. That's my point - in its current form queryScopedSelector*() doesn't lift that burden of pre-processing. I don't know about all selector engines, but jQuery, for example, has several non-standard selectors that will continue to require pre-processing. :first, :last, :even, :odd, :eq(), :gt(), :lt(), :header, :animated, :contains(), :has(), :parent, :input, :text, :password, :radio, :checkbox, :submit, :image, :reset, :button, :file Even if jQuery deprecates non-standard selectors, the current spec for queryScopedSelector*() doesn't support the jQuery implicitly scoped selector *. The queryScopedSelector*() methods have misleading names - they don't match the definition of scope. It would be ridiculous to stick with those names if there are no implementations already out there. Do you have a better alternative suggestion? Similarly, the :scope pseudo-class has a misleading name. I've tried various alternative names, like :context, :reference, etc., but so far scope seems to be the least objectionable. But all things considered, I don't think :scope is a particularly bad name, since it's name somewhat describes it's purpose and relates it to its utility in scoped stylesheets. :reference matches the text of the spec. :context would be second choice I guess. I seem to recall :ref-node and :context-node also being suggested. :scope only describes its purpose in specific cases - queries with one of the following forms: element.queryScopedSelector(:scope *) element.queryScopedSelector(:scope *) In the following forms :scope is misleading: element.queryScopedSelector(:scope + *) element.queryScopedSelector(:scope ~ *) and especially: element.querySelector(* :scope *, refNode)
Re: Publishing Selectors API Level 2 as an FPWD?
On 1/10/10 11:58 PM, Sean Hogan wrote: Even if jQuery deprecates non-standard selectors, the current spec for queryScopedSelector*() doesn't support the jQuery implicitly scoped selector *. As I understand it, jquery selectors on elements are always scoped in the sense that they behave differently from the v1 Selectors API. In particular, if I understand correctly, the behavior of: element.querySelector(body div) in matching all divs that are descendants of |element| and also descendants of a body (which may be an _ancestor_ of |element|) is different from the selector behavior in jquery. Or did I understand incorrectly? All that said, I just read the draft at http://dev.w3.org/2006/webapi/selectors-api2/ and I can't make heads or tails of either what the new arguments to querySelector(All) are supposed to mean (are they just an enumaration of the things :scope is allowed to match during the selector evaluation?) or what queryScopedSelector(All) is supposed to do. Am I just missing something? Am I reading the wrong draft? (I'd link to the dated version of the draft, in case it changes, but that link is broken, sadly.) In the following forms :scope is misleading: element.queryScopedSelector(:scope + *) element.queryScopedSelector(:scope ~ *) and especially: element.querySelector(* :scope *, refNode) Can't exactly comment on this given the above -Boris
Re: Publishing Selectors API Level 2 as an FPWD?
On 11/01/10 4:19 PM, Boris Zbarsky wrote: On 1/10/10 11:58 PM, Sean Hogan wrote: Even if jQuery deprecates non-standard selectors, the current spec for queryScopedSelector*() doesn't support the jQuery implicitly scoped selector *. As I understand it, jquery selectors on elements are always scoped in the sense that they behave differently from the v1 Selectors API. In particular, if I understand correctly, the behavior of: element.querySelector(body div) in matching all divs that are descendants of |element| and also descendants of a body (which may be an _ancestor_ of |element|) is different from the selector behavior in jquery. Or did I understand incorrectly? That's correct. jQuery's $(element).find(div) is the equivalent of SelectorsAPI2's element.querySelectorAll(:scope div) or element.queryScopedSelectorAll(div). My point is that jQuery's $(element).find( div) isn't supported (without pre-processing by the JS lib) by element.queryScopedSelectorAll(). All that said, I just read the draft at http://dev.w3.org/2006/webapi/selectors-api2/ and I can't make heads or tails of either what the new arguments to querySelector(All) are supposed to mean (are they just an enumaration of the things :scope is allowed to match during the selector evaluation?) or what queryScopedSelector(All) is supposed to do. Am I just missing something? Am I reading the wrong draft? (I'd link to the dated version of the draft, in case it changes, but that link is broken, sadly.) You are correct about the new refNodes argument in querySelector*(). queryScopedSelector*() are more-or-less wrappers around querySelector*(). e.g. element.queryScopedSelectorAll(div) generally becomes element.parentNode.querySelectorAll(:scope div, element) which is the same as element.querySelectorAll(:scope div, element) or even element.querySelectorAll(:scope div) element.queryScopedSelectorAll(:scope div) generally becomes element.parentNode.querySelectorAll(:scope div, element) which is the same as element.querySelectorAll(:scope div, element) or even element.querySelectorAll(:scope div) element.queryScopedSelectorAll(:scope + div) generally becomes element.parentNode.querySelectorAll(:scope + div, element) element.queryScopedSelectorAll(div, div:scope) generally becomes element.parentNode.querySelectorAll(:scope div, div:scope, element)
Re: Publishing Selectors API Level 2 as an FPWD?
On 11/01/10 5:24 PM, Sean Hogan wrote: On 11/01/10 4:19 PM, Boris Zbarsky wrote: On 1/10/10 11:58 PM, Sean Hogan wrote: Even if jQuery deprecates non-standard selectors, the current spec for queryScopedSelector*() doesn't support the jQuery implicitly scoped selector *. As I understand it, jquery selectors on elements are always scoped in the sense that they behave differently from the v1 Selectors API. In particular, if I understand correctly, the behavior of: element.querySelector(body div) in matching all divs that are descendants of |element| and also descendants of a body (which may be an _ancestor_ of |element|) is different from the selector behavior in jquery. Or did I understand incorrectly? That's correct. jQuery's $(element).find(div) is the equivalent of SelectorsAPI2's element.querySelectorAll(:scope div) or element.queryScopedSelectorAll(div). Oops. Not a very insightful example. Perhaps the following would be better. Same for examples below. jQuery's $(element).find(div p) is the equivalent of SelectorsAPI2's element.querySelectorAll(:scope div p) or element.queryScopedSelectorAll(div p). My point is that jQuery's $(element).find( div) isn't supported (without pre-processing by the JS lib) by element.queryScopedSelectorAll(). All that said, I just read the draft at http://dev.w3.org/2006/webapi/selectors-api2/ and I can't make heads or tails of either what the new arguments to querySelector(All) are supposed to mean (are they just an enumaration of the things :scope is allowed to match during the selector evaluation?) or what queryScopedSelector(All) is supposed to do. Am I just missing something? Am I reading the wrong draft? (I'd link to the dated version of the draft, in case it changes, but that link is broken, sadly.) You are correct about the new refNodes argument in querySelector*(). queryScopedSelector*() are more-or-less wrappers around querySelector*(). e.g. element.queryScopedSelectorAll(div) generally becomes element.parentNode.querySelectorAll(:scope div, element) which is the same as element.querySelectorAll(:scope div, element) or even element.querySelectorAll(:scope div) element.queryScopedSelectorAll(:scope div) generally becomes element.parentNode.querySelectorAll(:scope div, element) which is the same as element.querySelectorAll(:scope div, element) or even element.querySelectorAll(:scope div) element.queryScopedSelectorAll(:scope + div) generally becomes element.parentNode.querySelectorAll(:scope + div, element) element.queryScopedSelectorAll(div, div:scope) generally becomes element.parentNode.querySelectorAll(:scope div, div:scope, element)
Re: Publishing Selectors API Level 2 as an FPWD?
On 1/11/10 1:24 AM, Sean Hogan wrote: That's correct. jQuery's $(element).find(div) is the equivalent of SelectorsAPI2's element.querySelectorAll(:scope div) or So in fact jquery can simply implement Element.find in terms of querySelectorAll by just prepending :scope to the selector string, right? Note that this happens to work even for the div case (by converting the selector to :scope div, which is what jquery means). So the div thing doesn't seem to require preparsing (modulo commas in the selector; was that the key point?). Of course the jquery selectors that aren't in CSS do (or possibly post-parsing depending on how it's implemented). My point is that jQuery's $(element).find( div) isn't supported (without pre-processing by the JS lib) by element.queryScopedSelectorAll(). ... element.queryScopedSelectorAll(:scope div) generally becomes element.parentNode.querySelectorAll(:scope div, element) which is the same as element.querySelectorAll(:scope div, element) or even element.querySelectorAll(:scope div) That's what I'm confused about. Does implementing element.find( div) as element.queryScopedSelectorAll(:scope div) not do what the current jquery code does? If not, how do they differ? I'm still confused about queryScopedSelectorAll, though. It sounds from your example like queryScopedSelectorAll just prepends :scope to the whole query string and then calls querySelectorAll on the parentNode of the scope node, with the scope node passed in as the optional argument. So: element.queryScopedSelectorAll(myStr) is the same as: element.parentNode.querySelectorAll(:scope + myStr, element); is that correct? -Boris
