W3C home > Mailing lists > Public > www-style@w3.org > September 2013

Re: [selectors4] Use pesudo-class instead for selecting parent elems

From: Xidorn Quan <quanxunzhen@gmail.com>
Date: Mon, 9 Sep 2013 09:21:59 +0800
Message-ID: <CAMdq6984u8iKVeoc2-7QPTcAiOWgWGophEgB8wyRr_dtJ8HSPQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Simon Sapin <simon.sapin@exyr.org>, www-style list <www-style@w3.org>
On Tue, Sep 3, 2013 at 11:15 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Sep 3, 2013 at 1:24 AM, Simon Sapin <simon.sapin@exyr.org> wrote:
>> Le 03/09/2013 09:15, Simon Sapin a écrit :
>>> Le 03/09/2013 03:00, Xidorn Quan a écrit :
>>>> I believe that :matches which supports complete complex selector is
>>>> hard, if not impossible, to be implemented in a fast way, but it is
>>>> possible for the pseudo-class I requested which narrows the looking-up
>>>> range to its descendents.
>>>
>>> Is it? As far as I understand, the problem here is that a dynamic change
>>> anywhere in the tree, in the presence of such selectors, would require a
>>> big part of the tree or the whole document to be restyled.
>>>
>>> Does your proposal really help with that? Especially (see below) if the
>>> argument to :has() can start with a combinator.
>
> Boris has said before that a restricted form of :has() that only
> selected for children would likely be acceptable from a performance
> standpoint.

It should be possible to relax the restriction to allowing only one
:has() in a complex selector within the performance requirement.

I have to admit first that I don't know how selectors are implemented
now, but a selector with one :has() only requires one more branch to
check, which should not slow down the speed significantly.

>> I should add: I’m not convinced that :has() solves any performance problem,
>> but if it turns out to be equivalent in expressive power to the subject
>> indicator, I like this proposed syntax better. (:has() has no equivalent to
>> multiple subject indicators in the same selector, but I’m not overly
>> attached to that feature.)
>
> It's equivalent, yes.  Depending on what you're doing, it may be more
> or less convenient to express a given selector.

As discussed before, :matches() with arbitrary complex selector inside
is hard to optimize, which completely excludes it from the fast
profile. But as I described above, with a looser limitation, :has()
should not impact the performance a lot.

--
Xidorn Quan
Received on Monday, 9 September 2013 01:23:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2013 01:23:06 UTC