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
