- From: Xidorn Quan <quanxunzhen@gmail.com>
- Date: Mon, 9 Sep 2013 09:21:59 +0800
- 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