[selectors-api] typo in specification

2016-06-18 Thread Kirill Topolyan
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-COR

[selectors-api] How to mark TR version as obsolete/superseded? [Was: Re: Obsolete Document]

2015-04-28 Thread Arthur Barstow
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

CfC: publish Selectors API Level 2 as WG Note; deadline October 11

2013-10-04 Thread Arthur Barstow
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

Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-03 Thread Jirka Kosek
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

Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-02 Thread Daniel Glazman
On 02/07/13 04:46, Tab Atkins Jr. wrote: That's already the case - the subject indicator has to precede the compound selector. Tab, I know, *I* designed the subject indicator *exactly* the way it is in the spec back in *1997* in a language called STTS and an application implementing it... I

Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-02 Thread Tab Atkins Jr.
On Mon, Jul 1, 2013 at 11:53 PM, Daniel Glazman daniel.glaz...@disruptive-innovations.com wrote: On 02/07/13 04:46, Tab Atkins Jr. wrote: That's already the case - the subject indicator has to precede the compound selector. Tab, I know, *I* designed the subject indicator *exactly* the way it

Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-02 Thread Daniel Glazman
your point better now. I still think we need to extend Selectors to attribute selection and Selectors API to namespace resolution. /Daniel

Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-02 Thread Tab Atkins Jr.
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

ITS 2.0, Selectors 4 and Selectors API 2

2013-07-01 Thread Daniel Glazman
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

Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-01 Thread Daniel Glazman
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/

Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-01 Thread Tab Atkins Jr.
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

Re: ITS 2.0, Selectors 4 and Selectors API 2

2013-07-01 Thread Liam R E Quin
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

Re: [selectors-api] QSA and findAll definitions

2013-06-10 Thread Tab Atkins Jr.
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

Re: [selectors-api] QSA and findAll definitions

2013-06-10 Thread Timmy Willison
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

Re: [selectors-api] QSA and findAll definitions

2013-06-10 Thread Tab Atkins Jr.
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()

Re: [selectors-api] QSA and findAll definitions

2013-06-10 Thread Timmy Willison
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-api] QSA and findAll definitions

2013-06-09 Thread Timmy
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

Re: [selectors-api] QSA and findAll definitions

2013-06-09 Thread Timmy Willison
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]

Re: [selectors-api] QSA and findAll definitions

2013-06-09 Thread Boris Zbarsky
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

[selectors-api2] Seeking implementation data re Selectors API Level 2

2013-04-30 Thread Arthur Barstow
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

[selectors-api] References to Selectors 4

2013-04-03 Thread fantasai
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

Selectors API Level 1 is a W3C Recommendation

2013-02-21 Thread Arthur Barstow
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)

2012-12-03 Thread Lachlan Hunt
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

Re: [selectors-api] Matching of :scope in document.querySelector(All)

2012-12-03 Thread Boris Zbarsky
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

Re: [selectors-api] Matching of :scope in document.querySelector(All)

2012-12-02 Thread Dean Edwards
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

[selectors-api] Matching of :scope in document.querySelector(All)

2012-11-29 Thread Boris Zbarsky
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

Re: CfC: Selectors API Level 1 Test Suite; deadline November 23

2012-11-27 Thread Charles McCathie Nevile
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

CfC: Selectors API Level 1 Test Suite; deadline November 23

2012-11-16 Thread Arthur Barstow
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

Re: [selectors-api] Reference to obsolete ECMAScript Language spec version

2012-11-15 Thread Lachlan Hunt
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

2012-11-15 Thread Lachlan Hunt
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

Re: CFC Selectors API L1 to CR/PR

2012-11-11 Thread Charles McCathie Nevile
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

[selectors-api] Reference to obsolete ECMAScript Language spec version

2012-10-29 Thread Norbert Lindenberg
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

Re: CFC Selectors API L1 to CR/PR

2012-10-26 Thread Charles McCathie Nevile
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

[selectors-api] Updated Testsuite

2012-10-22 Thread Lachlan Hunt
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

Re: [selectors-api] Updated Testsuite

2012-10-22 Thread Boris Zbarsky
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

Re: [selectors-api] Updated Testsuite

2012-10-22 Thread Anne van Kesteren
-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

2012-10-22 Thread Lachlan Hunt
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

2012-10-08 Thread Lachlan Hunt
. 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

Re: [selectors-api] Kudos on find/findAll, feedback on spec readability

2012-10-04 Thread Lachlan Hunt
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

[selectors-api] Kudos on find/findAll, feedback on spec readability

2012-09-17 Thread David Greenspan
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

Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-08-07 Thread Tab Atkins Jr.
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.

Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-08-06 Thread Kang-Hao (Kenny) Lu
(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

Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-08-06 Thread Lachlan Hunt
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,

Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-08-06 Thread Tab Atkins Jr.
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

RE: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-08-06 Thread Travis Leithead
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

Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-07-31 Thread Arthur Barstow
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

[selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-07-19 Thread Kang-Hao (Kenny) Lu
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

Reminder: RfC: LCWD of Selectors API Level 1; deadline July 19

2012-07-12 Thread Arthur Barstow
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

[selectors-api] New Implementation Report for Updated Testsuite

2012-07-03 Thread Lachlan Hunt
/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

2012-06-30 Thread Lachlan Hunt
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

RfC: LCWD of Selectors API Level 1; deadline July 19

2012-06-28 Thread Arthur Barstow
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

Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-06-28 Thread Stewart Brodie
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

Re: CfC: publish a LCWD of Selectors API Level 1; deadline June 25

2012-06-26 Thread Lachlan Hunt
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

Re: CfC: publish WD of Selectors API Level 2; deadline June 25

2012-06-26 Thread Lachlan Hunt
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

Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-21 Thread Lachlan Hunt
, 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

Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-21 Thread Charles McCathieNevile
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

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-21 Thread Lachlan Hunt
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

Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-21 Thread Kang-Hao (Kenny) Lu
(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

Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-21 Thread Lachlan Hunt
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

Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-21 Thread Charles McCathieNevile
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

Selectors API Implementation Report

2012-06-21 Thread Lachlan Hunt
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

Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-21 Thread Kang-Hao (Kenny) Lu
(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.

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Charles McCathieNevile
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

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Lachlan Hunt
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

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Marat Tanalin | tanalin . com
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

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Dave Methvin
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

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Marat Tanalin | tanalin . com
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

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Boris Zbarsky
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

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-20 Thread Boris Zbarsky
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

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-19 Thread Simon Pieters
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

Re: CfC: publish a LCWD of Selectors API Level 1; deadline June 25

2012-06-19 Thread Charles McCathieNevile
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

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-19 Thread Brian Kardell
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

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-19 Thread Tab Atkins Jr.
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

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-19 Thread Marat Tanalin | tanalin . com
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

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-19 Thread Elliott Sprehn
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

Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-18 Thread Simon Pieters
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

Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-18 Thread Lachlan Hunt
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

Re: Updates to Selectors API

2012-06-18 Thread Arthur Barstow
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

Re: Updates to Selectors API

2012-06-18 Thread Lachlan Hunt
% 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

Re: Updates to Selectors API

2012-06-18 Thread Arthur Barstow
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

CfC: publish WD of Selectors API Level 2; deadline June 25

2012-06-18 Thread Arthur Barstow
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

CfC: publish a LCWD of Selectors API Level 1; deadline June 25

2012-06-18 Thread Arthur Barstow
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

[selectors-api] Consider backporting find() behavior to querySelector()

2012-06-18 Thread Simon Pieters
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

Re: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-18 Thread Kang-Hao (Kenny) Lu
(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

RE: [selectors-api] Consider backporting find() behavior to querySelector()

2012-06-18 Thread Travis Leithead
-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

RE: publish WD of Selectors API Level 2; deadline June 25

2012-06-18 Thread Travis Leithead
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

[selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Kang-Hao (Kenny) Lu
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

Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Anne van Kesteren
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

2012-06-17 Thread Boris Zbarsky
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

2012-06-17 Thread Anne van Kesteren
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

2012-06-17 Thread Aryeh Gregor
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

Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Kang-Hao (Kenny) Lu
(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,

Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Lachlan Hunt
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.

Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Boris Zbarsky
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

Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Anne van Kesteren
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

Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

2012-06-17 Thread Boris Zbarsky
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.

Updates to Selectors API

2012-06-14 Thread Lachlan Hunt
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

Re: Updates to Selectors API

2012-06-14 Thread Bjoern Hoehrmann
* 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.

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

2011-11-29 Thread Yehuda Katz
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

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

2011-11-29 Thread John-David Dalton
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

  1   2   3   4   5   6   >