Re: XPath and find/findAll methods
On Tue, Nov 29, 2011 at 7:33 AM, Liam R E Quin l...@w3.org wrote: (2) Not a dead end XSLT 1 and XPath 1 are not evolutionary dead ends although it's true that neither the xt nor the libxml2 library supports XSLT 2 and XPath 2. There's some support (along with XQuery) in the Qt libraries, and also in C++ with XQilla and Zorba. There are maybe 50 implementations of XPath 2 and/or XQuery 2 that I've encountered. XQuery 3.0 and XPath 3.0 are about to go to Last Call, we hope, and XSLT 3.0 to follow next year. The work is very much active and alive. Sure, XPath and XSLT keep being developed. What I meant by evolutionary dead end is that the XPath 1.0-compatibile evolutionary path has been relegated to a separate mode instead of XPath 2.0 and newer being compatible by design. So the new development you cite happens with Compatibility Mode set to false. To remain compatible with existing content, browsers would presumably have to live in the Compatibility Mode set to true world, which would mean browsers living on a forked evolutionary path that isn't the primary interest of the WGs working on the evolution. I don't have enough data about existing XPath-using Web content to know how badly the Web would break if browsers started interpreting existing XPath (1.x) expressions as XPath 2.x expression with Compatibility Mode set to false, but the fact that the WG felt that it needed to define a compatibility mode suggests that the WG itself believed the changes to be breaking ones. /html/body/div/p[@id = /html/head/link[@rel = 'me']/@src]/strong This example depends on unprefixed name expressions matching the (X)HTML namespace when tested against an element and no namespace when tested against attributes. And that trick only works with (X)HTML nodes. Selectors have the advantage that they wildcard the namespace by default, so it's feasible to define APIs that don't even have namespace binding mechanisms. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: XPath and find/findAll methods
On Nov 29, 2011, at 17:09 , Henri Sivonen wrote:
/html/body/div/p[@id = /html/head/link[@rel = 'me']/@src]/strong
This example depends on unprefixed name expressions matching the
(X)HTML namespace when tested against an element and no namespace when
tested against attributes. And that trick only works with (X)HTML
nodes.
Selectors have the advantage that they wildcard the namespace by
default, so it's feasible to define APIs that don't even have
namespace binding mechanisms.
That's a candidate for fixing or, as Anne put it, DOM4-ification. If you look
at Opera's implementation, you see:
document.selectSingleNode(//p).namespaceURI
http://www.w3.org/1999/xhtml;
and
document.selectSingleNode(//html:p, function () { return
http://www.w3.org/1999/xhtml;; }).namespaceURI
http://www.w3.org/1999/xhtml;
I'm not sure that it would break much existing content — would be useful to
look further though.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Re: XPath and find/findAll methods
On Nov 28, 2011, at 19:11 , Ojan Vafai wrote: Every task we take on in the working group has a cost. It makes it more difficult to focus on other features and specs we want to see happen. I would prefer that we focus on making css selectors richer instead of extending xpath. I don't have new arguments to make beyond what's already been said. I think that we have the same goals and agree on cost. We just happen to come to different conclusions. I think that improving CSS selectors to the point where they address the same use cases as XPath would be much, much costlier than the small amount of fixing that is required atop the existing XPath implementations. Note that there is no notion of extending XPath. It is certainly possible, but I don't believe that there's demand, or a need for it. All that's on the table is wrapping up DOM 3 XPath in a way that's actually usable and interoperable. My strong preference would be that we not take on this work, but I won't block it happening if someone is motivated to be the editor for it. I don't expect there to be much interest from WebKit/Chromium to implement this though. I would hope that the amount of fixing required could be implemented as a shim so as to be usable immediately. If that happens, I guess you can then make the call of whether or not to support it more directly. It would certainly be less trouble than the cruft that's currently needed for DOM 3 XPath :) -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: XPath and Selectors are identical, and shouldn't be co-developed
On Tue, Nov 29, 2011 at 12:18 PM, Julian Reschke julian.resc...@gmx.de wrote: On 2011-11-29 20:07, Tab Atkins Jr. wrote: ... Since XPath and Selectors are 95% overlapping in functionality and 100% overlapping in goals and overall structure, I believe it is a bad idea to try and develop both for the web platform. Instead, we should ... The proposal wasn't to develop XPath as in doing more work on the expression language. What *was* proposed is to fix/standardize the API for XPath, which already is part of the web platform. Speccing, implementing, and testing an API is also developing, particularly when it appears there's a desire to spec, implement, and test a new, more convenient API that's currently proprietary to a few browsers. For the reasons stated in my email, I believe this effort to be a bad idea. ~TJ
Re: XPath and Selectors are identical, and shouldn't be co-developed
On 2011-11-29 21:24, Tab Atkins Jr. wrote: On Tue, Nov 29, 2011 at 12:18 PM, Julian Reschkejulian.resc...@gmx.de wrote: On 2011-11-29 20:07, Tab Atkins Jr. wrote: ... Since XPath and Selectors are 95% overlapping in functionality and 100% overlapping in goals and overall structure, I believe it is a bad idea to try and develop both for the web platform. Instead, we should ... The proposal wasn't to develop XPath as in doing more work on the expression language. What *was* proposed is to fix/standardize the API for XPath, which already is part of the web platform. Speccing, implementing, and testing an API is also developing, particularly when it appears there's a desire to spec, implement, and test a new, more convenient API that's currently proprietary to a few browsers. For the reasons stated in my email, I believe this effort to be a bad idea. Well, if people are ready to do the specification, implementation and testing work, what's the reason to stop them? Yes, I know, opportunity cost. But guess what, that's not going to be a convincing argument for those who really want that feature. Best regards, Julian
Re: XPath and Selectors are identical, and shouldn't be co-developed
On Tue, Nov 29, 2011 at 12:28 PM, Julian Reschke julian.resc...@gmx.de wrote: On 2011-11-29 21:24, Tab Atkins Jr. wrote: On Tue, Nov 29, 2011 at 12:18 PM, Julian Reschkejulian.resc...@gmx.de wrote: On 2011-11-29 20:07, Tab Atkins Jr. wrote: ... Since XPath and Selectors are 95% overlapping in functionality and 100% overlapping in goals and overall structure, I believe it is a bad idea to try and develop both for the web platform. Instead, we should ... The proposal wasn't to develop XPath as in doing more work on the expression language. What *was* proposed is to fix/standardize the API for XPath, which already is part of the web platform. Speccing, implementing, and testing an API is also developing, particularly when it appears there's a desire to spec, implement, and test a new, more convenient API that's currently proprietary to a few browsers. For the reasons stated in my email, I believe this effort to be a bad idea. Well, if people are ready to do the specification, implementation and testing work, what's the reason to stop them? Yes, I know, opportunity cost. But guess what, that's not going to be a convincing argument for those who really want that feature. I never threatened physical harm to anyone attempting to work on it; I can't stop them if they really want to. My stated goal was to argue that working on XPath is a bad idea, and that any editor effort can be better spent elsewhere (either directly on Selectors, or on the rest of the web platform). I also attempted to combat some statements I saw cropping up repeatedly which were incorrect. ~TJ
FYI: New email alias for WebAppSec WG test suite work
Original Message Subject:New email alias for WebAppSec WG test suite work Resent-Date:Tue, 29 Nov 2011 20:46:50 + Resent-From:public-webapp...@w3.org Date: Tue, 29 Nov 2011 13:46:08 -0700 From: ext Hill, Brad bh...@paypal-inc.com To: public-webapp...@w3.org public-webapp...@w3.org WebAppSec WG members, Carine has created a new mailing list for us to discuss test suite issues: public-webappsec-testsu...@w3.org mailto:public-webappsec-testsu...@w3.org The archives and home page are at: http://lists.w3.org/Archives/Public/public-webappsec-testsuite/ -Brad Hill
Re: XPath and Selectors are identical, and shouldn't be co-developed
On Tue, 29 Nov 2011 20:42:59 -, Tab Atkins Jr. jackalm...@gmail.com wrote: My stated goal was to argue that working on XPath is a bad idea You can argue that it's wasted effort or duplicated by CSS Selectors (although XPath is already specified, implemented and deployed unlike the new Selector features), but it goes a long way for you to claim it is a *bad* idea. I still think you are underestimating XPath. There are things possible in XPath today that will never be possible with Selectors in the unforeseeable future, like a parent selector, or doing a case insensitive substring match of a node's text content (from any descendant). If you're suggesting forking Selectors into the ones used in stylesheet, and the others used in the Selector API, then it is repeated effort and a *bad* idea because those use cases are already covered today with already deployed XPath and its DOM 3 XPath API, which is convoluted and hard to use, which is what people are trying to make friendlier. And it would definitely confuse everyone, because then developers would need to know which features they can use in stylesheets and which they cannot.
Re: XPath and Selectors are identical, and shouldn't be co-developed
On Tue, Nov 29, 2011 at 4:16 PM, João Eiras jo...@opera.com wrote:
On Tue, 29 Nov 2011 20:42:59 -, Tab Atkins Jr. jackalm...@gmail.com
wrote:
My stated goal was to argue that working on XPath is a bad idea
You can argue that it's wasted effort or duplicated by CSS Selectors
(although XPath is already specified, implemented and deployed unlike the
new Selector features), but it goes a long way for you to claim it is a
*bad* idea.
I still think you are underestimating XPath. There are things possible in
XPath today that will never be possible with Selectors in the unforeseeable
future, like a parent selector, or doing a case insensitive substring match
of a node's text content (from any descendant).
Incorrect. The Selectors 4 editor's draft contains the same
functionality as a parent selector: A/parent::B in XPath is the
same as B! A in Selectors. I talked about this in my email.
Matching based on text contents has been proposed multiple times, but
has always been shot down due to performance concerns for CSS. A
profile of Selectors designed for JS (querySelector or find) wouldn't
have that same worry.
If you're suggesting forking Selectors into the ones used in stylesheet, and
the others used in the Selector API, then it is repeated effort and a *bad*
idea because those use cases are already covered today with already deployed
XPath and its DOM 3 XPath API, which is convoluted and hard to use, which is
what people are trying to make friendlier. And it would definitely confuse
everyone, because then developers would need to know which features they can
use in stylesheets and which they cannot.
You are looking at the cost of one possibility, and ignoring the
other. If we go your way, developers have a single set of Selectors
which they can use in CSS and JS, plus a set of XPath they can use in
JS, but they can't combine the two JS solutions in any reasonable way,
so the features that each have can't be used together, and for the
parts that are duplicated between the two they have to learn two
different syntaxes. I think it's impossible to argue that that's not
at least as confusing; I will argue further and say that it's
substantially more confusing.
This argument in general seems to have an underlying assumption that
XPath is necessarily more powerful than Selectors. This is incorrect.
Most of the useful bits of XPath and Selectors are isomorphic. XPath
has a few things that are more powerful, such as a general mechanism
for matching nodes based on simple math or string manipulation, but
they can be duplicated quite easily in JS. Selectors has a few things
that are more powerful, such as most of the pseudoclasses, but these
are *not* generally easily duplicable in JS. For example, handling
something simple like :nth-col() requires snooping through the
entire preceding table structure for row/colspan cells that would
alter the numbering beyond simple sibling-counting.
So, the simple hack of doing
document.evaluate(...).filter(function(elem){...}) doesn't work so
well if you're patching XPath into the union of features, but it
*does* work pretty well for patching Selectors into the union of
features.
My overriding point is that the mental cost of supporting two nearly
identical languages merely because they both already exist and each
has slightly different functionality than the other is horrible, and
we should avoid it if at all possible. It is roughly equivalent to
having, say, a captionedvideo element that accepts subtitles but
doesn't have controls, and a usablevideo that has controls but not
subtitles. Even if you can achieve any given feature by choosing one
or the other, it's much less useful (and much more confusing) to have
the two separate than it would be to just combine them. It is
absolutely worthwhile to expend effort in raising up one language to
the union or near-union of the feature-set (or achieve the union some
other way, like cheap/easy JS integration with Selectors) than to
attempt to pursue both simultaneously.
~TJ
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
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 named matchesSelector(). I'd be ok with querySelector/querySelectorAll/matchesSelector and find/findAll/matches As I have said, I personally consider qS/qSA to be implementation mistakes and would like to see find and findAll replace querySelector[All] in all cases, so maybe we don't need a matchesSelector then? 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: [Component Model] Decorator Challenges
On Tue, Nov 29, 2011 at 11:15, Roland Steiner rolandstei...@google.comwrote: If we are considering worker-like decorators, then AFAICT it doesn't have to be an actual worker - it's enough if it's a separate object that can be attached and detached. As long as we define the interfaces nicely, FWIW this object could even hold internal state, etc. I should point out that we already have exactly such an interface in the form of the host element - ShadowRoot boundary! Essentially, one could view Decorators as shadow DOM where scripts are only allowed in the shadow side. - Roland
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
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 matchesSelector API at the moment because the cost of testing/avoiding cross-browser bugs kills any perf gains. https://github.com/dperini/nwmatcher/commit/10a48ac54c3673c125c540447bb74c75cd1a9ed4 -JDD On Tue, Nov 29, 2011 at 10:26 PM, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Fri, Nov 25, 2011 at 7:49 AM, William Edney bed...@technicalpursuit.com wrote: 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(). I'd be ok with querySelector/querySelectorAll/matchesSelector and find/findAll/matches As I have said, I personally consider qS/qSA to be implementation mistakes and would like to see find and findAll replace querySelector[All] in all cases, so maybe we don't need a matchesSelector then? 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
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
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 drives the lib. https://github.com/dperini/nwmatcher/blob/master/src/nwmatcher-base.js#L391 I totally agree that we need the feature. This discussion was only about what to name it. The matchesSelector name fits better with querySelectorAll, while bare matches fits with the proposed find/findAll (which would be properly scoped). Since I'm in favor of the find[All] APIs, I am also in favor of the matches name :) Though he avoids the matchesSelector API at the moment because the cost of testing/avoiding cross-browser bugs kills any perf gains. https://github.com/dperini/nwmatcher/commit/10a48ac54c3673c125c540447bb74c75cd1a9ed4 -JDD On Tue, Nov 29, 2011 at 10:26 PM, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Fri, Nov 25, 2011 at 7:49 AM, William Edney bed...@technicalpursuit.com wrote: 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(). I'd be ok with querySelector/querySelectorAll/matchesSelector and find/findAll/matches As I have said, I personally consider qS/qSA to be implementation mistakes and would like to see find and findAll replace querySelector[All] in all cases, so maybe we don't need a matchesSelector then? 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
