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
On 26/11/11 12:00 AM, Lachlan Hunt wrote:
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,
On 25/11/11 6:49 PM, Lachlan Hunt wrote:
On 2011-11-25 01:07, Sean Hogan wrote:
On 24/11/11 7:46 PM, Lachlan Hunt wrote:
On 2011-11-23 23:38, Sean Hogan wrote:
- If you want to use selectors with :scope implied at the start of
each
selector in the selector list (as most js libs currently do)
All -
I'm going to throw my 2 cents in here and say that, whatever ends up happening
with scoping, that the equivalent of the current
querySelector()/querySelectorAll() should be named matchesSelector().
As a longtime Web developer (and trainer of other Web developers) it is
important to me
On 2011-11-23 23:38, Sean Hogan wrote:
Are there any issues with:
- If you want to use selectors with explicit :scope then you use
querySelector / querySelectorAll / matchesSelector.
- If you want to use selectors with :scope implied at the start of each
selector in the selector list (as most
On 2011-11-24 00:52, Yehuda Katz wrote:
On Wed, Nov 23, 2011 at 2:38 PM, Sean Hoganshogu...@westnet.com.au wrote:
The alternative option (find / findAll / matches can accept explicit
:scope, but will otherwise imply :scope) seems to be where all the
ambiguity lies.
What exact cases are
On Thu, Nov 24, 2011 at 12:50 AM, 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 11/23/11 5:38 PM, Sean Hogan wrote:
- If you want to use selectors with :scope implied at the start of each
selector in the selector list (as most js libs currently do) then you
use find / findAll / matches.
I'm not sure that for matches() the :scope thing is all that relevant.
:matches()
Yehuda Katz
(ph) 718.877.1325
On Thu, Nov 24, 2011 at 9:47 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/23/11 5:38 PM, Sean Hogan wrote:
- If you want to use selectors with :scope implied at the start of each
selector in the selector list (as most js libs currently do) then you
use find
On 24/11/11 10:52 AM, Yehuda Katz wrote:
Yehuda Katz
(ph) 718.877.1325
On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan shogu...@westnet.com.au
mailto:shogu...@westnet.com.au wrote:
On 23/11/11 12:17 AM, Boris Zbarsky wrote:
On 11/22/11 6:50 AM, Lachlan Hunt wrote:
On 24/11/11 7:46 PM, Lachlan Hunt wrote:
On 2011-11-23 23:38, Sean Hogan wrote:
Are there any issues with:
- If you want to use selectors with explicit :scope then you use
querySelector / querySelectorAll / matchesSelector.
- If you want to use selectors with :scope implied at the start of
On Thu, Nov 24, 2011 at 3:19 PM, Sean Hogan shogu...@westnet.com.au 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 straight-forward interpretation of implies :scope unless it is
explicit is
On 2011-11-25 01:07, Sean Hogan wrote:
On 24/11/11 7:46 PM, Lachlan Hunt wrote:
On 2011-11-23 23:38, Sean Hogan wrote:
- If you want to use selectors with :scope implied at the start of each
selector in the selector list (as most js libs currently do) then you
use find / findAll / matches.
On Tue, Nov 22, 2011 at 12:19 AM, Yehuda Katz wyc...@gmail.com wrote:
I like .is, the name jQuery uses for this purpose. Any reason not to go with
it?
We might want it for something else. .matches clearly sounds like
it's selector-related, and I have more trouble thinking of another
meaning
On Tue, Nov 22, 2011 at 1:04 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Again, some decent data on what pages actually do in on* handlers would be
really good. I have no idea how to get it. :(
Can't browsers add instrumentation for this? You have users who have
opted in to sending anonymized
On 11/23/11 10:03 AM, Aryeh Gregor wrote:
Can't browsers add instrumentation for this? You have users who have
opted in to sending anonymized data. So for each user, on a small
percentage of pages, intercept all bare-name property accesses in on*.
With enough work, this is possible. It'd
Works for me. I can live with .matches, but .matchesSelector is too verbose.
Yehuda Katz
(ph) 718.877.1325
On Wed, Nov 23, 2011 at 6:39 AM, Aryeh Gregor a...@aryeh.name wrote:
On Tue, Nov 22, 2011 at 12:19 AM, Yehuda Katz wyc...@gmail.com wrote:
I like .is, the name jQuery uses for this
On 23/11/11 12:17 AM, Boris Zbarsky wrote:
On 11/22/11 6:50 AM, Lachlan Hunt wrote:
Last time we had this discussion, you had a desire to keep the name
prefixed until the refNodes and :scope stuff was implemented [1]. What's
the status on that now?
The status is that I've given up on the
Yehuda Katz
(ph) 718.877.1325
On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan shogu...@westnet.com.au wrote:
On 23/11/11 12:17 AM, Boris Zbarsky wrote:
On 11/22/11 6:50 AM, Lachlan Hunt wrote:
Last time we had this discussion, you had a desire to keep the name
prefixed until the refNodes and
Yehuda Katz
(ph) 718.877.1325
On Tue, Nov 22, 2011 at 12:14 AM, Roland Steiner rolandstei...@chromium.org
wrote:
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/21/11 11:31 AM, Tab Atkins Jr. wrote:
1) Make sense.
2) Not break existing content.
3) Be short.
.matches
On 22/11/11 7:14 PM, Roland Steiner wrote:
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com
mailto:wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325 tel:718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu
mailto:bzbar...@mit.edu wrote:
On 11/22/11 1:56 AM, Sean Hogan wrote:
On 22/11/11 7:14 PM, Roland Steiner wrote:
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com
mailto:wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325 tel:718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky
Complexity and discussions about combinators seem to have prevented it from
getting into any draft despite lots of +1s. It is really different from
the rest of the selectors that exist today which are optimized like crazy
so it requires more in term of implementation than most to keep performance
On 11/22/11 6:50 AM, Lachlan Hunt wrote:
Last time we had this discussion, you had a desire to keep the name
prefixed until the refNodes and :scope stuff was implemented [1]. What's
the status on that now?
The status is that I've given up on the :scope discussion reaching a
conclusion in
On Tue, Nov 22, 2011 at 12:18 AM, Yehuda Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On Tue, Nov 22, 2011 at 12:14 AM, Roland Steiner
rolandstei...@chromium.org wrote:
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On
+ian since this wording is actually in the HTML spec.
I'm not sure how exactly this should be specced. DOM4 could specify the two
interfaces and HTML could use those definitions?
On Mon, Nov 21, 2011 at 7:05 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/21/11 9:58 PM, Ojan Vafai wrote:
I
On 11/22/11 12:57 PM, Ojan Vafai wrote:
The fewer properties that are exposed this way, the smaller the quirk
is.
I think the problem is that from web developers point of view the quirky
behavior is _not_ exposing properties. Certainly in the short term...
In the long term, since we have
On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/22/11 12:57 PM, Ojan Vafai wrote:
The fewer properties that are exposed this way, the smaller the quirk
is.
I think the problem is that from web developers point of view the quirky
behavior is _not_ exposing
On Tue, Nov 22, 2011 at 10:24 AM, Ojan Vafai o...@chromium.org wrote:
On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/22/11 12:57 PM, Ojan Vafai wrote:
The fewer properties that are exposed this way, the smaller the quirk
is.
I think the problem is that from
On Tue, Nov 22, 2011 at 4:12 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 22, 2011 at 10:24 AM, Ojan Vafai o...@chromium.org wrote:
On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu
wrote:
On 11/22/11 12:57 PM, Ojan Vafai wrote:
I was hoping that we could have a
What's the current state of matchesSelector? Are we confident enough in
the name and such to unprefix it?
-Boris
On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarsky bzbar...@mit.edu wrote:
What's the current state of matchesSelector? Are we confident enough in the
name and such to unprefix it?
I think that matchesSelector suffers from the same verbosity that qSA
does, and would benefit from the same
On 11/21/11 10:56 AM, Tab Atkins Jr. wrote:
On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarskybzbar...@mit.edu wrote:
What's the current state of matchesSelector? Are we confident enough in the
name and such to unprefix it?
I think that matchesSelector suffers from the same verbosity that qSA
On Mon, Nov 21, 2011 at 8:23 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/21/11 10:56 AM, Tab Atkins Jr. wrote:
On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarskybzbar...@mit.edu wrote:
What's the current state of matchesSelector? Are we confident enough in
the
name and such to unprefix
On 11/21/11 11:31 AM, Tab Atkins Jr. wrote:
1) Make sense.
2) Not break existing content.
3) Be short.
.matches
.is
The sticking point here is obviously item #2. Data needed on use of
matches and is as barewords in on* attributes, specifically.
-Boris
On Mon, Nov 21, 2011 at 11:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
The sticking point here is obviously item #2. Data needed on use of
matches and is as barewords in on* attributes, specifically.
I don't follow. matchesSelector is on Element, not Node, right? Why
is it relevant to on*
On Mon, Nov 21, 2011 at 5:31 PM, Aryeh Gregor a...@aryeh.name wrote:
On Mon, Nov 21, 2011 at 11:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
The sticking point here is obviously item #2. Data needed on use of
matches and is as barewords in on* attributes, specifically.
I don't follow.
On Mon, Nov 21, 2011 at 8:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You're not misunderstanding, but you're wrong. ^_^ The element
itself is put in the lookup chain before document. See this testcase:
!DOCTYPE html
button onclick=alert(namespaceURI)foo/button
(namespaceURI was
On 22/11/11 3:23 AM, Boris Zbarsky wrote:
On 11/21/11 10:56 AM, Tab Atkins Jr. wrote:
On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarskybzbar...@mit.edu wrote:
What's the current state of matchesSelector? Are we confident
enough in the
name and such to unprefix it?
I think that
I think this is the only sane solution to this problem. Lets split up the
Element interface. I'm not attached to these names, but something
like ElementExposed and Element. Element inherits (mixins?) ElementExposed
and only the methods on ElementExposed are exposed to the on* lookup chain.
On 11/21/11 8:31 PM, Aryeh Gregor wrote:
The lookup chain is first document
then window, with no elements anywhere, right?
The lookup order is the element the on* attribute is on, then the
element's form if it's a form control (more or less; details are in the
spec), then the document, then
On 11/21/11 9:58 PM, Ojan Vafai wrote:
I think this is the only sane solution to this problem. Lets split up
the Element interface. I'm not attached to these names, but something
like ElementExposed and Element. Element inherits (mixins?)
ElementExposed and only the methods on ElementExposed are
Yehuda Katz
(ph) 718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/21/11 11:31 AM, Tab Atkins Jr. wrote:
1) Make sense.
2) Not break existing content.
3) Be short.
.matches
.is
I like .is, the name jQuery uses for this purpose. Any reason
48 matches
Mail list logo
