[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-COR

[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 o

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 C

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

Re: ITS 2.0, Selectors 4 and Selectors API 2

On Tue, Jul 2, 2013 at 12:57 AM, Daniel Glazman 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

Re: ITS 2.0, Selectors 4 and Selectors API 2

't think it's an abuse at all. But I see your point better now. I still think we need to extend Selectors to attribute selection and Selectors API to namespace resolution.

Re: ITS 2.0, Selectors 4 and Selectors API 2

On Mon, Jul 1, 2013 at 11:53 PM, Daniel Glazman 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 > is in the spec back in *1997* in

Re: ITS 2.0, Selectors 4 and Selectors API 2

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 m

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 s

Re: ITS 2.0, Selectors 4 and Selectors API 2

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 retur

Re: ITS 2.0, Selectors 4 and Selectors API 2

On 02/07/13 02:53, Daniel Glazman wrote: http://www.w3.org/2005/11/its"; version="2.0" queryLanguage="css"> http://www.w3.org/1999/xhtml"/> Sorry, the above is obviously wrong, please read http://www.w3.org/2005/11/its"; version=

ITS 2.0, Selectors 4 and Selectors API 2

ice 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 cann

Re: [selectors-api] QSA and findAll definitions

On Mon, Jun 10, 2013 at 4:47 PM, Tab Atkins Jr. wrote: > > > 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 >

Re: [selectors-api] QSA and findAll definitions

On Mon, Jun 10, 2013 at 1:15 PM, Timmy Willison 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() wo

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 wo

Re: [selectors-api] QSA and findAll definitions

On Sun, Jun 9, 2013 at 6:18 PM, Boris Zbarsky 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

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 s

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]

[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 element

Re: [selectors-api] References to Selectors 4

.find() searches the whole document. It should instead return nothing. Example: document.find('img', [list-of-links]) /* find all images inside links */ Suppose the dynamically-generated [list-of-links] happens to be empty. It returns all the images in the document, a very unexpe

[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.htm

[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

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 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 chan

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://d

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

On 30 November 2012 02: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 > htt

[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-contex

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

On Fri, 16 Nov 2012 15:48:28 +0400, Arthur Barstow 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 Cf

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/Selec

[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

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/

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

[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

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

Re: [selectors-api] Updated Testsuite

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] Updated Testsuite

.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 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 :visite

[selectors-api] Updated Testsuite

: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] RfC: LCWD of Selectors API Level 1; deadline July 19

nts, 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

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

[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

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 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

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

(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. >

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 defin

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

On Mon, Aug 6, 2012 at 4:25 AM, Lachlan Hunt 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 wo

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

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 "

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 u

[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 anyt

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: Date: Thu, 28 Jun 2012 10:58:36 -0400 From: ext Arthur Barstow To: public-webapps This is a Request for Comments

[selectors-api] New Implementation Report for Updated Testsuite

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 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

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

Arthur Barstow 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

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 " [se

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

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

Re: Selectors API Implementation Report

/2006/webapi/selectors-api-testsuite/001-report.html If it would be useful, you can get a Firefox build with the NAMESPACE_ERR change applied at https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bzbar...@mozilla.com-ea5efd894886/ (at least for the next week or three; that stuff gets

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 > 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 ag

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

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

On Thu, 21 Jun 2012 15:56:45 +0200, 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 objec

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 spend

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 abou

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" : 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 th

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

On Wed, 20 Jun 2012 16:26:14 +0200, 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 a

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

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/webap

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

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 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". Thi

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

20.06.2012, 18:14, "Lachlan Hunt" : > 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 t

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 significa

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

20.06.2012, 18:26, "Lachlan Hunt" : > 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

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 (import

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

On 2012-06-18 16:45, Simon Pieters wrote: 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. The find m

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

On Wed, 20 Jun 2012 06:19:22 +0200, Elliott Sprehn wrote: On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr. wrote: ... 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, a

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

On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr. wrote: > ... > 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

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

20.06.2012, 00:38, "Tab Atkins Jr." : > On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters wrote: > >>  On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu >>   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

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

On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters wrote: > On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu > 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

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 so

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

On Mon, 18 Jun 2012 15:57:02 +0200, 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

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

On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu 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 br

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/

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

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-inco

[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

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

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 publi

Re: Updates to Selectors API

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&

Re: Updates to Selectors API

y 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

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

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

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/

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

On Sun, 17 Jun 2012 13:10:11 +0200, Kang-Hao (Kenny) Lu 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

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 Zbarsky 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

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

On Mon, Jun 18, 2012 at 4:29 AM, Boris Zbarsky 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 h

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 Zbarsky 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 pars

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 Zbarsky 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 w

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, i

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

On Jun 17, 2012, at 3:44 PM, Boris Zbarsky 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 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 implementa

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

Always throwing SyntaxError is probably better. Which reminds me, the specification needs to be updated for new-style exceptions.

[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

  1   2   3   4   5   6   7   >