Re: Dropping XMLHttpRequest 1 (just do 2)?
On Thu, 24 Nov 2011 20:39:16 +0100, Yehuda Katz wyc...@gmail.com wrote: Awesome. I wonder if there's any utility to linking to the exact thread where the merge was agreed to? I do not think so, but if people end up asking that a lot I will make sure to do that. Cheers, -- Anne van Kesteren http://annevankesteren.nl/
Re: XPath and find/findAll methods
On Thu, Nov 24, 2011 at 5:19 PM, Julian Reschke julian.resc...@gmx.de wrote: Well, the use case is to allow browsers to move to XPath2/XSLT2 at some point in the future, without having to maintain another engine. Sorry about bringing up the XPath2 rathole that's now expanding into the XSLT2 rathole. My point was that since XPath2/XSLT2 made incompatible changes, there isn't a smooth path for moving to XPath2/XSLT2 proper in browsers in the future even if browser vendors felt that it was worthwhile to expend the effort. There seems to be a potential migration path to XPath2_compat/XSLT2_compat, though, but do the people who want XPath2/XSLT2 want just the compat mode variants or the variants that the relevant WG treats as the primary ones? In any case, I think XPath2/XSLT2 have a bad investment/payoff ratio from the browser point of view, so I think it makes sense for people who want to use XSLT2 in browsers to license Saxon-CE (XSLT2 implemented in JavaScript) from Saxonica instead of expecting native implementations in browsers. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: XPath and find/findAll methods
On 2011-11-24 14:49, Robin Berjon wrote: So, now for the money question: should we charter this? Only if someone is volunteering to be the editor and drafts a spec. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Remaining Problems with Explicit :scope Switching in find/findAll
On 2011-11-25 03:58, Tab Atkins Jr. wrote: Alternately, assume that :matches() is eventually changed to allow complex selectors. Using :scope there is completely fine. I'm not sure what you mean. The current spec for matchesSelector does allow complex selectors as it's defined to accept a group of selectors (selectors 3 terminology), which is equivalent to a selector list (selectors 4). But :scope is still only useful when ref nodes are supplied. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[Bug 14666] Be clearer about cookies and CORS
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14666 Anne ann...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Anne ann...@opera.com 2011-11-25 09:13:58 UTC --- Added a note to the network error steps: http://dvcs.w3.org/hg/cors/rev/1b13c2d13067 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: XPath and find/findAll methods
On Nov 25, 2011, at 10:03 , Lachlan Hunt wrote: On 2011-11-24 14:49, Robin Berjon wrote: So, now for the money question: should we charter this? Only if someone is volunteering to be the editor and drafts a spec. If no one else steps up to it I can, but I was under the impression that our good friends from Opera had a solution they could contribute — I would hope in the shape of an editor :) -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: XPath and find/findAll methods
* Robin Berjon wrote: If no one else steps up to it I can, but I was under the impression that our good friends from Opera had a solution they could contribute — I would hope in the shape of an editor :) I started it some years ago, but then figured if anybody brought it up the selectors shirts would have yet another trollfest, followed by name- space mobbing, and I am too young to watch only the re-runs. I'm happy to contribute some tests though -- if the specification won't be a goto assembly with eye-burning formatting and inhuman popup boxes... -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
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 would be equivalent to: elt.findAll(:scope div span, div :scope span) If this isn't to throw an error then a more complex definition is required which can apply a different rule for implying :scope in different parts of the selector argument. This is sure to be confusing for anyone reading the code. Selectors in selector lists are always independent of each other, so authors who use a selector list would likely assume that one doesn't affect how another in the list matches. It would seem far more confusing for authors to do it using the other alternatives. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
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 selector basis, rather than applied to the entire list. That would be equivalent to: elt.findAll(:scope div span, div :scope span) If this isn't to throw an error then a more complex definition is required which can apply a different rule for implying :scope in different parts of the selector argument. This is sure to be confusing for anyone reading the code. Selectors in selector lists are always independent of each other, so authors who use a selector list would likely assume that one doesn't affect how another in the list matches. It would seem far more confusing for authors to do it using the other alternatives. Discussion on this list has indicated that allowing explicit :scope in findAll() is confusing, which-ever definition is used. OTOH, there has been little or no confusion about how findAll() would behave if :scope is always implied. Do you expect the general web-dev community to be different?
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) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. 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) then it could be called matches(). Oh, it wasn't clear that you were talking about a case involving explicit reference nodes before. But adding two separate methods that are only subtly different would add more complexity for authors, since the difference will not always be obvious where there is no explicit reference nodes supplied and they may get them confused. In fact, with a method that always prepends :scope, it could result in an unexpected result in some cases: e.g. root.matches(html.foo); root.matchesSelector(html.foo); These aren't obviously different, but when you consider that the first would always prepend :scope under your proposal, the first would unexpectedly return false, since it's equivalent to: root.matchesSelector(:scope html.foo); This would happen whether the root element is the root of the document, or the root of a disconnected tree. We could instead address your use case by implying :scope if a refElement or refNodes is supplied. That way, if the author calls .matches() without any refNodes, they get the expected result with no implied :scope. If they do supply refNodes, and there is no explicit :scope, then imply :scope at the beginning. This approach would be completely backwards compatible with the existing implementations, as nothing changes until refNodes/refElement and :scope are supported. You mentioned this before, but anyway: el.matches(div span) - ok el.matches( div span) - throws, because no :scope implied el.matches(div :scope span) - ok, but can't match anything el.matches( div span, refNode) - ok el.matches(div :scope span, refNode) - ok el.matches(div span, refNode) - what does this do? How do you know that the intention isn't to just ignore the refNode if there is no explicit :scope? I guess if you wanted this last behavior, you could call something like /:scope\b/.test(selector) before-hand and if it is false then not pass the refNode to matches(). I'm not sure if there are other problematic cases. Sean
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
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 to have consistency in naming above all else. JS libraries can always alias / wrap these names should they so desire. Name shortening has already been occurring... if we had followed 'old W3C DOM-style naming', querySelectorAll() would've been 'documentGetElementsBySelector()'. Providing a balance between short names and descriptive names is important. One of the things that drives me nuts about the (non-standard) 'document.evaluate()' call (exists on FF / Webkit to query using XPath), is that it is not explicit enough... 'evaluate' what? JS? XPath? CSS? While I don't disagree that shorter names could've been chosen all of those years ago, as Austin Powers would say, That train has sailed, baby... Cheers, - BIll On Nov 25, 2011, at 8:04 AM, Sean Hogan wrote: 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) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. 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) then it could be called matches(). Oh, it wasn't clear that you were talking about a case involving explicit reference nodes before. But adding two separate methods that are only subtly different would add more complexity for authors, since the difference will not always be obvious where there is no explicit reference nodes supplied and they may get them confused. In fact, with a method that always prepends :scope, it could result in an unexpected result in some cases: e.g. root.matches(html.foo); root.matchesSelector(html.foo); These aren't obviously different, but when you consider that the first would always prepend :scope under your proposal, the first would unexpectedly return false, since it's equivalent to: root.matchesSelector(:scope html.foo); This would happen whether the root element is the root of the document, or the root of a disconnected tree. We could instead address your use case by implying :scope if a refElement or refNodes is supplied. That way, if the author calls .matches() without any refNodes, they get the expected result with no implied :scope. If they do supply refNodes, and there is no explicit :scope, then imply :scope at the beginning. This approach would be completely backwards compatible with the existing implementations, as nothing changes until refNodes/refElement and :scope are supported. You mentioned this before, but anyway: el.matches(div span) - ok el.matches( div span) - throws, because no :scope implied el.matches(div :scope span) - ok, but can't match anything el.matches( div span, refNode) - ok el.matches(div :scope span, refNode) - ok el.matches(div span, refNode) - what does this do? How do you know that the intention isn't to just ignore the refNode if there is no explicit :scope? I guess if you wanted this last behavior, you could call something like /:scope\b/.test(selector) before-hand and if it is false then not pass the refNode to matches(). I'm not sure if there are other problematic cases. Sean
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. With this, we make the most common cases (searching descendants/siblings) easy, while making the global case *also* easy. There's a bit of intent-guessing when :scope is used in an indirect way, but I believe it's better to err on the side of simplicity and consistency there. I am ok with this, but I am also ok with find always evaluates against the whole document. If one of the selectors doesn't contain a :scope pseudoclass somewhere in it, :scope is prepended to it. I also thing we agreed that filtering selectors, in the case of implicit scope, are applied on the :scope, not as a descendent of the :scope. As I said above, since the cases of starting with a combinator are nonsense queries (correct me if I'm missing something obvious), we can simplify the rules even more and eliminate the case of starting with a combinator *and* has a :scope Are you AGAINST findAll() always implying :scope at the start of each selector in a selector list, and leaving explicit :scope to querySelectorAll()? If so, why? Sean
