Re: [selectors] Previous-sibling combinator?

On 2/11/15 2:43 PM, Liam R E Quin 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 problem here is quite different from XQuery.

In this case, matching is not really a problem, it is trivial to 
implement and should not be any slower than what already exists.

The problem is doing efficient style invalidation. You don't want a 
single selector to invalidate giant subtrees every time any of its 
element changes.

>
>> 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
>
>
>

Received on Wednesday, 11 February 2015 22:55:09 UTC