[selectors-api] typo in specification
Hello. At the moment I'm translating "Selectors API Level 1" [1] and it seems I have noticed a typo in the original document. [1] https://www.w3.org/TR/selectors-api/ Section 6.4: "If result is invalid ([SELECT], section 12), raisea a SYNTAX_ERR exception ([DOM-LEVEL-3-CORE], section 1.4) and abort this algorithm." Probably it meant "raise a SYNTAX_ERR" instead "raisea a SYNTAX_ERR"? Best regards, Kirill, http://topolyan.com/
[selectors-api] How to mark TR version as obsolete/superseded? [Was: Re: Obsolete Document]
On 3/26/15 8:30 AM, Gulfaraz Yasin wrote: Hi It has come to my notice that the following document http://www.w3.org/TR/selectors-api/#resolving-namespaces is obsolete. Hi Gulfaraz, Thanks for your e-mail and sorry for the slow reply. I was directed to it's page from one of StackOverflow's answers and after following up a bit I've been informed that the above document is obsolete. Yes, this is true. It would be very helpful if there was a notice on the page that informed it's visitors of the same. Yes, I agree. I think the principle of least surprise implies the document at w3.org/TR/selectors-api/ should be gutted of all technical content and a reference to the DOM spec [DOM] (which supersede Selectors API) should be added (as well as a clear statement work on selectors-api has stopped and its features/APIs are superseded by [DOM]). However, I suspect the consortium's publication processes might not permit that. Xiaoqian, Yves - can we do as I suggest above? If not, what is your recommendation re making sure people understand work on selectors-api has stopped and it is superseded by [DOM]? -Thanks, AB [DOM] http://www.w3.org/TR/dom/
CfC: publish Selectors API Level 2 as WG Note; deadline October 11
As discussed previously (e.g. [1]), this is a Call for Consensus to: 1. Publish Selectors API Level 2 as WG Note 2. Stop work on that spec with an understanding this spec's features will be included in the HTMLWG's version of DOM4 If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by October 11 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. -Thanks, AB [1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0045.html
Re: ITS 2.0, Selectors 4 and Selectors API 2
On 2.7.2013 2:53, Daniel Glazman wrote: a. it's not possible, even in Selectors API 2 [5], to resolve arbitrary namespaces in querySelectorAll() In general this might be problem, but for ITS I don't see this as a problem. People who use ITS with non-HTML content (various flavours of XML) will use XPath as a query language. Selectors will be likely used only in combination with HTML content where you don't need namespaces (of course, unless you want to target specific elements inside embedded SVG/MathML). b. Selectors cannot target attributes Indeed, this is very serious limitation of CSS selectors and we even discussed removing CSS selectors completely from ITS because of this. But at the end prevailing opinion was that CSS selectors will be useful for scenarios where there is no need to care about attributes. But without ability so select attributes some users will be forced to switch to XPath instead of CSS selectors. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. -- Bringing you XML Prague conferencehttp://xmlprague.cz -- signature.asc Description: OpenPGP digital signature
Re: ITS 2.0, Selectors 4 and Selectors API 2
On Tue, Jul 2, 2013 at 12:57 AM, Daniel Glazman daniel.glaz...@disruptive-innovations.com wrote: On 02/07/13 09:16, Tab Atkins Jr. wrote: Pseudo-elements do exist in the document tree as far as layout is concerned. No, they do not. They don't create new nodes (yet), even shadow nodes, they can't be serialized. They belong to the layout tree, NOT the document tree. As I said in the section you quoted, *as far as layout is concerned*, pseudo-elements exist. I didn't say anything about creating DOM, affecting stringification, etc. ~TJ
ITS 2.0, Selectors 4 and Selectors API 2
ITS 2.0 (the Internationalization Tag Set 2.0) [1] is a specification
attaching l10n/i18n properties to elements and attributes of a document
tree through two means:
1. locally, using attributes in the ITS namespace
2. globally, using rules expressed in XML in the ITS namespace and
based on a selecting mechanism (XPath, CSS, ...)
Here are two examples of the above:
locally:
span xmlns:its=http://www.w3.org/2005/11/its;
its:translate=noNASA/span
globally:
rules xmlns=http://www.w3.org/2005/11/its;
version=2.0
queryLanguage=css
translateRule selector=//html:acronym
translate=xpath
xmlns:html=http://www.w3.org/1999/xhtml/
/rules
In the global case, the selecting language of the rule can be chosen
through the @queryLanguage attribute on the rules element. CSS
Selectors are explicitely listed [2] as a valid selecting mechanism and
it would be really nice to see CSS used there. Unfortunately, Selectors
[3] and its Selectors API [4] companion have two problems that are more
or less blockers for Selectors inside ITS 2.0:
a. it's not possible, even in Selectors API 2 [5], to resolve arbitrary
namespaces in querySelectorAll()
b. Selectors cannot target attributes
In the case of querySelectorAll(), we clearly need to extend Selectors
API to allow namespaces. We had little use cases in the past but that's
not true any more. And it's totally false to say we need this for html
only. A spec like ITS 2.0 will be in most cases not implemented natively
but above abstractions like document.evaluate() or querySelectorAll().
We clearly need namespace resolvers like [6] in Selectors API.
In the case of attributes not reachable through Selectors, we may have
almost everything we need in Selectors level 4 to provide a user like
ITS 2.0 with a solution: the subject indicator [7] could be easily
extended the following way:
1. only one subject indicator is allowed per compound selector
2. the subject indicator can precede a universal selector (potentially
omitted), a type element selector or an attribute selector. In the
case of an attribute selector, the selector represents then the
attribute node matching the condition expressed by the attribute
selector. Note: all @foo attributes of the document is not ![foo]
- that means !*[foo] - but *![foo]
3. both Selectors and Selectors API should allow such attribute
matching, but CSS rules with such attribute matching would of
course not trigger any style resolution. querySelectorAll() and
friends should be extended to return attribute nodes. The case
of a group of selectors where one of the selectors uses a subject
indicator to match attributes has to be discussed but I think it's
doable.
The above would allow to express any ITS rule not only using Selectors
but also in the future in a CSS-alike syntax. Then instead of:
rules xmlns=http://www.w3.org/2005/11/its;
version=2.0
queryLanguage=css
translateRule selector=html|acronym![title]
translate=css
xmlns:html=http://www.w3.org/1999/xhtml/
/rules
we could have the readability of:
@namespace html url(http://www.w3.org/1999/xhtml;);
html|acronym![title] { its-translate: no; }
and have it merged with CSS, use the power of the cascade, etc instead
of having to rely on... ahem... XPath. We could solve two problems of
ours at the same time: *finally* extend Selectors to attribute nodes
and fix that painful hole of Selectors API not working with namespaces.
[1] http://www.w3.org/TR/its20/
[2] http://www.w3.org/TR/its20/#css-selectors
[3] http://www.w3.org/TR/2011/REC-css3-selectors-20110929/
[4] http://www.w3.org/TR/2013/REC-selectors-api-20130221/
[5] http://www.w3.org/TR/selectors-api2/
[6] http://is.gd/HVrWM5
[7] http://dev.w3.org/csswg/selectors4/#subject
/Daniel
Re: ITS 2.0, Selectors 4 and Selectors API 2
On 02/07/13 02:53, Daniel Glazman wrote: rules xmlns=http://www.w3.org/2005/11/its; version=2.0 queryLanguage=css translateRule selector=//html:acronym translate=xpath xmlns:html=http://www.w3.org/1999/xhtml/ /rules Sorry, the above is obviously wrong, please read rules xmlns=http://www.w3.org/2005/11/its; version=2.0 queryLanguage=xpath translateRule selector=//html:acronym translate=no xmlns:html=http://www.w3.org/1999/xhtml/ /rules instead. Thanks. /Daniel
Re: ITS 2.0, Selectors 4 and Selectors API 2
On Mon, Jul 1, 2013 at 5:53 PM, Daniel Glazman daniel.glaz...@disruptive-innovations.com wrote: 1. only one subject indicator is allowed per compound selector That's already the case - the subject indicator has to precede the compound selector. 2. the subject indicator can precede a universal selector (potentially omitted), a type element selector or an attribute selector. In the case of an attribute selector, the selector represents then the attribute node matching the condition expressed by the attribute selector. Note: all @foo attributes of the document is not ![foo] - that means !*[foo] - but *![foo] This is unacceptable for Selectors applied against HTML in general. Attributes are *not* nodes, either in HTML or XML, and ![foo] refers to an element. Against an arbitrary document language where attributes are translated into a tree in a different manner, it would work. 3. both Selectors and Selectors API should allow such attribute matching, but CSS rules with such attribute matching would of course not trigger any style resolution. querySelectorAll() and friends should be extended to return attribute nodes. The case of a group of selectors where one of the selectors uses a subject indicator to match attributes has to be discussed but I think it's doable. I am strongly against Selectors returning different results when used in CSS versus qSA/find. If you want Selectors to be able to select attribute nodes, address it directly with a new selector. This should not be smuggled in via the subject indicator. ~TJ
Re: ITS 2.0, Selectors 4 and Selectors API 2
On Mon, 2013-07-01 at 19:46 -0700, Tab Atkins Jr. wrote: [...] If you want Selectors to be able to select attribute nodes, address it directly with a new selector. This should not be smuggled in via the subject indicator. Maybe it would be simpler to support an XPath() selector? When you start using ITS you'll find other cases that get difficult with existing CSS selectors, e.g. . partShortDescription elements whose id attribute value appears in the list of id attributes in the includes attribute of a partsDiagram element in the same section, and where that diagram has a language=only attribute on the replacementCopies element, and the diagram issue year is earlier than 1996. This sort of thing is fairly frequently written with XPath selectors today, and is a plausible use case (e.g. the older exploded parts diagram is only available in spanish, includes Spanish labels for the parts that readers will have to match up to a table of part numbers, so they need the same text in the diagram and in the table). A rigorous comparison of XPath with CSS selectors would be worth doing; piecemeal attempts to duplicate functionality don't seem worthwhile to me. On the other hand I do agree that it sounds like some limitation in CSS selector namespace handling could be alleviated. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Re: [selectors-api] QSA and findAll definitions
On Sun, Jun 9, 2013 at 6:18 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/9/13 7:35 PM, Timmy Willison wrote:
I was a little confused. I realized something I already knew in that
elem.querySelector[All] does limit the matched set to the descendants of
element
Right. But find() does not, for what it's worth, depending on the exact
selector used. It can return sublings of the context object, for example,
as far as I can tell. Hence the wording difference.
Specifically, el.find('+ div'); will work, and find the sibling
div to the context element. el.querySelector(':scope + div');
will *not* work, because the results are first filtered to be only
descendants of the context element.
The wording is slightly confusing now, but in Selectors 4 terminology,
selectors in find() are *relative*, but not *scoped*. Selectors in
qSA() are scope-filtered. (They may also be relative - it's been a
while since I read the spec, so I don't remember.)
~TJ
Re: [selectors-api] QSA and findAll definitions
Thank you both. That helps a lot. I figured el.querySelector(:scope +
div) would do the same thing as el.find(+ div).
Perhaps more examples in the spec that clearly demonstrate differences like
this between qSA() and findAll() would be helpful. I think some form of the
example that Tab gave would be a great addition.
Also, maybe we can clarify even further in the defintions for find() and
findAll(). Perhaps, rather than,
... from the tree within which the context object is located.
It could be,
... within the subtrees of the parent of the context object or the tree in
which the context object is located if there is no parent.
Compare this with qS[A]:
... within the subtrees of the context object.
This is an attempt to make it clear that ancestors of the context object
will never be in the resulting set and need not be considered in
implementations. In other words, it seems to me that elem.find() will never
return ancestors of elem.
On Mon, Jun 10, 2013 at 10:53 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Sun, Jun 9, 2013 at 6:18 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/9/13 7:35 PM, Timmy Willison wrote:
I was a little confused. I realized something I already knew in that
elem.querySelector[All] does limit the matched set to the descendants of
element
Right. But find() does not, for what it's worth, depending on the exact
selector used. It can return sublings of the context object, for
example,
as far as I can tell. Hence the wording difference.
Specifically, el.find('+ div'); will work, and find the sibling
div to the context element. el.querySelector(':scope + div');
will *not* work, because the results are first filtered to be only
descendants of the context element.
The wording is slightly confusing now, but in Selectors 4 terminology,
selectors in find() are *relative*, but not *scoped*. Selectors in
qSA() are scope-filtered. (They may also be relative - it's been a
while since I read the spec, so I don't remember.)
~TJ
Re: [selectors-api] QSA and findAll definitions
On Mon, Jun 10, 2013 at 1:15 PM, Timmy Willison timmywill...@gmail.com wrote: Thank you both. That helps a lot. I figured el.querySelector(:scope + div) would do the same thing as el.find(+ div). Perhaps more examples in the spec that clearly demonstrate differences like this between qSA() and findAll() would be helpful. I think some form of the example that Tab gave would be a great addition. Also, maybe we can clarify even further in the defintions for find() and findAll(). Perhaps, rather than, ... from the tree within which the context object is located. It could be, ... within the subtrees of the parent of the context object or the tree in which the context object is located if there is no parent. Compare this with qS[A]: ... within the subtrees of the context object. This is an attempt to make it clear that ancestors of the context object will never be in the resulting set and need not be considered in implementations. In other words, it seems to me that elem.find() will never return ancestors of elem. It certainly can return ancestors. You just need the right combinators. The reference combinator defined in Selectors 4 http://dev.w3.org/csswg/selectors/#idref-combinators can move anywhere in the tree, including straight upwards. The use of the subject indicator, also defined in Selectors 4 http://dev.w3.org/csswg/selectors/#subject, can also move up the tree. Just throw away your notion that .find() does any scoping whatsoever. It doesn't; all it does is provide a reference element, which is matched by :scope and which is used to absolutize relative selectors. ~TJ
Re: [selectors-api] QSA and findAll definitions
On Mon, Jun 10, 2013 at 4:47 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: Just throw away your notion that .find() does any scoping whatsoever. Ok, will do. It doesn't; all it does is provide a reference element, which is matched by :scope and which is used to absolutize relative selectors. ~TJ
[selectors-api] QSA and findAll definitions
The wording of the QSA and findAll definitions are a bit confusing to me. Forgive me if I'm misunderstanding, but the definitions for querySelector[All] and find[All] seem to be partly reversed. First, the definition of subtrees seems clear enough: The term subtrees refers to the set of elements that are descendants of the specified context object. However, the definition for querySelector currently states: return the first matching Element node within the subtrees of the context object. Isn't that the definition for find? Element#querySelector does not limit matching to subtrees of the context object. `elem.querySelector(div)` will return all divs on the page, not just descendants of `elem`. I assume this was not meant to be changed here. find states: return the first matching Element node from the tree within which the context object is located. This sounds just like what querySelector is supposed to do. Element#querySelector returns results based off of the tree in which the element is located. Thanks, - Timmy
Re: [selectors-api] QSA and findAll definitions
I was a little confused. I realized something I already knew in that elem.querySelector[All] does limit the matched set to the descendants of element, but the selector itself is not relative. Sorry about that. I guess my only question now is what is the difference between the way .find[All] and .querySelector[All] relate to the context object? Why the wording difference? Thanks again, - Timmy On Sun, Jun 9, 2013 at 5:34 PM, Timmy timmywill...@gmail.com wrote: The wording of the QSA and findAll definitions are a bit confusing to me. Forgive me if I'm misunderstanding, but the definitions for querySelector[All] and find[All] seem to be partly reversed. First, the definition of subtrees seems clear enough: The term subtrees refers to the set of elements that are descendants of the specified context object. However, the definition for querySelector currently states: return the first matching Element node within the subtrees of the context object. Isn't that the definition for find? Element#querySelector does not limit matching to subtrees of the context object. `elem.querySelector(div)` will return all divs on the page, not just descendants of `elem`. I assume this was not meant to be changed here. find states: return the first matching Element node from the tree within which the context object is located. This sounds just like what querySelector is supposed to do. Element#querySelector returns results based off of the tree in which the element is located. Thanks, - Timmy
Re: [selectors-api] QSA and findAll definitions
On 6/9/13 7:35 PM, Timmy Willison wrote: I was a little confused. I realized something I already knew in that elem.querySelector[All] does limit the matched set to the descendants of element Right. But find() does not, for what it's worth, depending on the exact selector used. It can return sublings of the context object, for example, as far as I can tell. Hence the wording difference. -Boris
[selectors-api2] Seeking implementation data re Selectors API Level 2
Hi Lachlan, During WebApps' f2f meeting last week, someone asked [Mins] about the implementation status of Selectors API Level 2. Do you have any implementation data re selectors-api2 you can share with us? -Thanks, AB [Mins] http://www.w3.org/2013/04/25-webapps-minutes.html#item03 Original Message Subject: ACTION-680: Ask Lachlan if he has some impl data re Selectors API v2 (Web Applications Working Group) Date: Thu, 25 Apr 2013 17:04:04 + From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group public-webapps@w3.org To: art.bars...@nokia.com ACTION-680: Ask Lachlan if he has some impl data re Selectors API v2 (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/680 On: Arthur Barstow Due: 2013-05-02 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings
[selectors-api] References to Selectors 4
http://www.w3.org/TR/selectors-api2/#the-scope-pseudo-class This section has already been copied to Selectors 4 (and has been for awhile, actually), so should be removed here and replaced with references to Selectors 4. http://www.w3.org/TR/selectors4/#the-scope-pseudo If there's anything that needs to be fixed in Selectors 4 for this to be viable, then let us know and we'll fix it. :) http://www.w3.org/TR/selectors-api2/#grammar Tab just updated the grammar productions in Selectors 4 and defined some terms, so this section shouldn't need to define anything, just reference Selectors 4. http://dev.w3.org/csswg/selectors4/#grammar http://www.w3.org/TR/selectors-api2/#processing-selectors We also added the algorithm for absolutizing a relative selector to the Selectors 4 spec, so you can reference scope-relative selectors, as defined here: http://dev.w3.org/csswg/selectors4/#scoping Please let us know if there are any errors. We'll try to publish a new WD soon with the updated definitions. ~fantasai + TJ
Selectors API Level 1 is a W3C Recommendation
Congratulations to Lachlan and Anne on the publication of a Recommendation for Selectors API Level 1 http://www.w3.org/TR/2013/REC-selectors-api-20130221/. Great job guys! -ArtB
Re: [selectors-api] Matching of :scope in document.querySelector(All)
On 2012-11-30 03:01, Boris Zbarsky wrote: When implementing :scope support, I discovered that as things stand this call: document.querySelector(:scope) is specified to return null. In particular http://dev.w3.org/2006/webapi/selectors-api2/#queryselector step 1 calls http://dev.w3.org/2006/webapi/selectors-api2/#determine-contextual-reference-nodes which returns an empty set. Then this empty set is passed as an explicit contextual reference set to selector matching in http://dev.w3.org/2006/webapi/selectors-api2/#evaluate-a-selector so that :scope doesn't match anything. Is this intentional? I believe the spec was written the way it was to deal with the case where an explicitly empty set of reference nodes was given for find() and findAll(). So it seems the current spec ended up treating these in the same way by matching nothing: document.querySelector(:scope) document.findAll(:scope) document.findAll(:scope, null) document.findAll(:scope, []) I would have expected the above call to return the documentElement, which is what :scope would match in a non-scoped stylesheet... I can change the spec to make the first 2 examples above match documentElement, but keep the latter two with explicit refNodes parameters matching nothing. -- Lachlan Hunt http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Matching of :scope in document.querySelector(All)
On 12/3/12 7:33 AM, Lachlan Hunt wrote: So it seems the current spec ended up treating these in the same way by matching nothing: document.querySelector(:scope) document.findAll(:scope) document.findAll(:scope, null) document.findAll(:scope, []) That's how I read it, yes. I can change the spec to make the first 2 examples above match documentElement, but keep the latter two with explicit refNodes parameters matching nothing. That sounds great to me. Thanks! -Boris
Re: [selectors-api] Matching of :scope in document.querySelector(All)
On 30 November 2012 02:01, Boris Zbarsky bzbar...@mit.edu wrote: When implementing :scope support, I discovered that as things stand this call: document.querySelector(:scope) is specified to return null. In particular http://dev.w3.org/2006/webapi/selectors-api2/#queryselector step 1 calls http://dev.w3.org/2006/webapi/selectors-api2/#determine-contextual-reference-nodes which returns an empty set. Then this empty set is passed as an explicit contextual reference set to selector matching in http://dev.w3.org/2006/webapi/selectors-api2/#evaluate-a-selector so that :scope doesn't match anything. Is this intentional? I would have expected the above call to return the documentElement, which is what :scope would match in a non-scoped stylesheet... I would expect it to return documentElement too. Webkit's implementation does this. -dean
[selectors-api] Matching of :scope in document.querySelector(All)
When implementing :scope support, I discovered that as things stand this call: document.querySelector(:scope) is specified to return null. In particular http://dev.w3.org/2006/webapi/selectors-api2/#queryselector step 1 calls http://dev.w3.org/2006/webapi/selectors-api2/#determine-contextual-reference-nodes which returns an empty set. Then this empty set is passed as an explicit contextual reference set to selector matching in http://dev.w3.org/2006/webapi/selectors-api2/#evaluate-a-selector so that :scope doesn't match anything. Is this intentional? I would have expected the above call to return the documentElement, which is what :scope would match in a non-scoped stylesheet... -Boris
Re: CfC: Selectors API Level 1 Test Suite; deadline November 23
On Fri, 16 Nov 2012 15:48:28 +0400, Arthur Barstow art.bars...@nokia.com wrote: The RfR for the Selectors API Level 1 test suite passed WebApps' testing group's review (see below), and according to the agreed #Approvalprocess, this now means a group wide review should be done. As such, this is a CfC for this test suite: http://w3c-test.org/webapps/SelectorsAPI/tests/approved/ With no negative feedback, this Call for Consensus passes and we resolve to accept the test suite. for the co-chairs chaals If you have any comments, please send to public-webapps by November 23. If you review any set of the tests and find no issues, please state that as a reply to this RfR (so we can get a sense of who reviewed what). In the absence of any comments, these tests will be considered Approved. Note: for all practical purposes, I suspect the set of people that will actually review our tests are already subscribed to the testsuite list, thus this extra CfC is unlikely to result in additional review. As such, if no one beats me to it ;-), I will (separately) start a thread about streamlining the testing process a bit (for example remove the separate group wide CfC for a test suite and include the test suite review in the CfC to move a spec from CR to PR). However, let's please not derail this CfC on testing process issues. -Thanks, AB #Approval http://www.w3.org/2008/webapps/wiki/Approval Original Message Subject: Re: RfR: Selectors API Level 1 Test Suite - deadline 14 November Resent-Date:Thu, 15 Nov 2012 16:18:17 + Resent-From:public-webapps-testsu...@w3.org Date: Thu, 15 Nov 2012 17:17:42 +0100 From: ext Charles McCathie Nevile cha...@yandex-team.ru Organization: Yandex To: public-webapps-testsu...@w3.org, Lachlan Hunt lachlan.h...@lachy.id.au, Charles McCathie Nevile cha...@yandex-team.ru On Sun, 11 Nov 2012 16:07:08 +0100, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Wed, 24 Oct 2012 14:28:41 +0200, Lachlan Hunt lachlan.h...@lachy.id.au wrote: This is a request for review of the Selectors API Level 1 test suite. This is a formal resolution that the test suite has passed the review, and is accepted. Although the only review we are aware of is Opera's, there are 5 browsers scoring 97-99% on the tests, and people seem to have checked the tests in practice. cheers Chaals (as co-chair) -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
CfC: Selectors API Level 1 Test Suite; deadline November 23
The RfR for the Selectors API Level 1 test suite passed WebApps' testing group's review (see below), and according to the agreed #Approvalprocess, this now means a group wide review should be done. As such, this is a CfC for this test suite: http://w3c-test.org/webapps/SelectorsAPI/tests/approved/ If you have any comments, please send to public-webapps by November 23. If you review any set of the tests and find no issues, please state that as a reply to this RfR (so we can get a sense of who reviewed what). In the absence of any comments, these tests will be considered Approved. Note: for all practical purposes, I suspect the set of people that will actually review our tests are already subscribed to the testsuite list, thus this extra CfC is unlikely to result in additional review. As such, if no one beats me to it ;-), I will (separately) start a thread about streamlining the testing process a bit (for example remove the separate group wide CfC for a test suite and include the test suite review in the CfC to move a spec from CR to PR). However, let's please not derail this CfC on testing process issues. -Thanks, AB #Approval http://www.w3.org/2008/webapps/wiki/Approval Original Message Subject:Re: RfR: Selectors API Level 1 Test Suite - deadline 14 November Resent-Date:Thu, 15 Nov 2012 16:18:17 + Resent-From:public-webapps-testsu...@w3.org Date: Thu, 15 Nov 2012 17:17:42 +0100 From: ext Charles McCathie Nevile cha...@yandex-team.ru Organization: Yandex To: public-webapps-testsu...@w3.org, Lachlan Hunt lachlan.h...@lachy.id.au, Charles McCathie Nevile cha...@yandex-team.ru On Sun, 11 Nov 2012 16:07:08 +0100, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Wed, 24 Oct 2012 14:28:41 +0200, Lachlan Hunt lachlan.h...@lachy.id.au wrote: This is a request for review of the Selectors API Level 1 test suite. This is a formal resolution that the test suite has passed the review, and is accepted. Although the only review we are aware of is Opera's, there are 5 browsers scoring 97-99% on the tests, and people seem to have checked the tests in practice. cheers Chaals (as co-chair) -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more athttp://yandex.com
Re: [selectors-api] Reference to obsolete ECMAScript Language spec version
On 2012-10-29 14:38, Norbert Lindenberg wrote: The current drafts of the Selectors API specifications [1, 2, 3] refer to the third edition of the ECMAScript Language Specification, The references have been updated. Thank you. -- Lachlan Hunt http://lachy.id.au/ http://www.opera.com/
[selectors-api] Editoral Changes and Test Suite Progress
Hi, The test suite has been reviewed by a colleague at Opera, which resulted in a few minor corrections. No corrections required any changes to the implementation report. However, it did result in a few editorial changes to Selectors API spec. These changes should not affect conformance of any implementations. In particular, I fixed the algorithm for processing selectors to explicitly refer to the definition for invalidity in Selectors, with regards to throwing a syntax error. This was always implied, and is what browsers do, but now the spec is clearer. I also updated the Acknowledgements section to include people who have submitted comments over the years who had been missed. I tried to at least include people who's comments resulted in changes to the spec. I believe we can now finally proceed with publishing this as PR, as discussed at TPAC. I will co-ordinate with Chaals to make this happen as soon as possible. -- Lachlan Hunt http://lachy.id.au/ http://www.opera.com/
Re: CFC Selectors API L1 to CR/PR
On Mon, 15 Oct 2012 23:13:53 +0200, wrote: Hi, Formally, this is a Call for Consensus to move Selectors API to CR (and possibly direct to Proposed Recommendation - see below). Responses are due by Friday 26 October, and while silence will be considered assent, formal approval is preferred. As foreshadowed at TPAC, this Call for consensus has passed. We expect to request zero-length CR, if the associated RfR on the test quite doesn't turn up any reason to do otherwise. cheers Chaals In addition, we would appreciate any information implementors may be able to provide about proposed plans for fixing outstanding bugs in their implementations. The Selectors API Level 1 spec [1] has been fundamentally stable for quite a while, and one issue was raised during Last Call, about what to do with comments. Since we are working on a level 2, Lachlan has proposed to leave the comments case undefined for now and figure out what to do during the time Level 2 is finished, which has been accepted by the commenter [2]. The existing test suite [3] has not been approved yet (a separate mail is coming on that) and Lachlan suggests it could use improvement, but it shows two independent browsers passing each test (Opera 12.1 snapshot and Firefox 16 Release both already pass the ns|div tests that are listed as having no passes in the implementation report linked. General-purpose sites like caniuse.com claim it is implemented everywhere. If it is possible to satisfactorily demonstrate interoperable implementability, I propose to request a direct advance to proposed Recommendation. [1] http://www.w3.org/TR/selectors-api/ [2] http://www.w3.org/mid/501fa594.8000...@oupeng.com [3] http://w3c-test.org/webapps/SelectorsAPI/tests/submissions/Opera/level1-baseline.html -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
[selectors-api] Reference to obsolete ECMAScript Language spec version
The current drafts of the Selectors API specifications [1, 2, 3] refer to the third edition of the ECMAScript Language Specification, published 1999, although with a URL that is now home to edition 5.1, published 2011 [4]. Is there a reason to still reference the old version, or can the reference be updated to the current version? BTW, an HTML version of the ECMAScript Language Specification is now available for reference [5]. Norbert [1] http://www.w3.org/TR/selectors-api/ [2] http://dev.w3.org/2006/webapi/selectors-api/ [3] http://dev.w3.org/2006/webapi/selectors-api2/ [4] http://www.ecma-international.org/publications/standards/Ecma-262.htm [5] http://www.ecma-international.org/ecma-262/5.1/
Re: CFC Selectors API L1 to CR/PR
On Mon, 15 Oct 2012 23:13:53 +0200, wrote: Formally, this is a Call for Consensus to move Selectors API to CR (and possibly direct to Proposed Recommendation - see below). Responses are due by Friday 26 October, and while silence will be considered assent, formal approval is preferred. Please reply to this thread to indicate your response. Yandex formally supports Selectors going forward. cheers Chaals In addition, we would appreciate any information implementors may be able to provide about proposed plans for fixing outstanding bugs in their implementations. The Selectors API Level 1 spec [1] has been fundamentally stable for quite a while, and one issue was raised during Last Call, about what to do with comments. Since we are working on a level 2, Lachlan has proposed to leave the comments case undefined for now and figure out what to do during the time Level 2 is finished, which has been accepted by the commenter [2]. The existing test suite [3] has not been approved yet (a separate mail is coming on that) and Lachlan suggests it could use improvement, but it shows two independent browsers passing each test (Opera 12.1 snapshot and Firefox 16 Release both already pass the ns|div tests that are listed as having no passes in the implementation report linked. General-purpose sites like caniuse.com claim it is implemented everywhere. If it is possible to satisfactorily demonstrate interoperable implementability, I propose to request a direct advance to proposed Recommendation. [1] http://www.w3.org/TR/selectors-api/ [2] http://www.w3.org/mid/501fa594.8000...@oupeng.com [3] http://w3c-test.org/webapps/SelectorsAPI/tests/submissions/Opera/level1-baseline.html -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
[selectors-api] Updated Testsuite
Hi, I worked on redesigning the testsuite to resolve a number of issues with the design of the old tests, including removing significant amount of redundancy and fixing broken tests. In the process, I have discovered a number of new bugs in various browsers that need to be addressed. *Summary of Changes* 1. The Level 1 baseline tests are no longer a subset of the additional tests. The baseline and additional test files now test a completely separate set of tests. 2. The :target tests were moved from baseline to additional because :target was added in Selectors 3. 3. All selectors from CSS 1, 2 and Selectors 3 are being tested. 4. level1-lib.js now contains the common functions shared among the 3 testsuites: baseline, additional and xhtml. 5. The files level1-content.html and level1-content.xht contain the all of the (X)HTML that is queried by the API, included within the iframe of each testsuite. Every element in the file is assigned an ID that is used for verification. 6. selectors.js contains all selectors for both valid and invalid selector tests. This includes annotations about the expected result from each selector, with a list of expected element IDs. These IDs are compared with the results from the queries. This change in architecture resolves some major issues with the old testsuite, which had previously resolved in false positives being reported. Notably, the namespace tests. See below. Some additional tests were added for :link and :visited, which now reveal failures in both Gecko and WebKit. Notes: * The Selectors API Level 2 tests have not yet been updated. * Some tests are still needed for :not() and ~ sibling combinator. * Some test descriptions have not been finished in selectors.js. *Failures* Opera: Baseline: 1157 PASS, 10 FAIL * (no parameter) tests (throwing WRONG_ARGUMENTS_ERR instead of TypeError) * #head :link, #head :visited (new bug in 12.10 beta, passes in 12.02) Additional: 512 PASS, 0 FAIL Chrome/Safari: Baseline: 1140 PASS, 27 FAIL * hasFeature() returns false * namespace tests Additional: 508 PASS, 4 FAIL * :target tests Mozilla Gecko: Baseline: 1154 PASS, 13 FAIL * hasFeature() returns false * (no parameter) tests (throwing NS_ERROR_XPC_NOT_ENOUGH_ARGS instead of TypeError) * :link and :visited for fragment and detached element tests failing to match A and AREA elements. Additional: 512 PASS, 0 FAIL * No failures (I haven't got access to IE at this time, so I have not tested it.) The testsuite can be found here. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ All files for these tests are located in the hg repo. http://w3c-test.org/webapps/SelectorsAPI/tests/submissions/Opera/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Updated Testsuite
On 10/22/12 6:10 AM, Lachlan Hunt wrote: * hasFeature() returns false Just as a note, this is a pretty pointless test, and the language about it should be removed from this spec, assuming http://dom.spec.whatwg.org/#dom-domimplementation-hasfeature stays the way it is. * :link and :visited for fragment and detached element tests failing to match A and AREA elements. Presumably https://bugzilla.mozilla.org/show_bug.cgi?id=787134 -Boris
Re: [selectors-api] Updated Testsuite
On Mon, Oct 22, 2012 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/22/12 6:10 AM, Lachlan Hunt wrote: * hasFeature() returns false Just as a note, this is a pretty pointless test, and the language about it should be removed from this spec, assuming http://dom.spec.whatwg.org/#dom-domimplementation-hasfeature stays the way it is. Indeed, please remove http://www.w3.org/TR/selectors-api/#dom-feature-string -- http://annevankesteren.nl/
Re: [selectors-api] Updated Testsuite
On 2012-10-22 16:29, Boris Zbarsky wrote: On 10/22/12 6:10 AM, Lachlan Hunt wrote: * hasFeature() returns false Just as a note, this is a pretty pointless test, and the language about it should be removed from this spec, assuming http://dom.spec.whatwg.org/#dom-domimplementation-hasfeature stays the way it is. I dropped the feature string from both selectors api specs. I'll update the tests shortly. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
On 2012-08-06 13:25, Lachlan Hunt wrote: On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote: (12/07/31 20:06), Arthur Barstow wrote: On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518 I think this is a very minor issue, and it has a simple workaround - mark it as undefined. However, if Lachlan doesn't feel like paying extra fee for versionning (what Anne calls make work) or he thinks having undefineds in a spec significantly lowers the quality, I think that's fair enough and I suggest the way to move forward (if we really want to) is to consider my comment as retracted (let's just do so if Lachlan doesn't reply to this). I'd rather find a way to address the issue. I've just been a bit busy with other tasks for the last 2 weeks to look into this. I'd like feedback from implementers about how best to address the issue. The options I can think of: 1. Disallow all comments within the selector for this API. Throw SyntaxError when they are used. 2. Allow comments, but define that unclosed comments should throw a SyntaxError. 3. Allow comments, define that unclosed comments are silently ignored. After thinking about this for a while, I'm still not much closer to figuring out exactly what the right solution is, nor how the spec should change. But I think it may be acceptable to leave this issue as undefined in Selectors API 1, so as to not continue to hold up taking that spec to Recommendation status. Then we can figure out how to fix it in Selectors API 2, where I can spend more time and effort more clearly defining the parsing requirements. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Kudos on find/findAll, feedback on spec readability
On 2012-09-16 23:40, David Greenspan wrote: 6.2 - ... first matching Element node within the subtrees... Don't define a new term subtrees which just means descendants. Say, ... first matching Element node that is a descendant of the context object. I could do that, but doing so makes it harder to rephrase this statement without making it more complex. 3. The implementation must then run the algorithm to evaluate a selector against element nodes in the specified tree or subtrees using parsed selector as the selector and reference nodes as the contextual reference element set, as needed to return the required result for the invoked method. If you have a suggestion for how to rephrase that to remove subtrees in a readable way without altering the meaning, please let me know. The main take-away from section 6.2 should be that find/findAll use a *different algorithm* from querySelector/querySelectorAll, or the same algorithm with a different setting (relative=true). This point is almost entirely lost. I think the clearest of those two alternatives is to clearly separate the two algorithms. I have made this change in the spec. I think the intent is for the reader to perform a sort of dispatch on type when the algorithm in 6.5 is invoked, but it's confusing because you can't really look at a selector and a relative selector and tell them apart, and certainly not before parsing them. The intent was that the reader is supposed to know whether you have a selector or relative selector based on which method was invoked. The above changes now make that clearer. 6.2 - When either method is invoked... - there are four methods, not 2 Good point, but with the above changes, I also made it more explicit about which methods are being referred to in each case. 6.5 - ... begins with a combinator and that combinator is not ' ' (space) - how can a relative selector, in a comma-separated list with whitespace, physically start with a space, i.e. a descendant combinator?? This was added to clarify that ' ' is excluded from the set of possible combinators that trigger automatic prepending of :scope, regardless of whether the selector meets any of the other conditions. At this stage in the algorithm, no whitespace has been trimmed from the selector, so if the input is div, then it needs to be clear that :scope is not prepended in step 1. Note that there is a known bug in the way the grammar is defined that does actually allow for a relative selector to begin with a descendant combinator. I just haven't figured out a good way to fix this. I have now noted this issue in the spec. Supposing it can (at the beginning of the string, perhaps), why would you special-case it and prepend what's presumably a second descendant combinator in step 5? Because if steps 2, 3 or 4 apply, then step 5 doesn't apply and :scope is not prepended. e.g. document.find( div); // Matches condition in step 2 elm.find( not(:scope)); // Matches condition in step 3 elm.find( body.foo :scope p); // Matches condition in step 4 If space was not excluded, the the spec could be interpreted such that :scope should be prepended in those cases. 7 - contextual reference element - This term is revealed to mean simply a potential :scope element. I would call it something like a scope candidate -- or basically anything besides what it's called. This section was intended to be dropped now that Selectors 4 defines :scope adequately, and as such the term contextual reference element has been removed. However, the term contextual reference element set still remains due to its definition in Selectors 4. If you wish to have that changed, please follow this up with the CSS WG. I have now removed section 7 The :scope Pseudo-class entirely from this spec. 8 - Feature Strings - Change last paragraph to: Conforming implementations must return true ... if they are perfectly compliant, and false if they are not. No. Feature strings are a notoriously unreliably method of determining support for a given feature and it only exists to provide an indication that there is some support for the API, without specifying how compliant a given implementation is. 9 - Examples of find() and :scope MUST be added here. Seriously. This section is the last chance to push that lucky reader over the final threshold to feeling like they fully understand the spec. They will be added in due course. They hadn't been added yet due to the prior instability of the new API design and their low priority. However, feel free to contribute some examples if you like and I will consider including them. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[selectors-api] Kudos on find/findAll, feedback on spec readability
I've been reading the CSS/selector specs lately. I'm interested both as a framework implementer, designing and implementing jQuery-like functionality for Meteor, and as an app developer who looks forward to the days when browsers provide the APIs we want. Coming into the new Selectors API, I was really hoping to discover that the proposed find and findAll methods behaved essentially like the jQuery calls. Put simply, in running elem.find(div p), both the div and the p in question would have to be descendants of elem (as well as each other) in order to match. In running elem.find( div p), there would be the additional constraint that only immediate descendants of elem would be considered as candidates for the div. Unfortunately, this didn't seem to be the case... until I read the spec about a half dozen more times, and I realized it was! If I'm reading it right, the spec does work this way and is additionally much more flexible about the relationship between the element, the scoping element (or elements), and the selector. From reading the list archives, I get the feeling that few web developers who come across the spec understand this much. First of all, I want to offer some encouragement. The names find and findAll are great, and their functionality is exactly what web developers will expect and appreciate. It's familiar and practical. And as long as in basic cases like element.find(a b c + d), it's required that all of a, b, c, and d descend from the element, I am happy with whatever scope selectors and edge cases are necessary or desirable. However, the spec is very hard to understand. I've read several specs cover-to-cover (Java VM, ECMAScript, JPEG) and I think there is a lot of low-hanging fruit in this short document (Selectors API Level 2) -- ways to improve its clarity and enlist your readers more in support of this spec. Some feedback from a reader, for what it's worth. 6.2 - ... first matching Element node within the subtrees... Don't define a new term subtrees which just means descendants. Say, ... first matching Element node that is a descendant of the context object. The main take-away from section 6.2 should be that find/findAll use a *different algorithm* from querySelector/querySelectorAll, or the same algorithm with a different setting (relative=true). This point is almost entirely lost. I think the intent is for the reader to perform a sort of dispatch on type when the algorithm in 6.5 is invoked, but it's confusing because you can't really look at a selector and a relative selector and tell them apart, and certainly not before parsing them. Isn't a relative selector (string) just a selector (string) optionally preceded by a combinator? It seems to me that find() and querySelector() *do different things*, conceptually; for example, the former will add an implicit :scope to your selector and the latter won't. It's nothing to do with their arguments. Given the same arguments, they will do different things. To make it concrete by analogy, how would you interpret this spec (or short of that, how does it feel to read and try to understand)? === Definitions: Chairs are made of wood. Generalized Chairs are made of wood, metal or plastic. The VARNISH function accepts a chair. The PAINT function accepts a generalized chair. VARNISH must coat its input with transparent, Acme brand varnish. PAINT must coat its input with liquid. When either method is invoked, the implementation must perform Algorithm Coat. Algorithm Coat: 1) If the input is a wooden chair, coat it with varnish. 2) Otherwise, if the input is a generalized chair, coat it with paint whose color matches the chair's referential color context. === Here are the stumbling blocks: - If you try to simulate the algorithm, it's a head-scratcher. Aren't wooden chairs also generalized chairs? How do we get to step 2 to paint a wooden chair? Are we really supposed to varnish or paint based on whether the chair is known-to-be-wood or merely incidentally-wood, or is painting wooden chairs not possible? - Presumably, painting was invented to support new chair materials and achieve color-coordinated finishes, yet there is barely a functional description of what PAINT does, let alone the intent. PAINT must coat its input with liquid is the closest thing we have to a definition. - We're describing these two functions along three axes, but the information is so spread out that it is hard to integrate. The ideal in clarity, which admittedly is not always possible with the need to specify algorithms and share them between sections, is something like: === The VARNISH function accepts a chair and coats it with transparent, Acme brand varnish. The PAINT function accepts a generalized chair and coats it with paint whose color matches the chair's referential color context. === That's a breath of fresh air. However, there are many other options, like: === The VARNISH function accepts a chair as its argument. The PAINT
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
On Mon, Aug 6, 2012 at 7:13 PM, Kang-Hao (Kenny) Lu kangh...@oupeng.com wrote: (12/08/06 19:25), Lachlan Hunt wrote: On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote: I'd rather find a way to address the issue. I've just been a bit busy with other tasks for the last 2 weeks to look into this. I'd like feedback from implementers about how best to address the issue. The options I can think of: 1. Disallow all comments within the selector for this API. Throw SyntaxError when they are used. 2. Allow comments, but define that unclosed comments should throw a SyntaxError. 3. Allow comments, define that unclosed comments are silently ignored. Both 1. and 2. would take some extra code in Gecko, in particular 1. I'd note that this is not just about comments. It's about EOF fixing. See [1] for other testcases. [1] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0524 (12/08/07 0:20), Tab Atkins Jr. wrote: Officially, 2.1 defines Kenny's example of html /* as tokenizing into IDENT WS DELIM DELIM, which is then an invalid selector since nothing recognizes those two delims as part of Selector's syntax. No, that's IDENT WS(S) BAD_COMMENT Ah, whoops, indeed. I forgot that BAD_COMMENT existed. This is compatible with Syntax's treatment, where it's recognized as a comment, but triggers a parse error. COMMENT is a bit special here and I think you might want to comment on other cases in [1]. Hm, kk. ~TJ
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
(12/07/31 20:06), Arthur Barstow wrote: On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote: Sorry for my late comment. While I think it's fine to publish LCWD Selectors API as it is, it would be nice if it can address my comment in [1]. By address, I mean either define the desired behavior or explicitly mark it as undefined (which I think is better than not saying anything because an explicit undefined tells a spec reader that relevant discussions can be found in the list). [1] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518 Lachlan, Kenny - what is the status of this comment (f.ex. does the spec need to be changed)? I think this is a very minor issue, and it has a simple workaround - mark it as undefined. However, if Lachlan doesn't feel like paying extra fee for versionning (what Anne calls make work) or he thinks having undefineds in a spec significantly lowers the quality, I think that's fair enough and I suggest the way to move forward (if we really want to) is to consider my comment as retracted (let's just do so if Lachlan doesn't reply to this). To address this issue without marking undefineds, the way is: 0. Make sure this issue is addressed in css3-syntax (CCed Tab Atkins since he is the editor). 1. Link to css3-syntax. 2. Write tests for this issue. but I am not sure if the process will block us at 1. It sure would block us at 2. if implementations haven't changed last since last time I tested with this. Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote: (12/07/31 20:06), Arthur Barstow wrote: On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518 I completely missed that comment of yours when you originally sent it, which is why I didn't address it back then. Lachlan, Kenny - what is the status of this comment (f.ex. does the spec need to be changed)? I think this is a very minor issue, and it has a simple workaround - mark it as undefined. However, if Lachlan doesn't feel like paying extra fee for versionning (what Anne calls make work) or he thinks having undefineds in a spec significantly lowers the quality, I think that's fair enough and I suggest the way to move forward (if we really want to) is to consider my comment as retracted (let's just do so if Lachlan doesn't reply to this). I'd rather find a way to address the issue. I've just been a bit busy with other tasks for the last 2 weeks to look into this. I'd like feedback from implementers about how best to address the issue. The options I can think of: 1. Disallow all comments within the selector for this API. Throw SyntaxError when they are used. 2. Allow comments, but define that unclosed comments should throw a SyntaxError. 3. Allow comments, define that unclosed comments are silently ignored. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
On Mon, Aug 6, 2012 at 4:25 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote: I think this is a very minor issue, and it has a simple workaround - mark it as undefined. However, if Lachlan doesn't feel like paying extra fee for versionning (what Anne calls make work) or he thinks having undefineds in a spec significantly lowers the quality, I think that's fair enough and I suggest the way to move forward (if we really want to) is to consider my comment as retracted (let's just do so if Lachlan doesn't reply to this). I'd rather find a way to address the issue. I've just been a bit busy with other tasks for the last 2 weeks to look into this. I'd like feedback from implementers about how best to address the issue. The options I can think of: 1. Disallow all comments within the selector for this API. Throw SyntaxError when they are used. 2. Allow comments, but define that unclosed comments should throw a SyntaxError. 3. Allow comments, define that unclosed comments are silently ignored. Officially, 2.1 defines Kenny's example of html /* as tokenizing into IDENT WS DELIM DELIM, which is then an invalid selector since nothing recognizes those two delims as part of Selector's syntax. This is compatible with Syntax's treatment, where it's recognized as a comment, but triggers a parse error. So, go with #2. ~TJ
RE: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
From: Lachlan Hunt [mailto:lachlan.h...@lachy.id.au] I'd like feedback from implementers about how best to address the issue. The options I can think of: 1. Disallow all comments within the selector for this API. Throw SyntaxError when they are used. 2. Allow comments, but define that unclosed comments should throw a SyntaxError. 3. Allow comments, define that unclosed comments are silently ignored. I just checked in IE10, and it looks like we actually do: 4. Allow comments, define that unclosed comments are automatically closed. Behavior wise, this means that given the following OM: div id=parent div id=child/div /div The call: document.querySelector(#parent /* #child); Returns the parent div successfully. I'm not sure that I'm thrilled about this behavior, but it is what it is...
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote: Sorry for my late comment. While I think it's fine to publish LCWD Selectors API as it is, it would be nice if it can address my comment in [1]. By address, I mean either define the desired behavior or explicitly mark it as undefined (which I think is better than not saying anything because an explicit undefined tells a spec reader that relevant discussions can be found in the list). [1] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518 Lachlan, Kenny - what is the status of this comment (f.ex. does the spec need to be changed)? -Thanks, Art
[selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
Sorry for my late comment. While I think it's fine to publish LCWD Selectors API as it is, it would be nice if it can address my comment in [1]. By address, I mean either define the desired behavior or explicitly mark it as undefined (which I think is better than not saying anything because an explicit undefined tells a spec reader that relevant discussions can be found in the list). [1] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518 Cheers, Kenny
Reminder: RfC: LCWD of Selectors API Level 1; deadline July 19
Original Message Subject:RfC: LCWD of Selectors API Level 1; deadline July 19 Resent-Date:Thu, 28 Jun 2012 14:59:09 + Resent-From:public-webapps@w3.org Date: Thu, 28 Jun 2012 10:58:36 -0400 From: ext Arthur Barstow art.bars...@nokia.com To: public-webapps public-webapps@w3.org This is a Request for Comments for the June 28 Last Call Working Draft of Selectors API Level 1: http://www.w3.org/TR/2012/WD-selectors-api-20120628/ The comment deadline is July 19 and all comments should be sent to the public-webapps@w3.org list with a Subject: prefix of [selectors-api]. -Thanks, AB
[selectors-api] New Implementation Report for Updated Testsuite
I have now generated a new implementation report [1] to go with the updated testsuite. As I detailed previously on public-webapps-testsuite [2], the new tests use testharness.js and, as a result, some of the tests which passed under the old framework now fail in some browsers. This is mostly because the new tests explicitly check for TypeError on the 'no parameter' tests, whereas the old tests accepted any exception as a pass. WebKit is also failing one of the :target selector tests, probably releated to the way the test loads the testing page in an iframe. [1] http://dev.w3.org/2006/webapi/selectors-api-testsuite/level1-baseline-report.html [2] http://lists.w3.org/Archives/Public/public-webapps-testsuite/2012Jun/0009.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
On 2012-06-28 18:03, Stewart Brodie wrote: Arthur Barstow art.bars...@nokia.com wrote: This is a Request for Comments for the June 28 Last Call Working Draft of Selectors API Level 1: http://www.w3.org/TR/2012/WD-selectors-api-20120628/ The comment deadline is July 19 and all comments should be sent to the public-webapps@w3.org list with a Subject: prefix of [selectors-api]. Section 1 contains a unwanted duplication: With these methods methods, Fixed in both level 1 and 2. There is something odd about the way matching is defined: Section 6 defines matching Element node directly in terms of the [SELECT] reference, then section 6.4 defines what it means to evaluate a selector but this is never referenced. I think section 6 needs to define matching Element node as something like: Oops, this was supposed to have the content similar to that in the level 2 spec defining what to do when the methods were invoked. I've now backported this from that spec, but omitted all things related to :scope. The changes are in the editor's drafts. http://dev.w3.org/2006/webapi/selectors-api/ http://dev.w3.org/2006/webapi/selectors-api2/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
RfC: LCWD of Selectors API Level 1; deadline July 19
This is a Request for Comments for the June 28 Last Call Working Draft of Selectors API Level 1: http://www.w3.org/TR/2012/WD-selectors-api-20120628/ The comment deadline is July 19 and all comments should be sent to the public-webapps@w3.org list with a Subject: prefix of [selectors-api]. -Thanks, AB
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
Arthur Barstow art.bars...@nokia.com wrote: This is a Request for Comments for the June 28 Last Call Working Draft of Selectors API Level 1: http://www.w3.org/TR/2012/WD-selectors-api-20120628/ The comment deadline is July 19 and all comments should be sent to the public-webapps@w3.org list with a Subject: prefix of [selectors-api]. Section 1 contains a unwanted duplication: With these methods methods, There is something odd about the way matching is defined: Section 6 defines matching Element node directly in terms of the [SELECT] reference, then section 6.4 defines what it means to evaluate a selector but this is never referenced. I think section 6 needs to define matching Element node as something like: An Element node is a matching Element node if the result of invoking the *evaluate a selector* algorithm with the selector and the Element bnode is true. And then have the matching rules in a separate explanatory sentence in 6.4: Selectors are evaluated against the given element according to the rules for matching elements defined in Selectors [SELECT]. This would seem to be the original intention - the algorithm was added, but then section 6 wasn't updated (it's the same as in the previous CR) Did an edit go missing somewhere? -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited
Re: CfC: publish a LCWD of Selectors API Level 1; deadline June 25
On 2012-06-18 15:57, Arthur Barstow wrote: Lachlan has made some changes to the Selectors API Level 1 spec (last published as a CR) and we consider the changes sufficient to require the spec be published as a Working Draft (see the [1] thread). As such, this is a Call for Consensus to publish a new LCWD of this spec using the following document as the basis http://dev.w3.org/2006/webapi/selectors-api/. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by June 25 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. This draft has been prepared for publication and checked into the repository. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: CfC: publish WD of Selectors API Level 2; deadline June 25
On 2012-06-18 15:41, Arthur Barstow wrote: Lachlan would like to publish a new Working Draft of the Selectors API Level 2 spec and this is a Call for Consensus to do so using the following Editor's Draft as the basis http://dev.w3.org/2006/webapi/selectors-api2/. If you have any comments or concerns about this proposal, please reply to this e-mail by June 25 at the latest. This draft has been prepared for publication and checked into the repository. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 2012-06-18 11:06, Lachlan Hunt wrote: Since it seems there are no objections to the latter option, and a few people in favour of that, I've tentatively updated both drafts to reflect this. It now states: If the group of selectors include namespace prefixes that need to be resolved, the implementation must raise a SYNTAX_ERR exception http://dev.w3.org/2006/webapi/selectors-api/#resolving-namespaces http://dev.w3.org/2006/webapi/selectors-api2/#resolving-namespaces I have now updated the testsuite to reflect this change. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Wed, 20 Jun 2012 16:26:14 +0200, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. Yeah, if that works, it's fine. Back then we were in a position where people cared enough to object, so we chose a different way of making most of the people unhappy that drew less objection... cheers Chaals (You think this is bad, people bikeshed how I should write *my*name* ...) -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 2012-06-20 17:46, Marat Tanalin | tanalin.com wrote:
20.06.2012, 18:14, Lachlan Hunt lachlan.h...@lachy.id.au:
4. Support for returning elements that are not descendants of the
context object.
This feature allows a selector to be constructed such that it matches an
element anywhere in the tree relative to the context element. This
feature is not relevant to document.find(), since it can already return
anything from the whole tree.
elm.find(+span)// span is a sibling
elm.find(/for/ input) // input could be anywhere
elm.find(:not(:scope)) // Everything except the context object
This feature cannot be supported on Element.qSA, even when using eplicit
:scope, because matching elements need to be descendants of the context
object.
It's unclear why an _updated_ qSA version should have same limitation
that matching elements need to be descendants of the context
object. There is nothing obvious that makes h1.querySelector('+ H2')
impossible to work in newer implementations (in older ones it would
not work anyway -- to the same extent as `elm.querySelector(span)`
that you've declared as could work).
Supporting this without the risk of breaking compatibility would require
switching selection behaviour based on the presence of the :scope pseudo
class (either explicit or implied), for each individual selector in the
group. When :scope is present, then matching could be applied to the
entire tree, just like it is in element.find().
That is, given the group of selectors:
elm.querySelectorAll(:scope+p, div p)
(Note: After pre-processing, there is no difference between explicit
:scope and implied :scope in +p)
Only :scope+p would be permitted to match non-descendant elements and
the other div p would have to retain the backwards compatible
selection behaviour where the subject of the selector must be a
descendant of the context object.
That means, the implementation would need to split the group of
selectors such that :scope+p (or any other selector with explicit or
implied :scope) is potentially compared with all elements in the tree.
Then the other selector div p should only be compared with descendants
of the context object.
It will also not work for the reference combinator in some cases. If
switching selection behaviour depends on the presence of :scope, then
the reference combinator will not always work effectively.
elm.querySelectorAll(label /for/ input)
In this case with no :scope, the matching input must be a descendant of
the context object, but the label may or may not be. Compare that with
this:
elm.findAll(label /for/ input)
In this case, :scope is implied at the beginning, so the label must be a
descendant of the context object, but the matching input elements may
appear anywhere in the tree.
Overall, this adds significant complexity to the implementations, so
while it may actually be technically possible in some cases, it's far
from ideal and doesn't address all problems.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
(12/06/20 22:26), Lachlan Hunt wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. While I don't think a WG vote is the right way to do, I strongly disagree that naming of a function belongs to an editorial decision. Changing the name of a function requires all the tests be rewritten, and therefore it is by definition not editorial. The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. While I agree that trying to please everyone is foolish, I am curious about data that can be used to prove the the least-objectionable alternative is rarely the best alternative statement. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor, but from a outsider's point of view, along with the final decision, I also care about a detailed description about why a function name is chosen. For example, attributing the poor querySelector decision to an abstract concept of design by committee doesn't seem to be reasonable and genuine. I'd rather want to see a long explanation like: Despite the fact the editor thinks function name X is better than 'querySelector', there were a few people (name goes here) who were strongly opposed to X and a group vote happened and a decision was made by (name goes here). Nobody ran a compatibility research. And this time, I would like to ask whoever is going to make the decision to take the opinion of the *public* into account. I am not saying it should be the sole factor, but what I am looking for is an explanation like Compatibility research shows that both name X and Y are fine. 70% of the Web developers are in favor of name X and therefore X is chosen. or Despite 70% of the Web developers are in favor of name X, compatibility research shows that or even Despite 70% of the Web developers are in favor of name X, 100% of browser developers are not and therefore ... or even Nobody ran either a public vote and compatibility research and the editor made the decision on X because he likes it. (Seriously, I don't see why a rationale like this is better than the one for querySelector as this is pretty much just s/WG/editor/ of that since the WG vote didn't represent the public, but at least this is easier to understand than design by committee or design by editor, which is just well, difficult to understand to a causal person who cares about the standard but doesn't have the bandwidth to go in.) In other words, while I can agree that a single +1/-1 statement isn't strong as a rationale (or even not a rationale) I beg you to take the sum as a valid and strong rationale, at least in this case where X and Y don't have much difference. And I am still interested in what really happened last time. (will try to bring real feedback next time.) Cheers, Kenny
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 2012-06-21 15:56, Kang-Hao (Kenny) Lu wrote: (12/06/20 22:26), Lachlan Hunt wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. While I don't think a WG vote is the right way to do, I strongly disagree that naming of a function belongs to an editorial decision. Changing the name of a function requires all the tests be rewritten, and therefore it is by definition not editorial. By editorial decision, I meant that the decision of what to name it should be up to the editor, not that it is a minor editorial issue. Sorry for the confusion. Fixing tests is trivial, but the name should be decided before implementation begins and a testsuite is written anyway. At this stage, I haven't seen any overly strong objections to the names find/findAll anyway, so hopefully this is a non-issue. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor, but from a outsider's point of view, along with the final decision, I also care about a detailed description about why a function name is chosen. For example, attributing the poor querySelector decision to an abstract concept of design by committee doesn't seem to be reasonable and genuine. I'd rather want to see a long explanation like: What happened last time was that I carefully reviewed the entire debate, taking into account all arguments for and against every suggested alternative I found at the time and posted a thorough review and rationale for the decision I made at the end. http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0077.html This then resulted in some people in the group complaining loudly enough because they weren't happy, mostly because it's impossible to please everyone, leading to a vote between 6 choices, ultimately overruling me. Anecdotally, I heard from a few web developers at the time saying they even liked the names I'd chosen, despite them being a little long, but were later disappointed with the result of the vote. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/20 22:26), Lachlan Hunt wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. While I agree that trying to please everyone is foolish, I am curious about data that can be used to prove the the least-objectionable alternative is rarely the best alternative statement. I don't think there is any readily available. There are no clear criteria for judging best, although there are some clear criteria for judging bad - for example things that often get confused are definitely bad. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor Pretty much what Lachy said. As chair, I was the one who decided there ws too much objection and called for some other process. I don't claim it was especially good or came up with a great name, but I don't think it was awful and I don't see a better alternative if the situation arises again. Despite the fact the editor thinks function name X is better than 'querySelector', there were a few people (name goes here) who were strongly opposed to X and a group vote happened and a decision was made by (name goes here). Nobody ran a compatibility research. And this time, I would like to ask whoever is going to make the decision to take the opinion of the *public* into account. I am not saying it should be the sole factor, but what I am looking for is an explanation like Compatibility research shows that both name X and Y are fine. 70% of the Web developers are in favor of name X and therefore X is chosen. We don't have that data. We don't agree which web developers are the ones whose opinions matter - those who type a name once a month and want something self-explanatory, or those who type it once every 3 minutes, or those who write tools to avoid typing it at all, or ... And then we don't have representative samples. We know, for example, that focus/blur made sense to english-speaking developers but confused millions of developers whose first language was something else. So claiming we are basing a decision on the data will probably give results as arbitrary as the process we used, but with a veneer of intellectual dishonesty. Seriously, I don't see why a rationale like this is better than the one for querySelector as this is pretty much just s/WG/editor/ of that since the WG vote didn't represent the public Sure. In other words, while I can agree that a single +1/-1 statement isn't strong as a rationale (or even not a rationale) I beg you to take the sum as a valid and strong rationale, at least in this case where X and Y don't have much difference. And I am still interested in what really happened last time. (It is instructive to think for five minutes about the things that can go wrong, and how much effort we should spend on trying to get it right) Essentially, a bunch of people tossed up all the reasons to object to a name that they could think of based on their experience of things that go wrong. Based on that, some proposals were rapidly rejected, and then we looked at the rest, kicking the tyres of each in turn until we figured out which one the most people didn't think was truly problematic. It can be dismissed as design by committee, but it can also be characterised as applying the wisdom of several smart people to avoid as many pitfalls as possible. Frankly I think that suggesting one is smarter than any committee of smart people could be is a bold claim - if nobody is especially happy with the outcome, it can often be said that a number of very clever hardworking people recognise that it doesn't have any of several obvious problems they can name, and they think it is an acceptable outcome. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Selectors API Implementation Report
Hi, I have created a basic implementation report covering the baseline tests. All 5 browser implementations are at 99.2% pass rate, each browser only failing 8 of these tests because of the recent change for the NAMESPACE_ERR issue. http://dev.w3.org/2006/webapi/selectors-api-testsuite/001-report.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
(12/06/21 23:28), Charles McCathieNevile wrote: On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/20 22:26), Lachlan Hunt wrote: The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. While I agree that trying to please everyone is foolish, I am curious about data that can be used to prove the the least-objectionable alternative is rarely the best alternative statement. I don't think there is any readily available. There are no clear criteria for judging best, although there are some clear criteria for judging bad - for example things that often get confused are definitely bad. Well, yes, though I wonder why we can't define best to be what gets the most public votes (just in this case, please don't generalize this to cases when X and Y are having different implementation difficulty). Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor Pretty much what Lachy said. As chair, I was the one who decided there ws too much objection and called for some other process. I don't claim it was especially good or came up with a great name, but I don't think it was awful and I don't see a better alternative if the situation arises again. Thanks for the information (and to Lachy too). I also found the vote[1] itself quite interesting. [1] http://www.w3.org/2002/09/wbs/38482/selectorsNames/results Despite the fact the editor thinks function name X is better than 'querySelector', there were a few people (name goes here) who were strongly opposed to X and a group vote happened and a decision was made by (name goes here). Nobody ran a compatibility research. And this time, I would like to ask whoever is going to make the decision to take the opinion of the *public* into account. I am not saying it should be the sole factor, but what I am looking for is an explanation like Compatibility research shows that both name X and Y are fine. 70% of the Web developers are in favor of name X and therefore X is chosen. We don't have that data. We don't agree which web developers are the ones whose opinions matter - those who type a name once a month and want something self-explanatory, or those who type it once every 3 minutes, or those who write tools to avoid typing it at all, or ... And then we don't have representative samples. We know, for example, that focus/blur made sense to english-speaking developers but confused millions of developers whose first language was something else. So claiming we are basing a decision on the data will probably give results as arbitrary as the process we used, but with a veneer of intellectual dishonesty. I claim that numeric data is as honest as we ever can be. Taking a look at Lachy's summary, I have to say while I appreciate the effort spent on this, there are really just contradictory sentences that made me frown, and Lachy later admitted[2]: [[ In hindsight, looking at the arguments above, I probably did let my own personal dislike of the name get in the way of my objectivity in this case, as much as I tried to avoid doing so. As such, I am now willing to consider these alternatives. ]] . Debating these rationale seems to be a waste of time too. I don't see why doing a public poll can be considered dishonest. The honest description would just be We ran a public poll on (pointer goes here) with X people, Y % of them are Web developers (pointer to the statistics goes here). The result ... [2] http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0120 (It is instructive to think for five minutes about the things that can go wrong, and how much effort we should spend on trying to get it right) Essentially, a bunch of people tossed up all the reasons to object to a name that they could think of based on their experience of things that go wrong. Based on that, some proposals were rapidly rejected, and then we looked at the rest, kicking the tyres of each in turn until we figured out which one the most people didn't think was truly problematic. It can be dismissed as design by committee, but it can also be characterised as applying the wisdom of several smart people to avoid as many pitfalls as possible. Frankly I think that suggesting one is smarter than any committee of smart people could be is a bold claim - if nobody is especially happy with the outcome, it can often be said that a number of very clever hardworking people recognise that it doesn't have any of several obvious problems they can name, and they think it is an acceptable outcome. I never like the design by committee term because it seems to suggest a solution (the benevolent dictator) without explaining what's going on. In the querySelector case, although I admit that I think what
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Wed, 20 Jun 2012 06:19:22 +0200, Elliott Sprehn espr...@gmail.com wrote: On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: ... This is not a good argument. qSA is used often enough, and has a long enough name, that the name is actually a pretty significant misfeature. This is a pretty core API, and both it and its precursors (getElementByID, etc.) are very commonly renamed by libraries precisely because you need a very short name for such a commonly used function. Why does it need a short name? If the name is too long to type then that's an argument for better IDEs. Otherwise you end up with stuff like strncpy to save typing. gzip eliminates the file size issue. I'm in agreement with Marat that find() is not as clear as most DOM APIs usually are. findBySelector() makes much more sense. In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. getElementsB(y)Selector is consistent with the platform, subject to getting the s wrong, awfully long. find is too short for a general platform that has lots of ways of finding things and things you might be finding. querySelector is just sucky. But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. If you want quick typing, alias it. If you want to know what it does because you only use it once a month (or in my case about once every six months), the name is barely clear enough. There are no good answers here, since there are significant and competing needs. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. Right now, that draft uses find/findAll() simply because they're the names that were used throughout the discussion that led to them being added. There are still issues to resolve, however, which I would like feedback on. In particular, is there really value in adding two distinct methods that differ only by whether they return 1 element or a collection? Resolving this issue first would help with resolving the naming issue. It should be noted that JQuery/sizzle does not use querySelector() at all, AFAICS. It only uses querySelectorAll() and sometimes switches to .getElementById() or document.body. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Consider backporting find() behavior to querySelector()
20.06.2012, 18:26, Lachlan Hunt lachlan.h...@lachy.id.au:
In particular, is there really value in adding two distinct methods that
differ only by whether they return 1 element or a collection? Resolving
this issue first would help with resolving the naming issue.
It should be noted that JQuery/sizzle does not use querySelector() at
all, AFAICS. It only uses querySelectorAll() and sometimes switches to
.getElementById() or document.body.
The whole jQuery's paragigm of always searching all matching elements is a
potentially big shortcoming of jQuery as for (at least) performance. It's
natural to suppose that searching for just _first_ matching element and
returning immediately once it's found should be much _faster_ than searching
for _all_ matching elements (be it 100 or 1000 elements) even if we need just
first one.
So yes, we need two separate methods: one to select first matching element and
another one to select all matching elements. They could be united into one
single method with an optional argument, but I doubt it would be quite handy
and nonconfusing for using. Also, a method generally should return consistent
result as for type of returning value, so if we had one method that always
returns collection of elements, that would force us to often use the method
with item accessor (like find('A')[0]) that would be redundant, unusable and
less readable.
For example, I very like `querySelector()` and use it at least as much as (and
maybe even more often than) `querySelectorAll()`.
Re: [selectors-api] Consider backporting find() behavior to querySelector()
It should be noted that JQuery/sizzle does not use querySelector() at all, AFAICS. It only uses querySelectorAll() and sometimes switches to .getElementById() or document.body. I took a look at using querySelector as an optimization a while back but it did not seem to make a significant difference in speed, at least once the library overheads were included. This test html is based on the msn.comhome page to be representative of a big real-life document. http://jsperf.com/findone-vs-findall The reason we switch to getElementById is because querySelectorAll is much slower for that case. qSA can retrieve multiple elements in invalid documents with duplicate IDs, but that's not a case we are worried about.
Re: [selectors-api] Consider backporting find() behavior to querySelector()
20.06.2012, 18:14, Lachlan Hunt lachlan.h...@lachy.id.au:
4. Support for returning elements that are not descendants of the
context object.
This feature allows a selector to be constructed such that it matches an
element anywhere in the tree relative to the context element. This
feature is not relevant to document.find(), since it can already return
anything from the whole tree.
elm.find(+span) // span is a sibling
elm.find(/for/ input) // input could be anywhere
elm.find(:not(:scope)) // Everything except the context object
This feature cannot be supported on Element.qSA, even when using eplicit
:scope, because matching elements need to be descendants of the context
object.
It's unclear why an _updated_ qSA version should have same limitation that
matching elements need to be descendants of the context object. There is
nothing obvious that makes h1.querySelector('+ H2') impossible to work in newer
implementations (in older ones it would not work anyway -- to the same extent
as `elm.querySelector(span)` that you've declared as could work).
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 6/20/12 10:52 AM, Dave Methvin wrote: This test html is based on the msn.com http://msn.com home page to be representative of a big real-life document. For what it's worth, that document has about 2200 DOM nodes. That's two orders of magnitude smaller than big real-life documents. This is a medium-small real-life document. Just for scale, the google.com homepage has about 500 DOM nodes. The W3C homepage has about 1400 DOM nodes. A Zimbra UI with about 200 messages in the inbox is about 5000 nodes. Anything that does dynamic UI stuff will tend to be in the 5k-50k node range. Of course the library overhead might still kill you enough that it doesn't matter... -Boris
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 6/20/12 11:34 AM, Marat Tanalin | tanalin.com wrote: It's natural to suppose that searching for just _first_ matching element and returning immediately once it's found should be much _faster_ than searching for _all_ matching elements (be it 100 or 1000 elements) even if we need just first one. It's natural to suppose that, but it would be wrong if the majority of the time is spent setting up the search (e.g. preprocessing the selector, which jQuery does), not actually searching For example, I very like `querySelector()` and use it at least as much as (and maybe even more often than) `querySelectorAll()`. If you're calling these directly, there's a lot less preprocessing going on. -Boris
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/18 22:45), Simon Pieters wrote: I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. I didn't read through all the QSA threads, but isn't the function name itself a mistake that many people don't want to live with? We have lots of shipped APIs with worse names. I think we should live with past mistakes, try not to make them again, and move on. -- Simon Pieters Opera Software
Re: CfC: publish a LCWD of Selectors API Level 1; deadline June 25
On Mon, 18 Jun 2012 15:57:02 +0200, Arthur Barstow art.bars...@nokia.com wrote: Lachlan has made some changes to the Selectors API Level 1 spec (last published as a CR) and we consider the changes sufficient to require the spec be published as a Working Draft (see the [1] thread). As such, this is a Call for Consensus to publish a new LCWD of this spec using the following document as the basis http://dev.w3.org/2006/webapi/selectors-api/. Please publish :) cheers -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [selectors-api] Consider backporting find() behavior to querySelector()
I am very opposed to this, they do different things. Having abilities isn't a bad thing and numerous Web sites and libraries make use of qsa, not just because find was not available but because different APIs shapes interesting new possibilities, different ways of looking at problems, etc... We solve problems with the tools at hand, so given that it has been widely implemented a long time, you can safely assume we have found good uses for it. There are a vast number of libraries and websites that have use cases for find, this is especially true because selector engines that solved those cases evolved in the wild a long time ago it probably would have been nice to have had that native first, as it would have been a more immediate help for the vast number of users, but qsa is definitely useful. On Jun 18, 2012 10:45 AM, Simon Pieters sim...@opera.com wrote: So http://dev.w3.org/2006/webapi/**selectors-api2/http://dev.w3.org/2006/webapi/selectors-api2/introduces the methods find() and findAll() in addition to querySelector() and querySelectorAll() and changes the scoping behavior for the former methods to match what people expect them to do. I'm not convinced that doubling the API surface is a good idea. If we were to do that every time we find that a shipped API has suboptimal behavior, the API surface on the Web would grow exponentially and we wouldn't make the overall situation any better. What if we find a new problem with find() after it has shipped? Do we introduce yet another method? I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. -- Simon Pieters Opera Software
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters sim...@opera.com wrote: On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/18 22:45), Simon Pieters wrote: I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. I didn't read through all the QSA threads, but isn't the function name itself a mistake that many people don't want to live with? We have lots of shipped APIs with worse names. I think we should live with past mistakes, try not to make them again, and move on. This is not a good argument. qSA is used often enough, and has a long enough name, that the name is actually a pretty significant misfeature. This is a pretty core API, and both it and its precursors (getElementByID, etc.) are very commonly renamed by libraries precisely because you need a very short name for such a commonly used function. ~TJ
Re: [selectors-api] Consider backporting find() behavior to querySelector()
20.06.2012, 00:38, Tab Atkins Jr. jackalm...@gmail.com: On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters sim...@opera.com wrote: On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: We have lots of shipped APIs with worse names. I think we should live with past mistakes, try not to make them again, and move on. This is not a good argument. qSA is used often enough, and has a long enough name, that the name is actually a pretty significant misfeature. This is a pretty core API, and both it and its precursors (getElementByID, etc.) are very commonly renamed by libraries precisely because you need a very short name for such a commonly used function. There is a key difference between native functionality and one implemented as a library -- they quite differently relate to backward compatibility. A library can be rewritten partially or even entirely if needed (older applications can just continue using older versions of the library), while native functionality, once widely implemented, have to be supported forever and in fact cannot (and should never) be dropped. As for `querySelector()` in particular, its name is indeed not the best, but _not_ because it's too long, but because it's not quite _clear_ / _self-documenting_. `querySelector()` and `querySelectorAll()` should have been named `getElementBySelector()` and `getElementsBySelector()` instead. In this regard, `find()` is far less clear (and even confusing) as for what it does.
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: ... This is not a good argument. qSA is used often enough, and has a long enough name, that the name is actually a pretty significant misfeature. This is a pretty core API, and both it and its precursors (getElementByID, etc.) are very commonly renamed by libraries precisely because you need a very short name for such a commonly used function. Why does it need a short name? If the name is too long to type then that's an argument for better IDEs. Otherwise you end up with stuff like strncpy to save typing. gzip eliminates the file size issue. I'm in agreement with Marat that find() is not as clear as most DOM APIs usually are. findBySelector() makes much more sense. - Elliott - E
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On Sun, 17 Jun 2012 13:10:11 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: 1. Explicitly undefine this case. That would not be my preference. 2. Spec IE9, Firefox13 and Opera12alpha's behavior Roughly speaking, the choice is an invalid token or '|' whichever comes first, but I'd note that in the corner case These are valid: |a *|a My proposed spec change: # If the group of selectors include namespace prefixes that need to # be resolved, the implementation must raise a NAMESPACE_ERR # exception. s/NAMESPACE_ERR/SYNTAX_ERR/ -- Simon Pieters Opera Software
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 2012-06-18 04:29, Boris Zbarsky wrote: Consider how this is parsed in a depth-first recursive descent parser: a|b +, 1) The identifier a is scanned. This might be a tag name or a namespace; look at the next token. 2) The symbol '|' is scanned. Great. a was a namespace. Resolve it. And you're done. You have an error and bail out. You never even got to the '+'. This is a good reason not to strictly define one having precedence over the other. That leaves 2 options: Leaving it explicitly undefined (only mildly better than the current situation) or using only syntax error. Since it seems there are no objections to the latter option, and a few people in favour of that, I've tentatively updated both drafts to reflect this. It now states: If the group of selectors include namespace prefixes that need to be resolved, the implementation must raise a SYNTAX_ERR exception I also removed the note about non-namespace supporting implementations throwing a syntax error instead of a namespace error. http://dev.w3.org/2006/webapi/selectors-api/#resolving-namespaces http://dev.w3.org/2006/webapi/selectors-api2/#resolving-namespaces -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Updates to Selectors API
On 6/14/12 10:11 AM, ext Lachlan Hunt wrote: Hi, I have updated the specification for Selectors API Level 1, which is currently in CR. Most of it was editorial in nature, to bring it in line with Selectors API Level 2, except without adding any of the new features like findAll() or or matches(). Importantly, the IDL has now been updated to comply with the most recent WebIDL specificiation. This was basically to split it up into 3 partial interfaces, just like what was previously done in v2. Some of the prose was rewritten, but none of the changes should adversely affect implementation requirements. This was mostly done by back porting the content from v2, but while ensuring that all the normative references still refer to the older, stable specs. (e.g. DOM3Core instead of using DOM4, as is used in the v2 draft.) This now makes v1 a proper subset of v2. In the process, I also made a few minor editorial changes to v2 just to tidy it up. At this stage, we should be able to publish v1 as a revised CR, or possibly move it up to PR. I like the changes Lachlan, especially the new section 6.4. Although I have argued to the Advisory Committee and Advisory Board the process should (under certain circumstances) permit a CR to be directly re-published as a CR, that currently is not possible. Nevertheless, I think it could be a bit tricky to argue to the Director in this case that there were no substantive changes (e.g. the new 6.4) so my recommendation is that we publish a new LCWD with the minimum 3-week review period (and make sure all of the changes can be reviewed). At the end of the LC review period, if no substantive changes are needed, and we already have sufficient interop data (i.e. the 2009 CR exit criteria is already met), we could skip a new CR and directly publish a PR. Do you or Chaals have the interop data now (and if so, where is it)? What do you think about going the LC-PR route? We can also publish v2. as a new WD. If you want me to start a CfC to publish a new WD of v2, just let me know. -Thanks, Art Alternatively, we could forgo any further progress with v1 and let v2 supersede it entirely, at which point I could simply rename it back to Selectors API without a version number and move on. (This is my preferred approach). http://dev.w3.org/2006/webapi/selectors-api/ http://dev.w3.org/2006/webapi/selectors-api2/
Re: Updates to Selectors API
On 2012-06-18 13:57, Arthur Barstow wrote: In the process, I also made a few minor editorial changes to v2 just to tidy it up. At this stage, we should be able to publish v1 as a revised CR, or possibly move it up to PR. I like the changes Lachlan, especially the new section 6.4. Although I have argued to the Advisory Committee and Advisory Board the process should (under certain circumstances) permit a CR to be directly re-published as a CR, that currently is not possible. Nevertheless, I think it could be a bit tricky to argue to the Director in this case that there were no substantive changes (e.g. the new 6.4) so my recommendation is that we publish a new LCWD with the minimum 3-week review period (and make sure all of the changes can be reviewed). OK. Let's get started on that process. Do you or Chaals have the interop data now (and if so, where is it)? What do you think about going the LC-PR route? Opera, Firefox, Safari, Chrome and IE all pass 100% of the baseline (HTML/CSS 2.1 selectors) and additional (HTML/Selectors 3) tests. Firefox, Safari and Chrome also pass 100% of the XHTML/Selectors 3 tests. Opera only passes 99.2% of these and IE only passes 67.7% of these. However, these are additional tests that are not required to declare interoperability of the API, as the failures relate more to XHTML and Selectors support, rather than any particular bug with the API. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ Do I need to prepare some kind of formal testsuite report with the results for each test? However, with the recent change from NAMESPACE_ERR to SYNTAX_ERR, this test suite will need to be updated with new tests, so this will likely delay PR for a little bit longer. We can also publish v2. as a new WD. If you want me to start a CfC to publish a new WD of v2, just let me know. Yes please. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Updates to Selectors API
On 6/18/12 8:34 AM, ext Lachlan Hunt wrote: On 2012-06-18 13:57, Arthur Barstow wrote: In the process, I also made a few minor editorial changes to v2 just to tidy it up. At this stage, we should be able to publish v1 as a revised CR, or possibly move it up to PR. I like the changes Lachlan, especially the new section 6.4. Although I have argued to the Advisory Committee and Advisory Board the process should (under certain circumstances) permit a CR to be directly re-published as a CR, that currently is not possible. Nevertheless, I think it could be a bit tricky to argue to the Director in this case that there were no substantive changes (e.g. the new 6.4) so my recommendation is that we publish a new LCWD with the minimum 3-week review period (and make sure all of the changes can be reviewed). OK. Let's get started on that process. OK, I'll start the CfC for LC today. Do you or Chaals have the interop data now (and if so, where is it)? What do you think about going the LC-PR route? Opera, Firefox, Safari, Chrome and IE all pass 100% of the baseline (HTML/CSS 2.1 selectors) and additional (HTML/Selectors 3) tests. Firefox, Safari and Chrome also pass 100% of the XHTML/Selectors 3 tests. Opera only passes 99.2% of these and IE only passes 67.7% of these. However, these are additional tests that are not required to declare interoperability of the API, as the failures relate more to XHTML and Selectors support, rather than any particular bug with the API. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ Do I need to prepare some kind of formal testsuite report with the results for each test? Yes, we do need to document the spec has interoperable implementations (and that is typically called the interop report). I think we have considerable flexibility on the format of the data. Here are a couple of examples: * Cam's Element Traversal http://www.w3.org/2008/webapps/ElementTraversal/index.html * Marcos' widget spec http://dev.w3.org/2006/waf/widgets/imp-report/ However, with the recent change from NAMESPACE_ERR to SYNTAX_ERR, this test suite will need to be updated with new tests, so this will likely delay PR for a little bit longer. OK, that's good to know. The LC's status section should include the URI of the interop report although that document can be empty when the LC is published. (I think the status section should also mention the group expects to skip CR and go directly to PR.) We can also publish v2. as a new WD. If you want me to start a CfC to publish a new WD of v2, just let me know. Yes please. Will do. -Thanks, Art
CfC: publish WD of Selectors API Level 2; deadline June 25
Lachlan would like to publish a new Working Draft of the Selectors API Level 2 spec and this is a Call for Consensus to do so using the following Editor's Draft as the basis http://dev.w3.org/2006/webapi/selectors-api2/. Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by June 25 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. -Thanks, AB
CfC: publish a LCWD of Selectors API Level 1; deadline June 25
Lachlan has made some changes to the Selectors API Level 1 spec (last published as a CR) and we consider the changes sufficient to require the spec be published as a Working Draft (see the [1] thread). As such, this is a Call for Consensus to publish a new LCWD of this spec using the following document as the basis http://dev.w3.org/2006/webapi/selectors-api/. This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by June 25 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. The proposed LC review period is 3 weeks. -Thanks, AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1189.html
[selectors-api] Consider backporting find() behavior to querySelector()
So http://dev.w3.org/2006/webapi/selectors-api2/ introduces the methods find() and findAll() in addition to querySelector() and querySelectorAll() and changes the scoping behavior for the former methods to match what people expect them to do. I'm not convinced that doubling the API surface is a good idea. If we were to do that every time we find that a shipped API has suboptimal behavior, the API surface on the Web would grow exponentially and we wouldn't make the overall situation any better. What if we find a new problem with find() after it has shipped? Do we introduce yet another method? I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. -- Simon Pieters Opera Software
Re: [selectors-api] Consider backporting find() behavior to querySelector()
(12/06/18 22:45), Simon Pieters wrote: I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. I didn't read through all the QSA threads, but isn't the function name itself a mistake that many people don't want to live with? I'd rather like to see querySelector() marked as deprecated so it doesn't appear in tutorials in the future. Cheers, Kenny
RE: [selectors-api] Consider backporting find() behavior to querySelector()
-Original Message- From: Kang-Hao (Kenny) Lu [mailto:kennyl...@csail.mit.edu] (12/06/18 22:45), Simon Pieters wrote: I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. I didn't read through all the QSA threads, but isn't the function name itself a mistake that many people don't want to live with? I'd rather like to see querySelector() marked as deprecated so it doesn't appear in tutorials in the future. Despite being non-optimal according to a vocal sub-set of people, querySelector[All] has been deployed in browsers for around 3-4 years. I strongly oppose any notion of altering its behavior now. As to find/findAll, let's just make sure we get the behavior right the second time so we don't go through this again.
RE: publish WD of Selectors API Level 2; deadline June 25
From: Arthur Barstow [mailto:art.bars...@nokia.com] Lachlan would like to publish a new Working Draft of the Selectors API Level 2 spec and this is a Call for Consensus to do so using the following Editor's Draft as the basis http://dev.w3.org/2006/webapi/selectors-api2/. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. I support the publication of a new WD. -Travis
[selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
The spec (either Level 1 or Level 2) is unclear about which error should be raised in a situation when both NAMESAPCE_ERR and SYNTAX_ERR apply, and this is not the same in all browsers. That is, for a selector like a|b + or a|b, + IE9, Firefox 13 and Opera12alpha raise NAMESAPCE_ERR, while Chrome19 raises SYNTAX_ERR. Two proposed solutions (sorted by my preference): 1. Explicitly undefine this case. I don't think having interoperability on this is of big importance, but in general having an explicit undefined is usually better than an implicit one. Proposed text: change # If the group of selectors include namespace prefixes that need to # be resolved, the implementation must raise a NAMESPACE_ERR # exception. to | If the group of selectors include namespace prefixes that need to | be resolved and match either dom_selectors_group or | dom_relative_selectors_group, the implementation must raise a | NAMESPACE_ERR exception. If the group of selectors include | namespace prefixes that need to be resolved and /doesn't/ match | either dom_selectors_group or dom_relative_selectors_group, the | implementation must raise either a NAMESPACE_ERR exception or a | SYNTAX_ERR exception. The exact choice is undefined. 2. Spec IE9, Firefox13 and Opera12alpha's behavior Roughly speaking, the choice is an invalid token or '|' whichever comes first, but I'd note that in the corner case a| Firefox13 and Oper12alpha raise NAMESPACE_ERR but IE9 raises SYNTAX_ERR. Cheers, Kenny
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
Always throwing SyntaxError is probably better. Which reminds me, the specification needs to be updated for new-style exceptions.
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 6/17/12 9:33 AM, Anne van Kesteren wrote: Always throwing SyntaxError is probably better. Also probably incompatible with a depth-first recursive descent parser implementation. Are we sure we want to overconstrain implementations like that? -Boris
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On Jun 17, 2012, at 3:44 PM, Boris Zbarsky bzbar...@mit.edu wrote: Also probably incompatible with a depth-first recursive descent parser implementation. Are we sure we want to overconstrain implementations like that? Incompatible how?
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On Sun, Jun 17, 2012 at 4:43 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/17/12 9:33 AM, Anne van Kesteren wrote: Always throwing SyntaxError is probably better. Also probably incompatible with a depth-first recursive descent parser implementation. Are we sure we want to overconstrain implementations like that? I'm not sure what Anne meant, but I'd think we should just always require SyntaxError, including for namespace errors. Do enough people really use namespaces that they deserve a separate exception? CSS itself treats namespace errors the same as syntax errors in stylesheets (right?), so it doesn't make sense to require Selectors APIs to distinguish them.
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
(12/06/17 21:33), Anne van Kesteren wrote: Always throwing SyntaxError is probably better. I have no opinion here besides that I think this should be well-defined. (12/06/17 21:50), Aryeh Gregor wrote: I'm not sure what Anne meant, but I'd think we should just always require SyntaxError, including for namespace errors. Do enough people really use namespaces that they deserve a separate exception? Probably no. CSS itself treats namespace errors the same as syntax errors in stylesheets (right?), In the Selectors spec, in some sense, yes, but the spec didn't have to touch the JS stuff so I wouldn't rely on its insights into this. so it doesn't make sense to require Selectors APIs to distinguish them. As long as browsers are willing to change this old behavior, agreed. (By the way, another irrelevant editorial feedback: http://dev.w3.org/2006/webapi/selectors-api2/ 6.5 3-1 s/dom_relative_selectors_group/dom_selectors_group/ ) Cheers, Kenny
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 2012-06-17 15:50, Aryeh Gregor wrote: On Sun, Jun 17, 2012 at 4:43 PM, Boris Zbarskybzbar...@mit.edu wrote: On 6/17/12 9:33 AM, Anne van Kesteren wrote: Always throwing SyntaxError is probably better. Also probably incompatible with a depth-first recursive descent parser implementation. Are we sure we want to overconstrain implementations like that? I don't know what this means. Could you clarify? I'm not sure what Anne meant, but I'd think we should just always require SyntaxError, including for namespace errors. Do enough people really use namespaces that they deserve a separate exception? CSS itself treats namespace errors the same as syntax errors in stylesheets (right?), so it doesn't make sense to require Selectors APIs to distinguish them. The distinction made sense when we were considering supporting namespaces, as it would help authors to diagnose mistakes. But looking at sizzle.js [1], it doesn't make a distinction between them at all. It just catches the error, ignores it and moves on. This may be one thing that could be changed without risk of breaking anything, since the lack of any namespace support means its unlikely that there are any scripts performing any special error handling for namespace errors that differs from other syntax errors. Is there any reason we should keep this distinction? [1] https://github.com/jquery/sizzle/blob/master/sizzle.js -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 6/17/12 9:50 AM, Anne van Kesteren wrote: On Jun 17, 2012, at 3:44 PM, Boris Zbarskybzbar...@mit.edu wrote: Also probably incompatible with a depth-first recursive descent parser implementation. Are we sure we want to overconstrain implementations like that? Incompatible how? Consider how this is parsed in a depth-first recursive descent parser: a|b +, 1) The identifier a is scanned. This might be a tag name or a namespace; look at the next token. 2) The symbol '|' is scanned. Great. a was a namespace. Resolve it. And you're done. You have an error and bail out. You never even got to the '+'. -Boris P.S. This is basically what the Gecko parser does, afaik. On the other hand, WebKit's parser is breadth-first, again as far as I know: it first breaks up the selector on ',', then tries to match the various bits against the relevant productions and only after that actually deals with the leaf parse nodes. Hence it actually sees the missing stuff after '+' error before it ever tries to figure out anything about a in there.
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On Mon, Jun 18, 2012 at 4:29 AM, Boris Zbarsky bzbar...@mit.edu wrote: And you're done. You have an error and bail out. Yeah, so I should have been more clear. My suggestion was to never throw a NamespaceError and just always use SyntaxError. That distinction has never made much sense. (Well I guess it might have somewhat when it was still theoretically possible to have a namespace-aware and non-namespace-aware DOM...) -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 6/18/12 1:33 AM, Anne van Kesteren wrote: On Mon, Jun 18, 2012 at 4:29 AM, Boris Zbarskybzbar...@mit.edu wrote: And you're done. You have an error and bail out. Yeah, so I should have been more clear. My suggestion was to never throw a NamespaceError and just always use SyntaxError. Ah, ok. That would certainly be pretty easy. ;) -Boris
Updates to Selectors API
Hi, I have updated the specification for Selectors API Level 1, which is currently in CR. Most of it was editorial in nature, to bring it in line with Selectors API Level 2, except without adding any of the new features like findAll() or or matches(). Importantly, the IDL has now been updated to comply with the most recent WebIDL specificiation. This was basically to split it up into 3 partial interfaces, just like what was previously done in v2. Some of the prose was rewritten, but none of the changes should adversely affect implementation requirements. This was mostly done by back porting the content from v2, but while ensuring that all the normative references still refer to the older, stable specs. (e.g. DOM3Core instead of using DOM4, as is used in the v2 draft.) This now makes v1 a proper subset of v2. In the process, I also made a few minor editorial changes to v2 just to tidy it up. At this stage, we should be able to publish v1 as a revised CR, or possibly move it up to PR. We can also publish v2. as a new WD. Alternatively, we could forgo any further progress with v1 and let v2 supersede it entirely, at which point I could simply rename it back to Selectors API without a version number and move on. (This is my preferred approach). http://dev.w3.org/2006/webapi/selectors-api/ http://dev.w3.org/2006/webapi/selectors-api2/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Updates to Selectors API
* Lachlan Hunt wrote: At this stage, we should be able to publish v1 as a revised CR, or possibly move it up to PR. We can also publish v2. as a new WD. It does not seem that additional implementation experience is required to make sure no major changes are needed, so, Proposed Recommendation. -- 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: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
Yehuda Katz (ph) 718.877.1325 On Fri, Nov 25, 2011 at 7:49 AM, William Edney bed...@technicalpursuit.comwrote: All - I'm going to throw my 2 cents in here and say that, whatever ends up happening with scoping, that the equivalent of the current querySelector()/querySelectorAll() should be named matchesSelector(). I'd be ok with querySelector/querySelectorAll/matchesSelector and find/findAll/matches As I have said, I personally consider qS/qSA to be implementation mistakes and would like to see find and findAll replace querySelector[All] in all cases, so maybe we don't need a matchesSelector then? As a longtime Web developer (and trainer of other Web developers) it is important to me to have consistency in naming above all else. JS libraries can always alias / wrap these names should they so desire. Name shortening has already been occurring... if we had followed 'old W3C DOM-style naming', querySelectorAll() would've been 'documentGetElementsBySelector()'. Providing a balance between short names and descriptive names is important. One of the things that drives me nuts about the (non-standard) 'document.evaluate()' call (exists on FF / Webkit to query using XPath), is that it is not explicit enough... 'evaluate' what? JS? XPath? CSS? While I don't disagree that shorter names could've been chosen all of those years ago, as Austin Powers would say, That train has sailed, baby... Cheers, - BIll On Nov 25, 2011, at 8:04 AM, Sean Hogan wrote: On 25/11/11 6:49 PM, Lachlan Hunt wrote: On 2011-11-25 01:07, Sean Hogan wrote: On 24/11/11 7:46 PM, Lachlan Hunt wrote: On 2011-11-23 23:38, Sean Hogan wrote: - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. If and when there is a need for a matching method that does imply :scope (which I provided a use-case for in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html) then it could be called matches(). Oh, it wasn't clear that you were talking about a case involving explicit reference nodes before. But adding two separate methods that are only subtly different would add more complexity for authors, since the difference will not always be obvious where there is no explicit reference nodes supplied and they may get them confused. In fact, with a method that always prepends :scope, it could result in an unexpected result in some cases: e.g. root.matches(html.foo); root.matchesSelector(html.foo); These aren't obviously different, but when you consider that the first would always prepend :scope under your proposal, the first would unexpectedly return false, since it's equivalent to: root.matchesSelector(:scope html.foo); This would happen whether the root element is the root of the document, or the root of a disconnected tree. We could instead address your use case by implying :scope if a refElement or refNodes is supplied. That way, if the author calls .matches() without any refNodes, they get the expected result with no implied :scope. If they do supply refNodes, and there is no explicit :scope, then imply :scope at the beginning. This approach would be completely backwards compatible with the existing implementations, as nothing changes until refNodes/refElement and :scope are supported. You mentioned this before, but anyway: el.matches(div span) - ok el.matches( div span) - throws, because no :scope implied el.matches(div :scope span) - ok, but can't match anything el.matches( div span, refNode) - ok el.matches(div :scope span, refNode) - ok el.matches(div span, refNode) - what does this do? How do you know that the intention isn't to just ignore the refNode if there is no explicit :scope? I guess if you wanted this last behavior, you could call something like /:scope\b/.test(selector) before-hand and if it is false then not pass the refNode to matches(). I'm not sure if there are other problematic cases. Sean
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
so maybe we don't need a matchesSelector then? We totally need a matchesSelector. It's perfect for event delegation. In Diego Perini's NWMatcher his `match` method is what drives the lib. https://github.com/dperini/nwmatcher/blob/master/src/nwmatcher-base.js#L391 Though he avoids the matchesSelector API at the moment because the cost of testing/avoiding cross-browser bugs kills any perf gains. https://github.com/dperini/nwmatcher/commit/10a48ac54c3673c125c540447bb74c75cd1a9ed4 -JDD On Tue, Nov 29, 2011 at 10:26 PM, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Fri, Nov 25, 2011 at 7:49 AM, William Edney bed...@technicalpursuit.com wrote: All - I'm going to throw my 2 cents in here and say that, whatever ends up happening with scoping, that the equivalent of the current querySelector()/querySelectorAll() should be named matchesSelector(). I'd be ok with querySelector/querySelectorAll/matchesSelector and find/findAll/matches As I have said, I personally consider qS/qSA to be implementation mistakes and would like to see find and findAll replace querySelector[All] in all cases, so maybe we don't need a matchesSelector then? As a longtime Web developer (and trainer of other Web developers) it is important to me to have consistency in naming above all else. JS libraries can always alias / wrap these names should they so desire. Name shortening has already been occurring... if we had followed 'old W3C DOM-style naming', querySelectorAll() would've been 'documentGetElementsBySelector()'. Providing a balance between short names and descriptive names is important. One of the things that drives me nuts about the (non-standard) 'document.evaluate()' call (exists on FF / Webkit to query using XPath), is that it is not explicit enough... 'evaluate' what? JS? XPath? CSS? While I don't disagree that shorter names could've been chosen all of those years ago, as Austin Powers would say, That train has sailed, baby... Cheers, - BIll On Nov 25, 2011, at 8:04 AM, Sean Hogan wrote: On 25/11/11 6:49 PM, Lachlan Hunt wrote: On 2011-11-25 01:07, Sean Hogan wrote: On 24/11/11 7:46 PM, Lachlan Hunt wrote: On 2011-11-23 23:38, Sean Hogan wrote: - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. If and when there is a need for a matching method that does imply :scope (which I provided a use-case for in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html) then it could be called matches(). Oh, it wasn't clear that you were talking about a case involving explicit reference nodes before. But adding two separate methods that are only subtly different would add more complexity for authors, since the difference will not always be obvious where there is no explicit reference nodes supplied and they may get them confused. In fact, with a method that always prepends :scope, it could result in an unexpected result in some cases: e.g. root.matches(html.foo); root.matchesSelector(html.foo); These aren't obviously different, but when you consider that the first would always prepend :scope under your proposal, the first would unexpectedly return false, since it's equivalent to: root.matchesSelector(:scope html.foo); This would happen whether the root element is the root of the document, or the root of a disconnected tree. We could instead address your use case by implying :scope if a refElement or refNodes is supplied. That way, if the author calls .matches() without any refNodes, they get the expected result with no implied :scope. If they do supply refNodes, and there is no explicit :scope, then imply :scope at the beginning. This approach would be completely backwards compatible with the existing implementations, as nothing changes until refNodes/refElement and :scope are supported. You mentioned this before, but anyway: el.matches(div span) - ok el.matches( div span) - throws, because no :scope implied el.matches(div :scope span) - ok, but can't match anything el.matches( div span, refNode) - ok el.matches(div :scope span, refNode) - ok el.matches(div span, refNode) - what does this do? How do you know that the intention isn't to just ignore the refNode if there is no explicit :scope? I guess if you wanted this last behavior, you could call something like /:scope\b/.test(selector) before-hand and if it is false then not pass the refNode to matches(). I'm not sure if there are other
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
Yehuda Katz (ph) 718.877.1325 On Tue, Nov 29, 2011 at 11:06 PM, John-David Dalton john.david.dal...@gmail.com wrote: so maybe we don't need a matchesSelector then? We totally need a matchesSelector. It's perfect for event delegation. In Diego Perini's NWMatcher his `match` method is what drives the lib. https://github.com/dperini/nwmatcher/blob/master/src/nwmatcher-base.js#L391 I totally agree that we need the feature. This discussion was only about what to name it. The matchesSelector name fits better with querySelectorAll, while bare matches fits with the proposed find/findAll (which would be properly scoped). Since I'm in favor of the find[All] APIs, I am also in favor of the matches name :) Though he avoids the matchesSelector API at the moment because the cost of testing/avoiding cross-browser bugs kills any perf gains. https://github.com/dperini/nwmatcher/commit/10a48ac54c3673c125c540447bb74c75cd1a9ed4 -JDD On Tue, Nov 29, 2011 at 10:26 PM, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Fri, Nov 25, 2011 at 7:49 AM, William Edney bed...@technicalpursuit.com wrote: All - I'm going to throw my 2 cents in here and say that, whatever ends up happening with scoping, that the equivalent of the current querySelector()/querySelectorAll() should be named matchesSelector(). I'd be ok with querySelector/querySelectorAll/matchesSelector and find/findAll/matches As I have said, I personally consider qS/qSA to be implementation mistakes and would like to see find and findAll replace querySelector[All] in all cases, so maybe we don't need a matchesSelector then? As a longtime Web developer (and trainer of other Web developers) it is important to me to have consistency in naming above all else. JS libraries can always alias / wrap these names should they so desire. Name shortening has already been occurring... if we had followed 'old W3C DOM-style naming', querySelectorAll() would've been 'documentGetElementsBySelector()'. Providing a balance between short names and descriptive names is important. One of the things that drives me nuts about the (non-standard) 'document.evaluate()' call (exists on FF / Webkit to query using XPath), is that it is not explicit enough... 'evaluate' what? JS? XPath? CSS? While I don't disagree that shorter names could've been chosen all of those years ago, as Austin Powers would say, That train has sailed, baby... Cheers, - BIll On Nov 25, 2011, at 8:04 AM, Sean Hogan wrote: On 25/11/11 6:49 PM, Lachlan Hunt wrote: On 2011-11-25 01:07, Sean Hogan wrote: On 24/11/11 7:46 PM, Lachlan Hunt wrote: On 2011-11-23 23:38, Sean Hogan wrote: - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. If and when there is a need for a matching method that does imply :scope (which I provided a use-case for in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html) then it could be called matches(). Oh, it wasn't clear that you were talking about a case involving explicit reference nodes before. But adding two separate methods that are only subtly different would add more complexity for authors, since the difference will not always be obvious where there is no explicit reference nodes supplied and they may get them confused. In fact, with a method that always prepends :scope, it could result in an unexpected result in some cases: e.g. root.matches(html.foo); root.matchesSelector(html.foo); These aren't obviously different, but when you consider that the first would always prepend :scope under your proposal, the first would unexpectedly return false, since it's equivalent to: root.matchesSelector(:scope html.foo); This would happen whether the root element is the root of the document, or the root of a disconnected tree. We could instead address your use case by implying :scope if a refElement or refNodes is supplied. That way, if the author calls .matches() without any refNodes, they get the expected result with no implied :scope. If they do supply refNodes, and there is no explicit :scope, then imply :scope at the beginning. This approach would be completely backwards compatible with the existing implementations, as nothing changes until refNodes/refElement and :scope are supported. You mentioned this before, but anyway: el.matches(div span) - ok
Re: Remaining Problems with Explicit :scope Switching in find/findAll (was: Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?)
On Thursday, November 24, 2011, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2011-11-24 00:52, Yehuda Katz wrote: On Wed, Nov 23, 2011 at 2:38 PM, Sean Hoganshogu...@westnet.com.au wrote: The alternative option (find / findAll / matches can accept explicit :scope, but will otherwise imply :scope) seems to be where all the ambiguity lies. What exact cases are ambiguous with find/findAll/matches can accept explicit :scope, but will otherwise imply :scope? The problems to be solved with automatically switching between implied and explicit :scope are basically in determining what exactly counts as an explicit :scope. The answers to each of these has is trade off between complexity and functionality, with the simplest option being always implying :scope. * Is explicit :scope allowed at the beginning of each selector? find(:scopediv); find(body.foo :scopediv); * Does :scope inside functional pseudo-classes count? find(:not(:scope)); find(:matches(:scope)); If yes, does the first match the whole document, only descendants, or descendants plus siblings? * If using an explicit :scope, can it match itself? find(:scope) // Return null or the element itself? * Is :scope always implied if it begins with an explicit combinator other than descendant, even if :scope is used elsewhere? find(div :scope); find(+div :scope); find(~div :scope); Here is what I sent to the list on Nov 10th. Though it didn't get archived so maybe it didn't go through properly: 1. Start with an empty list 2. Skip any whitespace at the beginning of the string. 3. If the next character is a , a + or a ~, insert a simple selector[1] containing just the :scope pseudo selector at the beginning of the selector. 4. Parse as a selector[1]. If there's a parse error throw an SyntaxError exception. 5. If during parsing a :scope pseudo class was parsed, and if a :scope pseudo selector was added in step 2, throw a SyntaxError exception. 6. If during parsing no :scope pseudo class was parsed, and if no :scope pseudo selector was added in step 2, add a simple selector containing just the :scope pseudo class to the beginning of the list, and use a descendant selector as combinator to the rest of the selector. 7. Add selector to the end of list created in step 1. 8. If, after skipping any whitespace, the next character is a comma, skip the comma and go to step 2. The resulting selector list is evaluated against the document node, but with :scope matching the node that .find/.findAll was called on. .findAll returns all nodes which match the selector in document order. .find returns the first node in the list of nodes that .findAll returns, or null if the list is empty. The reason I suggested to throw in step 5 was that such a selector would never match anything and so must be a bug. But maybe that isn't the case for /for/. More below. * There's also the general issue, not related to :scope, about how the reference combinator affects the range of potential matches. label.find(/for/ input) Based on the above issues, what happens in this case? foo.find(label /for/ input+:scope~span) Can this expression ever match anything if we prepend :scope? Would simply removing step 5 above make the steps work for this case too? / Jonas
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 2011-11-25 00:19, Sean Hogan wrote: This has been raised before, but I'll restate it here. How should the selector be expanded in elt.findAll(div span, div :scope span)? The implication of :scope has to be done on a per complex selector basis, rather than applied to the entire list. That would be equivalent to: elt.findAll(:scope div span, div :scope span) If this isn't to throw an error then a more complex definition is required which can apply a different rule for implying :scope in different parts of the selector argument. This is sure to be confusing for anyone reading the code. Selectors in selector lists are always independent of each other, so authors who use a selector list would likely assume that one doesn't affect how another in the list matches. It would seem far more confusing for authors to do it using the other alternatives. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
