Re: Mutation events replacement

On 3/07/11 5:36 AM, Ryosuke Niwa wrote: On Sat, Jul 2, 2011 at 10:46 AM, John J. Barton 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 mutation. Why do you ne

Re: Mutation events replacement

On 8/07/11 8:28 AM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 3:21 PM, John J Barton 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 and replace or extend them. Th

Re: Mutation events replacement

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

Re: Mutation events replacement

On 9/07/11 1:12 AM, Ryosuke Niwa wrote: On Fri, Jul 8, 2011 at 5:21 AM, Sean Hogan <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 to HTML. B

Re: Mutation events replacement

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 mailto:simetrical%2b...@gmail.com>> wrote: On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan mailto:dflana...@mozilla.com>> wrote: > Finally, I still thi

Re: More use-cases for mutation events replacement

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

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

On 3/09/11 4:47 AM, Dimitri Glazkov wrote: On Fri, Sep 2, 2011 at 2:30 AM, Anne van Kesteren wrote: Examples of elements that should not be replaced but could be changed by a binding: Having a sortable binding for; Exposing cite="" on ; Turning a listing countries into a map. Great! Let's go

Re: HTMLElement.register--giving components tag names

On 7/09/11 7:20 AM, Alex Russell wrote: On Sat, Sep 3, 2011 at 8:20 PM, Ian Hickson 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 to select a c

Re: DOM Mutation Events Replacement: When to deliver mutations

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

Re: [DOM4] Remove Node.isSameNode

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 t

Re: [DOM4] Remove Node.isSameNode

On 10/09/11 11:00 AM, Jonas Sicking wrote: On Fri, Sep 9, 2011 at 2:27 PM, Sean Hogan 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 already. Except Brainfu

Re: Mutation Observers: a replacement for DOM Mutation Events

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 sensibl

Re: Mutation Observers: a replacement for DOM Mutation Events

On 12/10/11 3:26 AM, Tab Atkins Jr. wrote: On Mon, Oct 10, 2011 at 7:51 PM, Sean Hogan 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: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779

Re: Mutation Observers: a replacement for DOM Mutation Events

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 Hogan wrote: On 24/09/11 7:16 AM, Adam Klein wrote: - Is free of the faults of the existing Mutation Events mechanism

Re: Mutation Observers: a replacement for DOM Mutation Events

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 handl

Re: Mutation Observers: a replacement for DOM Mutation Events

On 13/10/11 2:33 PM, Ryosuke Niwa wrote: On Wed, Oct 12, 2011 at 8:14 PM, Sean Hogan <mailto:shogu...@westnet.com.au>> wrote: Maybe you can provide concrete examples (i.e. with code snippets, actual instances of use cases, etc...) Actually, it is the proponents of

Re: Mutation Observers: a replacement for DOM Mutation Events

On 13/10/11 7:58 PM, Ryosuke Niwa wrote: On Thu, Oct 13, 2011 at 1:32 AM, Sean Hogan <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: QSA, the problem with ":scope", and naming

On 19/10/11 7:20 AM, Yehuda Katz wrote: I agree entirely. I have asked a number of practitioner friends about this scenario: Content document.getElementById("child").querySelectorAll("div span"); // returns #inline In 100% of cases, people consider this behavior *broken*. Not just "int

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

On 19/10/11 10:58 AM, Tab Atkins Jr. wrote: On Tue, Oct 18, 2011 at 4:46 PM, Sean Hogan 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: Content document.getElementById("child").querySelect

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

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 element.fi

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

On 20/10/11 1:07 PM, Jonas Sicking wrote: On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell wrote: Lachlan and I have been having an...um...*spirited* twitter discussion regarding querySelectorAll, the (deceased?) queryScopedSelectorAll, and ":scope". He asked me to continue here, so I'll try to ke

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

On 20/10/11 5:41 PM, Jonas Sicking wrote: On Wed, Oct 19, 2011 at 11:14 PM, Sean Hogan 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. Already support

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

On 20/10/11 1:07 PM, Jonas Sicking wrote: On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell wrote: Lachlan and I have been having an...um...*spirited* twitter discussion regarding querySelectorAll, the (deceased?) queryScopedSelectorAll, and ":scope". He asked me to continue here, so I'll try to ke

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

On 20/10/11 7:32 PM, Jonas Sicking wrote: On Thu, Oct 20, 2011 at 1:14 AM, Sean Hogan wrote: On 20/10/11 1:07 PM, Jonas Sicking wrote: On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell wrote: Lachlan and I have been having an...um...*spirited* twitter discussion regarding querySelectorAll, the

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

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

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 Sicking 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 strongly agree that it

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

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

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 > wrote: No need to wait

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

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

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 http://jsfiddle.net/D

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

On 26/10/11 7:51 AM, Tab Atkins Jr. wrote: On Tue, Oct 25, 2011 at 1:47 PM, Sean Hogan 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") and asking

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

On 26/10/11 9:28 AM, Tab Atkins Jr. wrote: On Tue, Oct 25, 2011 at 2:33 PM, Sean Hogan wrote: On 26/10/11 7:51 AM, Tab Atkins Jr. wrote: On Tue, Oct 25, 2011 at 1:47 PM, Sean Hogan wrote: I think allowing explicit :scope in findAll() will be perpetually confusing. I can imagine someone

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

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

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 i

Re: innerHTML in DocumentFragment

On 4/11/11 10:03 AM, Yehuda Katz wrote: It would be useful if there was a way to take a String of HTML and parse it into a document fragment. This should work even if the HTML string contains elements that are invalid in the "in body" insertion mode. Something like this code should work: v

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

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

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

On 22/11/11 7:14 PM, Roland Steiner wrote: On Tue, Nov 22, 2011 at 14:19, Yehuda Katz > wrote: Yehuda Katz (ph) 718.877.1325 On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky mailto:bzbar...@mit.edu>> wrote: On 11/21/11 11:31 AM, Tab Atkins Jr. wrot

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

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

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

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 <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: Last time we

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

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

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

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 passi

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

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

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

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

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: Comments on proposed editor's draft of XBL2 from Forms WG

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

Re: Call for Consensus - Selectors Last Call

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 querySelect

Re: Call for Consensus - Selectors Last Call

Lachlan Hunt wrote: Sean Hogan wrote: 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

Re: [selectors-api] matchesSelector() Proposal

this code. Just pointing out that I'm not just full of hot air. /* Light-weight (or poor man's) XBL2. (c) Sean Hogan, December 2008 All rights reserved. NOTES: Uses event delegation and late-binding to do everything. Bindings are created when an event is handled and destroyed immediat

Re: Seeking implementation status of XBL2

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 pro

Re: [cors] ACTION-11 API use cases

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 X

Re: [cors] ACTION-11 API use cases

Anne van Kesteren wrote: On Tue, 10 Feb 2009 13:00:35 +0100, Sean Hogan 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 policy ena

Re: DOM3 Events call today/tonight?

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 or Element (instead of window). I would also suggest a progress event on document or window. Ideally it would be t

Re: DOM3 Events call today/tonight?

Charles McCathieNevile wrote: On Wed, 25 Feb 2009 22:59:06 +0100, Sean Hogan 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 or Element (

Re: Storage 'length' and enumeration

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 wo

Re: Storage 'length' and enumeration

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 poin

Re: Storage 'length' and enumeration

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, elements, Window objects, History, CanvasPixelArrays, etc. I'm not sure about all those objects, but my (incomplete) testing of HTML*Colle

Re: Storage 'length' and enumeration

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

Re: [selectors-api] Scoped Queries

Jonas Sicking wrote: On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt 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 of the element, in a way m

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

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 NodeList

Re: [selectors-api] Scoped Queries

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 i

Re: [selectors-api] Scoped Queries

Jonas Sicking wrote: On Wed, Sep 23, 2009 at 6:00 PM, Sean Hogan wrote: Jonas Sicking wrote: On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt wrote: *Scoped Queries* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 This has been discussed extensively in the past. Basically

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

Garrett Smith wrote: On Thu, Sep 24, 2009 at 12:02 AM, Mike Wilson 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 delegation library creators

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

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&#x

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

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 lapt

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

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 che

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

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,

Re: [selectors-api] Scoped Selectors

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

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

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 p

Re: [selectors-api] Scoped Selectors

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: CfC - publish Selectors API as CR

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 bas

Re: Publishing Selectors API Level 2 as an FPWD?

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?

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 th

Re: Publishing Selectors API Level 2 as an FPWD?

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

Re: Publishing Selectors API Level 2 as an FPWD?

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

Re: Publishing Selectors API Level 2 as an FPWD?

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 retur

Re: Publishing Selectors API Level 2 as an FPWD?

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

Re: Publishing Selectors API Level 2 as an FPWD?

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