On Nov 22, 2011, at 18:57 , Tab Atkins Jr. wrote: > On Tue, Nov 22, 2011 at 9:29 AM, Robin Berjon <[email protected]> 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
