Re: [selectors] Previous-sibling combinator?

On Thu, 12 Feb 2015 08:24:03 +1100
"Tab Atkins Jr." <> wrote:

> On Thu, Feb 12, 2015 at 7:18 AM, Marat Tanalin <> 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,
Pictures from old books:

Received on Wednesday, 11 February 2015 22:43:31 UTC