- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 12 Feb 2015 09:47:45 +1100
- To: Liam R E Quin <liam@w3.org>
- Cc: Marat Tanalin <mtanalin@yandex.ru>, Clive Chan <doobahead@gmail.com>, Brad Kemper <brad.kemper@gmail.com>, Henrik Andersson <henke@henke37.cjb.net>, www-style list <www-style@w3.org>
On Thu, Feb 12, 2015 at 9:43 AM, Liam R E Quin <liam@w3.org> wrote: > On Thu, 12 Feb 2015 08:24:03 +1100 > "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > >> On Thu, Feb 12, 2015 at 7:18 AM, Marat Tanalin <mtanalin@yandex.ru> wrote: >> [...] It hasn't yet been added because >> it's technically difficult to make it work in a performant manner. > > We went through something very similar with reverse selectors in XQuery in streaming environments. I suspect the same research papers on rewriting XPath expressions for performance apply to CSS selectors, except that CSS also I think lacks a parent selector. It turned out that the restrictions XQuery had on XPath "axes" (e.g. following-sibling, preceding-sibling) were not needed, because you could rewrite them all in terms of the ones we had... > > Worse, it turned out that users simulated the axes themselves - just as one would in JavaScript in a Web browser - and the simulations were slow and hard to optimize. > > To some extent it's better to give people enough rope to tie themselves up and have fun^H^H^Hproblems, better to have completeness, than to have something incomplete where people spend ages publishing weird workarounds that end up even more tangled. The full-powered :has() pseudo-class is in the Complete profile, so browsers should implement and expose it to JS. The problem with "giving people enough rope to hang themselves" is when the mere existence of the feature slows down or complexifies the engine as a whole, regardless of whether it's used. ~TJ
Received on Wednesday, 11 February 2015 22:48:33 UTC