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
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
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
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
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
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
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/
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
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
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
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
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()
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
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
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]
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
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
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
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
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
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
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
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
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
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
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/
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
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
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
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
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
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
-domimplementation-hasfeature stays the way
it is.
Indeed, please remove http://www.w3.org/TR/selectors-api/#dom-feature-string
--
http://annevankesteren.nl/
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/
.
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
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
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
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.
(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
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,
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
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
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
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
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
/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/
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
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
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
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
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
, 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
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
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
(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
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
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
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
(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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
% 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
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
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
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
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
(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
-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
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
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
Always throwing SyntaxError is probably better. Which reminds me, the
specification needs to be updated for new-style exceptions.
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
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?
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
(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,
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.
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
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
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.
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
* 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.
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
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
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
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
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
1 - 100 of 496 matches
Mail list logo
