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