- From: Liam R E Quin <liam@w3.org>
- Date: Wed, 11 Feb 2015 17:43:24 -0500
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- 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, 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. > a few members are going to > investigate what level of restriction would be reasonable and will > report back. It is likely, though, that `el:has(>child)` and > `el:has(+sibling)` will end up in the fast profile. Believe, the list > will be notified when we decide on this. +1 -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/
Received on Wednesday, 11 February 2015 22:43:31 UTC