Re: [selectors] Previous-sibling combinator?

On 2/11/15 2:47 PM, Tab Atkins Jr. wrote:
> 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.

Can you explain this? Why is that the case?

Benjamin

Received on Wednesday, 11 February 2015 22:54:45 UTC