Gregory Reimer (the author of reglib) points out that
Element.matchesSelector would be useful for event delegation.
See http://blogs.sun.com/greimer/entry/opera_10_will_suport_selector
It would also neatly tie in with NodeFilter in DOM-Traversal,
facilitating something like a live
There are a few active JS implementation projects:
xbl.googlecode.com, see http://code.google.com/p/xbl/wiki/Features
dojo.E has some support, see:
http://blog.nexaweb.com/post/xbl-support-for-all-browsers-via-dojoe/
XBLUI, see: http://meekostuff.net/projects/XBLUI/status.html
XBLUI (my
I don't think the presented XBL use case is valid:
An XBL binding allows full access to the document it is bound to and
therefore cross-origin XBL usage is prohibited. The resource sharing
policy enables cross-origin XBL bindings. If the user is authenticated
with the server that hosts the
Anne van Kesteren wrote:
On Tue, 10 Feb 2009 13:00:35 +0100, Sean Hogan
shogu...@westnet.com.au wrote:
I don't think the presented XBL use case is valid:
An XBL binding allows full access to the document it is bound to and
therefore cross-origin XBL usage is prohibited. The resource sharing
Charles McCathieNevile wrote:
On Wed, 25 Feb 2009 22:59:06 +0100, Sean Hogan
shogu...@westnet.com.au wrote:
Garrett Smith wrote:
It might be worth discussing the load event;
http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-load
Seems that it is specified to fire on Document
Ian Hickson wrote:
On Tue, 28 Apr 2009, John J. Barton wrote:
I could not figure out from the WebIDL what happens in this case:
sessionStore[2] = howdy; // no other keys in sessionStore
I guess this does not work like Javascript arrays or objects, rather I
expect it fails?
It
Boris Zbarsky wrote:
Sean Hogan wrote:
sessionStore[2] = howdy;
print(sessionStore[2]); // prints null?
Where, exactly? That gives howdy in Gecko, at least. At least with
s/sessionStore/window.sessionStorage/.
-Boris
I was following the discussion, and the point is that array-like
Ian Hickson wrote:
There are lots of objects that are not arrays (or should not be rendered
as arrays) and yet have length. Collections, TimeRanges, select
elements, Window objects, History, CanvasPixelArrays, etc.
I'm not sure about all those objects, but my (incomplete) testing of
Ian Hickson wrote:
On Thu, 30 Apr 2009, Sean Hogan wrote:
I'm not sure about all those objects, but my (incomplete) testing of
HTML*Collections indicates that when accessed using array notation:
object[index]; where index object.length
they behave as a readonly array. Which has
Jonas Sicking wrote:
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
This has been discussed extensively in the past. Basically, the idea is
that the selector would be evaluated in the scope
I think a couple of those features are pretty low priority:
- I don't see the point of collective queries on NodeLists.
Are there any references for the proposal?
Otherwise I can't think of any useful queries that can't already be
achieved with a single querySelectorAll().
- Filtering
John Resig wrote:
Libraries already parse selector queries anyway. And some of them
add non-standard selectors and presumeably will continue to do so.
I don't think it is an issue.
However the parsing only happens after the selector has been passed to
the native querySelectorAll
Jonas Sicking wrote:
On Wed, Sep 23, 2009 at 6:00 PM, Sean Hogan shogu...@westnet.com.au wrote:
Jonas Sicking wrote:
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au
wrote:
*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
This has been
Garrett Smith wrote:
On Thu, Sep 24, 2009 at 12:02 AM, Mike Wilson mike...@hotmail.com wrote:
Yes, the base for event delegation is certainly something
like that. I just wanted to make clear that the main reason
for adding this functionality (IMO) is event delegation.
I'll let event
Lachlan Hunt wrote:
Lachlan Hunt wrote:
Sean Hogan wrote:
I think a couple of those features are pretty low priority:
- I don't see the point of collective queries on NodeLists.
Are there any references for the proposal?
Otherwise I can't think of any useful queries that can't already
Boris Zbarsky wrote:
On 9/24/09 6:29 AM, Sean Hogan wrote:
I would be surprised if an implementation didn't create an internal
lookup table keyed off the selector text.
Gecko doesn't. Webkit doesn't.
I just checked really quickly, and on my machine (a year-plus old
laptop) parsing the .foo
Lachlan Hunt wrote:
Mike Wilson wrote:
My first priority would be Matches Selector, and see to that
it fulfills the needs for event delegation.
Is there any special functionality that would be needed to achieve
this? If I understand correctly, event delegation just needs to be
able to
Boris Zbarsky wrote:
On 9/24/09 6:45 PM, Sean Hogan wrote:
That is surprising. Does the CSS engine do the same? If the CSS engine
doesn't store the parsed selector then it probably doesn't matter for JS
calls either.
In Gecko the CSS engine stores the parsed selector. In addition, it
stores
Hi Lachy,
Here's a proposal.
querySelector*(selector, context) // allows selectors with :scope
pseudo-class
queryScopedSelector*(selector, context) // allows selectors with implied
:scope
matchesSelector(selector, context) // allows selectors with :scope
pseudo-class
To check if the :scope
Sean Hogan wrote:
Hi Lachy,
Here's a proposal.
querySelector*(selector, context) // allows selectors with :scope
pseudo-class
queryScopedSelector*(selector, context) // allows selectors with
implied :scope
matchesSelector(selector, context) // allows selectors with :scope
pseudo-class
Lachlan Hunt wrote:
Sean Hogan wrote:
Here's a proposal.
querySelector*(selector, context) // allows selectors with :scope
pseudo-class
queryScopedSelector*(selector, context) // allows selectors with implied
:scope
matchesSelector(selector, context) // allows selectors with :scope
pseudo
Lachlan Hunt wrote:
John Resig wrote:
With that in mind, option #3 looks the best to me. It's lame that the
API
will be longer but we'll be able to use basic object detection to see
if it
exists. Unfortunately the proper scoping wasn't done the first time the
Selectors API was implemented so
Lachlan Hunt wrote:
Maciej Stachowiak wrote:
The proposed exit criteria are in a separate thread, but essentially
are:
For a set of tests based on HTML, CSS 2.1 selectors and this spec,
there are two implementations that pass every test interoperably, and
do not fail any additional tests
On 8/01/10 1:19 AM, Lachlan Hunt wrote:
Hi,
Now that Selectors API Level 1 is published and basically all but
finalised (just waiting for some implementations to be officially
released before taking it to REC), can we publish Selectors API Level
2 as an FPWD?
It would be useful to have it
On 11/01/10 8:29 AM, Lachlan Hunt wrote:
Sean Hogan wrote:
On 8/01/10 1:19 AM, Lachlan Hunt wrote:
can we publish Selectors API Level 2 as an FPWD?
http://dev.w3.org/2006/webapi/selectors-api2/
I can't see the value of queryScopedSelector*() methods. The original
rationale was that JS
On 11/01/10 4:19 PM, Boris Zbarsky wrote:
On 1/10/10 11:58 PM, Sean Hogan wrote:
Even if jQuery deprecates non-standard selectors, the current spec for
queryScopedSelector*() doesn't support the jQuery implicitly scoped
selector *.
As I understand it, jquery selectors on elements are always
On 11/01/10 5:24 PM, Sean Hogan wrote:
On 11/01/10 4:19 PM, Boris Zbarsky wrote:
On 1/10/10 11:58 PM, Sean Hogan wrote:
Even if jQuery deprecates non-standard selectors, the current spec for
queryScopedSelector*() doesn't support the jQuery implicitly scoped
selector *.
As I understand
On 11/01/10 8:55 PM, Lachlan Hunt wrote:
In the following forms :scope is misleading:
element.queryScopedSelector(:scope + *)
element.queryScopedSelector(:scope ~ *)
What's misleading about that? :scope would match the context node
(what the element variable points to), and would return
On 11/01/10 6:40 PM, Boris Zbarsky wrote:
On 1/11/10 1:24 AM, Sean Hogan wrote:
That's correct. jQuery's $(element).find(div) is the equivalent of
SelectorsAPI2's element.querySelectorAll(:scope div) or
So in fact jquery can simply implement Element.find in terms of
querySelectorAll by just
On 12/01/10 5:30 AM, Lachlan Hunt wrote:
Sean Hogan wrote:
In summary, the proposed :scope pseudo-class only acts as a scope for
the query in special cases, not in the general case.
Yes, I'm aware of that. That was basically my reasoning for
attempting to change it to :reference
Perhaps HTML Components (HTC) would be a more accurate name now.
On 23/09/10 12:53 PM, Adam Barth wrote:
Perhaps the new effort should be called XBL3?
Adam
On Wed, Sep 22, 2010 at 9:30 AM, Leigh L. Klotz, Jr.
leigh.kl...@xerox.com wrote:
On 3/07/11 5:36 AM, Ryosuke Niwa wrote:
On Sat, Jul 2, 2011 at 10:46 AM, John J. Barton
johnjbar...@johnjbarton.com wrote:
2) element transformation. The replacement fires after a mutation.
Library or tools that want to transform the application dynamically want
to get notification before the
On 8/07/11 8:28 AM, Jonas Sicking wrote:
On Thu, Jul 7, 2011 at 3:21 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
Jonas Sicking wrote:
We are definitely
short on use cases for mutation events in general which is a problem.
3. Client side dynamic translation. Intercept mutations
On 8/07/11 10:21 PM, Sean Hogan wrote:
On 8/07/11 8:28 AM, Jonas Sicking wrote:
On Thu, Jul 7, 2011 at 3:21 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
Jonas Sicking wrote:
We are definitely
short on use cases for mutation events in general which is a problem.
3. Client side
On 9/07/11 1:12 AM, Ryosuke Niwa wrote:
On Fri, Jul 8, 2011 at 5:21 AM, Sean Hogan shogu...@westnet.com.au
mailto:shogu...@westnet.com.au wrote:
- MathJax (http://mathjax.org) is a JS lib that facilitates
putting math onto the web by converting LaTeX or MathML markup in
a page
On 21/07/11 6:18 AM, David Flanagan wrote:
On 7/20/11 12:11 PM, Ryosuke Niwa wrote:
On Wed, Jul 20, 2011 at 11:56 AM, Aryeh Gregor
simetrical+...@gmail.com mailto:simetrical%2b...@gmail.com wrote:
On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan
dflana...@mozilla.com
On 25/07/11 2:18 AM, Aryeh Gregor wrote:
When discussing mutation events use-cases, mostly so far people have
been talking about editors. However, I think mutation event
replacements would have a much more general appeal if they were easily
usable in certain cases with little performance
On 3/09/11 4:47 AM, Dimitri Glazkov wrote:
On Fri, Sep 2, 2011 at 2:30 AM, Anne van Kesterenann...@opera.com wrote:
Examples of elements that should not be replaced but could be changed by a
binding: Having a sortable binding fortable; Exposing cite= on
blockquote; Turning aselect listing
On 7/09/11 7:20 AM, Alex Russell wrote:
On Sat, Sep 3, 2011 at 8:20 PM, Ian Hicksoni...@hixie.ch wrote:
On Sat, 3 Sep 2011, Dominic Cooney wrote:
I think the XBL approach is far superior here -- have authors use
existing elements, and use XBL to augment them. For example, if you
want the user
On 10/09/11 3:21 AM, Jonas Sicking wrote:
It's a completely useless function. It just implements the equality
operator. I believe most languages have a equality operator already.
Except Brainfuck [1]. But the DOM isn't implementable in Brainfuck
anyway as it doesn't have objects, so I'm ok with
On 10/09/11 11:00 AM, Jonas Sicking wrote:
On Fri, Sep 9, 2011 at 2:27 PM, Sean Hoganshogu...@westnet.com.au wrote:
On 10/09/11 3:21 AM, Jonas Sicking wrote:
It's a completely useless function. It just implements the equality
operator. I believe most languages have a equality operator
On 24/09/11 7:16 AM, Adam Klein wrote:
Chromium (myself, Rafael Weinstein, Erik Arvidsson, Ryosuke Niwa) and
Mozilla (Olli Pettay, Jonas Sicking) have worked together on a
proposal for a replacement for Mutation Events.
This proposal represents our best attempt to date at making a set of
On 12/10/11 3:26 AM, Tab Atkins Jr. wrote:
On Mon, Oct 10, 2011 at 7:51 PM, Sean Hoganshogu...@westnet.com.au wrote:
On 24/09/11 7:16 AM, Adam Klein wrote:
- Is free of the faults of the existing Mutation Events mechanism
(enumerated in detail here:
On 13/10/11 12:34 AM, Olli Pettay wrote:
On 10/12/2011 02:00 PM, Sean Hogan wrote:
On 12/10/11 3:26 AM, Tab Atkins Jr. wrote:
On Mon, Oct 10, 2011 at 7:51 PM, Sean Hoganshogu...@westnet.com.au
wrote:
On 24/09/11 7:16 AM, Adam Klein wrote:
- Is free of the faults of the existing Mutation
On 13/10/11 4:50 AM, Rafael Weinstein wrote:
Hi Sean,
I find it hard to reason about cases in the abstract. None of the
examples you list seem concerning to me (i.e. I believe they can be
properly handled), but perhaps it's a failure of my imagination.
I didn't say they can't be properly
On 13/10/11 2:33 PM, Ryosuke Niwa wrote:
On Wed, Oct 12, 2011 at 8:14 PM, Sean Hogan shogu...@westnet.com.au
mailto:shogu...@westnet.com.au wrote:
Maybe you can provide concrete examples (i.e. with code snippets,
actual instances of use cases, etc...)
Actually
On 13/10/11 7:58 PM, Ryosuke Niwa wrote:
On Thu, Oct 13, 2011 at 1:32 AM, Sean Hogan shogu...@westnet.com.au
mailto:shogu...@westnet.com.au wrote:
Why do you assume that all other mutation observers should ignore
such changes? If there's a library that's automatically syncing
On 19/10/11 7:20 AM, Yehuda Katz wrote:
I agree entirely.
I have asked a number of practitioner friends about this scenario:
div id=parent
p id=childspan id=inlineContent/span/p
/div
document.getElementById(child).querySelectorAll(div span); //
returns #inline
In 100% of cases, people
On 19/10/11 10:58 AM, Tab Atkins Jr. wrote:
On Tue, Oct 18, 2011 at 4:46 PM, Sean Hoganshogu...@westnet.com.au wrote:
On 19/10/11 7:20 AM, Yehuda Katz wrote:
I agree entirely.
I have asked a number of practitioner friends about this scenario:
div id=parent
p id=childspan
On 19/10/11 2:39 PM, Ojan Vafai wrote:
Overall, I wholeheartedly support the proposal.
I don't really see the benefit of allowing starting with a combinator.
I think it's a rare case that you actually care about the scope
element and in those cases, using :scope is fine. Instead of
On 20/10/11 1:07 PM, Jonas Sicking wrote:
On Tue, Oct 18, 2011 at 9:42 AM, Alex Russellslightly...@google.com wrote:
Lachlan and I have been having an...um...*spirited* twitter discussion
regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
and :scope. He asked me to continue
On 20/10/11 5:41 PM, Jonas Sicking wrote:
On Wed, Oct 19, 2011 at 11:14 PM, Sean Hoganshogu...@westnet.com.au wrote:
I do however like the idea that if :scope appears in the selector,
then this removes the prepending of :scope to that selector group.
Is there a reason not to do that?
1.
On 20/10/11 1:07 PM, Jonas Sicking wrote:
On Tue, Oct 18, 2011 at 9:42 AM, Alex Russellslightly...@google.com wrote:
Lachlan and I have been having an...um...*spirited* twitter discussion
regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
and :scope. He asked me to continue
On 20/10/11 7:32 PM, Jonas Sicking wrote:
On Thu, Oct 20, 2011 at 1:14 AM, Sean Hoganshogu...@westnet.com.au wrote:
On 20/10/11 1:07 PM, Jonas Sicking wrote:
On Tue, Oct 18, 2011 at 9:42 AM, Alex Russellslightly...@google.com
wrote:
Lachlan and I have been having an...um...*spirited*
On 20/10/11 8:42 PM, Lachlan Hunt wrote:
On 2011-10-20 10:14, Sean Hogan wrote:
The primary use-case for matchesSelector() has been event-delegation,
and this is the same for matches(). More specifically, consider the
following scenario:
jQuery adds a new event registration method that uses
On 20/10/11 10:05 PM, Lachlan Hunt wrote:
On 2011-10-20 12:50, Alex Russell wrote:
On Thu, Oct 20, 2011 at 6:55 AM, Jonas Sickingjo...@sicking.cc wrote:
Oh, and as a separate issue. I think .findAll should return a plain
old JS Array. Not a NodeList or any other type of host object.
I
On 20/10/11 10:49 PM, Lachlan Hunt wrote:
On 2011-10-20 13:35, Sean Hogan wrote:
I wonder if anyone is relying on querySelectorAll() returning a
StaticNodeList?
Only if there are people out there using list.item(n) instead of
list[n], or people extending the NodeList interface and expecting
On 20/10/11 12:39 AM, Timmy Willison wrote:
From the perspective of building a selector engine, I think all
selector engines need something like .findAll, and not something like
:scope.
On Tue, Oct 18, 2011 at 8:00 PM, Alex Russell slightly...@google.com
mailto:slightly...@google.com wrote:
On 23/10/11 5:44 AM, Timmy wrote:
On Oct 21, 2011, at 7:57 PM, Sean Hogan wrote:
It was definitely not a design flaw in QSA. As Alex's sample code shows it is
possible to get findAll() behavior using QSA.
I think that further supports my argument. JS libraries have commonly
considered
On 26/10/11 4:43 AM, Yehuda Katz wrote:
Your guesses are all right in terms of existing jQuery but one:
'div': [1, 2, 3, 4]
'': []
'#3': [3]
' div': [1, 2, 3]
'[foo=bar]': []
'[id=1]': [1]
':first-child': [1, 4]
'+ div': [5]
'~ div': [5, 6]
You can see the results live at
On 26/10/11 7:51 AM, Tab Atkins Jr. wrote:
On Tue, Oct 25, 2011 at 1:47 PM, Sean Hoganshogu...@westnet.com.au wrote:
I think allowing explicit :scope in findAll() will be perpetually confusing.
I can imagine someone looking at old code like:
e.findAll(div.foo span, div.bar :scope span)
On 26/10/11 9:28 AM, Tab Atkins Jr. wrote:
On Tue, Oct 25, 2011 at 2:33 PM, Sean Hoganshogu...@westnet.com.au wrote:
On 26/10/11 7:51 AM, Tab Atkins Jr. wrote:
On Tue, Oct 25, 2011 at 1:47 PM, Sean Hoganshogu...@westnet.com.au
wrote:
I think allowing explicit :scope in findAll() will be
On 26/10/11 11:03 AM, Yehuda Katz wrote:
fwiw, jQuery doesn't properly handle the comma-separated case, but
this is most definitely a bug, caused by the naïve implementation that
Alex showed early on in this thread.
So no-one is actually using +foo, +bar? How common is +foo usage?
Sean
On 30/10/11 2:28 PM, Cameron McCormack wrote:
On 20/10/11 3:50 AM, Alex Russell wrote:
I strongly agree that it should be an Array *type*, but I think just
returning a plain Array is the wrong resolution to our NodeList
problem. WebIDL should specify that DOM List types *are* Array types.
It's
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
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 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
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
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
On 25/11/11 5:53 AM, Yehuda Katz wrote:
So, the rules end up being very simple. find always evaluates against
the whole document. If one of the selectors starts with a combinator
or doesn't contain a :scope pseudoclass somewhere in it, :scope is
prepended to it. That's it.
72 matches
Mail list logo
