W3C home > Mailing lists > Public > www-style@w3.org > February 2015

Re: [selectors] Previous-sibling combinator?

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>
Message-ID: <20150211174324.27a9f803.liam@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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:01 UTC