Re: XPath and find/findAll methods

On Nov 22, 2011, at 18:57 , Tab Atkins Jr. wrote:
> On Tue, Nov 22, 2011 at 9:29 AM, Robin Berjon <robin@berjon.com> wrote:
>> Are you not concerned at the flood of puzzlement brought about by having the same language that supports different features at different places in the same runtime? I can already tell that I will get it wrong on a regular basis...
> 
> I'm much less concerned about that than I am about authors having to
> learn an entirely different selection syntax which is 90% identical in
> functionality, just to get that 10% functionality on occasion.

Developers will need to learn new syntax for new features anyway, and when you don't need the new stuff you can still use CSS anyway. I don't see how this is an argument.

>>>> d - "//div[parent::*//a]";
> 
> In that case, this isn't *yet* doable in Selectors, but we plan to
> eventually support complex selectors in :matches(), at which point you
> can do:
> 
> :matches(:scope a) > div
> 
> Or with a different syntax:
> 
> :has(a) > div

Interesting. Do you have syntax examples for other typical selectors like //text() or //*[starts-with(name(@*), "data-mylib-")]? It would be good to compare.

>> Right, because since we have something that works why not invent another! Makes perfect sense to me.
> 
> I know you're being somewhat hostile because you like XPath and we're
> essentially saying "ignore XPath, it's dead", but still, you're
> arguing badly.

I don't care about XPath, I care about getting stuff done. And by done, I mean preferably before I reach retirement age.

One the one hand we have a solution that works today and can be made simple to use with minor tweaking. The time required to bang this API into shape is measured in months, definitely less than a year. Then I can get the sort of tree manipulation that I need, and I can stop pestering you. I think that works out great for all involved.

Instead of this you're proposing some experimental, as-yet-undrafted, potentially-done-someday extension syntax to CSS that could, perhaps, address some of the use cases.

If you're willing to put your arse on the line that the CSS WG can deliver a version of Selectors that matches XPath for functionality by TPAC next year, then by all means go ahead. But somehow, I don't believe that's the case, and I don't believe you do either.

I don't care about syntax or overlap purity. I care about features.

I don't care that the CSS WG has a deeply held grudge against XPath and will go to all extremes to admit that it might actually be useful. I care about being pragmatic and delivering functionality in a timely fashion and will take what's available.

I don't care about standards wars and the "battles" you so fondly mention. I don't know what you mean by "winning" when you have authors coming to you asking for features that you are not delivering on. I care about getting those nodes, and what I call a win is when I can do so without hacking my way around the browser or loading KBs of libraries to do so.

So, can you tell me again why we should prefer CSS WG-approved purity in some indeterminate future over something that works pretty much now?

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 22 November 2011 20:03:22 UTC