Re: XPath and find/findAll methods

On Tue, Nov 22, 2011 at 12:02 PM, Robin Berjon <robin@berjon.com> wrote:
> 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.

Come on, Robin, you're being unreasonable.  You and I both know
there's a huge difference between "new features require small amounts
of new syntax" and "oh look, it's an entirely different language".


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

Text nodes aren't selectable, though there's a recent request against
the Selectors spec (tracked in bugzilla) to allow selecting them.  I
think it's a reasonable suggestion.  The bug suggests doing this
through a "::paragraphs" pseudo-element.

I thought that your second example was doable in Selectors 3, but then
I remembered that the prefix-matching functionality is for values, not
attribute names.  Nobody has yet suggested that be supported.


>>> 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, you're familiar with XPath.  You look at it and go "Oh, neat,
it has all the features I need!".  I'm not.  I look at it and go "Oh,
look, somebody took a subset of Selectors, gave it a different syntax
for some reason, and then added some new stuff.  I can't use the new
Selectors stuff with the new XPath stuff, though, and now I have to
remember two different syntaxes for the basic stuff.  I am a sad
tab.".  I am quite certain that my position is closer to that of the
average author than yours.

Look at the platform as a whole.  There is *no way* to justify having
two completely separate mechanisms for accomplishing the exact same
thing unless you're planning on replacing one with the other.
Attempting to develop both Selectors and XPath in browsers at the same
time, without plans to merge them, is undeniably a bad thing for
authors and for the platform.

This is not about theoretical purity.  It's not about history, either
(I came into the CSSWG too late to experience any of the "battles" you
remember).  It's about producing the best API for authors and the
future, because I intend to remain a webdev for many years.


(Also: "CSS WG has a deeply held grudge" and "the 'battles' you so
fondly mention"?  You're projecting, Robin.  I expressed nothing of
the sort, and *feel* nothing of the sort.  There were two competing
technologies, and one clearly won in the browser marketplace, so I
support it.  Other technologies are useful at this point as a source
of ideas, but not as legitimate contenders.)

~TJ

Received on Tuesday, 22 November 2011 21:25:13 UTC