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

2011-11-25 Thread Sean Hogan
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

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

2011-11-25 Thread Sean Hogan
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

Re: Remaining Problems with Explicit :scope Switching in find/findAll

2011-11-25 Thread Sean Hogan
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.

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

2011-11-24 Thread Sean Hogan
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

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

2011-11-24 Thread Sean Hogan
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

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

2011-11-24 Thread Sean Hogan
On 25/11/11 12:21 PM, Boris Zbarsky wrote: On 11/24/11 7:07 PM, Sean Hogan wrote: If and when there is a need for a matching method that does imply :scope (which I provided a use-case for in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html) That's a use case passing

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

2011-11-23 Thread Sean Hogan
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

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

2011-11-22 Thread Sean Hogan
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:

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

2011-11-21 Thread Sean Hogan
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

Re: QSA, the problem with :scope, and naming

2011-10-30 Thread Sean Hogan
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

Re: QSA, the problem with :scope, and naming

2011-10-25 Thread Sean Hogan
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

Re: QSA, the problem with :scope, and naming

2011-10-25 Thread Sean Hogan
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)

Re: QSA, the problem with :scope, and naming

2011-10-25 Thread Sean Hogan
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

Re: QSA, the problem with :scope, and naming

2011-10-25 Thread Sean Hogan
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

Re: QSA, the problem with :scope, and naming

2011-10-23 Thread Sean Hogan
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

Re: QSA, the problem with :scope, and naming

2011-10-21 Thread Sean Hogan
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:

Re: QSA, the problem with :scope, and naming

2011-10-20 Thread Sean Hogan
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

Re: QSA, the problem with :scope, and naming

2011-10-20 Thread Sean Hogan
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.

Re: QSA, the problem with :scope, and naming

2011-10-20 Thread Sean Hogan
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

Re: QSA, the problem with :scope, and naming

2011-10-20 Thread Sean Hogan
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*

Re: QSA, the problem with :scope, and naming

2011-10-20 Thread Sean Hogan
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

Re: QSA, the problem with :scope, and naming

2011-10-20 Thread Sean Hogan
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

Re: QSA, the problem with :scope, and naming

2011-10-20 Thread Sean Hogan
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

Re: QSA, the problem with :scope, and naming

2011-10-19 Thread Sean Hogan
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

Re: QSA, the problem with :scope, and naming

2011-10-18 Thread Sean Hogan
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

Re: QSA, the problem with :scope, and naming

2011-10-18 Thread Sean Hogan
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

Re: Mutation Observers: a replacement for DOM Mutation Events

2011-10-13 Thread Sean Hogan
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

Re: Mutation Observers: a replacement for DOM Mutation Events

2011-10-13 Thread Sean Hogan
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

Re: Mutation Observers: a replacement for DOM Mutation Events

2011-10-12 Thread Sean Hogan
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:

Re: Mutation Observers: a replacement for DOM Mutation Events

2011-10-12 Thread Sean Hogan
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

Re: Mutation Observers: a replacement for DOM Mutation Events

2011-10-12 Thread Sean Hogan
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

Re: Mutation Observers: a replacement for DOM Mutation Events

2011-10-10 Thread Sean Hogan
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

Re: [DOM4] Remove Node.isSameNode

2011-09-09 Thread Sean Hogan
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

Re: [DOM4] Remove Node.isSameNode

2011-09-09 Thread Sean Hogan
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

Re: DOM Mutation Events Replacement: When to deliver mutations

2011-09-08 Thread Sean Hogan
On 8/09/11 8:57 AM, Travis Leithead wrote: When I proposed watchSelector [2], the idea was clearly to propose an option that provided semantics similar to Option 4 as described here. The primary benefits I sought were: Pros: * batching - allow a script to operate on the DOM's cumulative

Re: HTMLElement.register--giving components tag names

2011-09-06 Thread Sean Hogan
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

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

2011-09-04 Thread Sean Hogan
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

Re: More use-cases for mutation events replacement

2011-07-25 Thread Sean Hogan
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

Re: Mutation events replacement

2011-07-20 Thread Sean Hogan
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

Re: Mutation events replacement

2011-07-09 Thread Sean Hogan
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

Re: Mutation events replacement

2011-07-08 Thread Sean Hogan
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

Re: Mutation events replacement

2011-07-08 Thread Sean Hogan
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

Re: Mutation events replacement

2011-07-05 Thread Sean Hogan
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

Re: Comments on proposed editor's draft of XBL2 from Forms WG

2010-09-23 Thread Sean Hogan
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:

Re: Publishing Selectors API Level 2 as an FPWD?

2010-01-11 Thread Sean Hogan
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

Re: Publishing Selectors API Level 2 as an FPWD?

2010-01-11 Thread Sean Hogan
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

Re: Publishing Selectors API Level 2 as an FPWD?

2010-01-11 Thread Sean Hogan
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

Re: Publishing Selectors API Level 2 as an FPWD?

2010-01-10 Thread Sean Hogan
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

Re: Publishing Selectors API Level 2 as an FPWD?

2010-01-10 Thread Sean Hogan
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

Re: Publishing Selectors API Level 2 as an FPWD?

2010-01-10 Thread Sean Hogan
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

Re: Publishing Selectors API Level 2 as an FPWD?

2010-01-10 Thread Sean Hogan
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

Re: CfC - publish Selectors API as CR

2009-11-26 Thread Sean Hogan
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

Re: [selectors-api] Scoped Selectors

2009-09-30 Thread Sean Hogan
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

Re: [selectors-api] Scoped Selectors

2009-09-25 Thread Sean Hogan
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

Re: [selectors-api] Scoped Selectors

2009-09-25 Thread Sean Hogan
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

Re: [selectors-api] Scoped Selectors

2009-09-25 Thread Sean Hogan
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

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Sean Hogan
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

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Sean Hogan
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

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Sean Hogan
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

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Sean Hogan
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

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Sean Hogan
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

Re: [selectors-api] Scoped Queries

2009-09-23 Thread Sean Hogan
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

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-23 Thread Sean Hogan
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

Re: [selectors-api] Scoped Queries

2009-09-23 Thread Sean Hogan
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

Re: [selectors-api] Scoped Queries

2009-09-23 Thread Sean Hogan
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

Re: Storage 'length' and enumeration

2009-04-30 Thread Sean Hogan
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

Re: Storage 'length' and enumeration

2009-04-29 Thread Sean Hogan
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

Re: Storage 'length' and enumeration

2009-04-29 Thread Sean Hogan
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

Re: Storage 'length' and enumeration

2009-04-29 Thread Sean Hogan
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

Re: DOM3 Events call today/tonight?

2009-02-25 Thread Sean Hogan
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

Re: [cors] ACTION-11 API use cases

2009-02-10 Thread Sean Hogan
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

Re: [cors] ACTION-11 API use cases

2009-02-10 Thread Sean Hogan
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

Re: Seeking implementation status of XBL2

2009-02-09 Thread Sean Hogan
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

Re: Call for Consensus - Selectors Last Call

2008-12-06 Thread Sean Hogan
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