[selectors] More intuitive names for selector performance profiles

[dbaron]

@Marat-Tanalin sent an email to www-style saying:

It probably makes sense to change the existing names for the fast (JS, currently “static”) and slow (CSS, currently “dynamic”) selector profiles.

For example, using the “dynamic” term for something CSS-related is confusing given that dynamics is usually related to JS, while “static” in webdev is usually about something where JS is not involved: e.g. “static page” as opposed to a page where JS is used to add some dynamics.

So something like “One-shot” or “One-time” (for the JS-oriented profile) and “Iterative” or “Recursive” (for the CSS-oriented profile) would probably be more intuitive names for selector performance profiles.

[dbaron]

Briefly discussed in today's working group meeting.

[frivoal]

manual vs auto ?

[css-meeting-bot]

The CSS Working Group just discussed renaming selector profiles.

The full IRC log of that discussion

<dauwhe> Topic: renaming selector profiles
<astearns> https://github.com//issues/1694
<dauwhe> astearns: dbaron added the issue, there was some discussion during lunch, but no resolution
<dbaron> github: https://github.com//issues/1694
<dauwhe> ... let's try to put realistic suggestions in the issue

[ewilligers]

Suggestion: 'snapshot' for script, 'tracking' for stylesheet.

[FremyCompany]

static vs live-updated ?

[FremyCompany]

inactive vs reactive ?

[gibson042]

There are some analogous concepts in DOM:

A collection is an object that represents a list of nodes. A collection can be either live or static. Unless otherwise stated, a collection must be live.

If a collection is live, then the attributes and methods on that object must operate on the actual underlying data, not a snapshot of the data.

The obvious static vs. live seems just as bad as static vs. dynamic, but snapshot vs. live works.

[SelenIT]

"Live" for CSS-related profile sounds great to me.

But first of all, I would ask if the "non-live" profile — for just one selector — is really necessary? Limiting the :has() selector to that "non-live" profile effectively makes that selector nearly useless since there are already many other ways to know if one element contains or precedes the other in DOM/JavaScript. What people constantly ask for is adding something like :has() to the live profile, to modify the styling of the container based on the content without resorting to scripting. Yes, that selector wouldn't be the fast one, but we already have several selectors depending on the nested or following elements (:empty, :nth-last-*, :focus-within). And it has always been up to the author to decide if the resulting performance is acceptable or not.

I believe that the most use cases for :has(), once it gets implemented, would be relatively simple (something like label:has([type="checkbox"]:checked)) and the resulting performance wouldn't differ too much from the performance of the existing selectors.

Wasn't the whole concept of "non-live" selector profile a kind of premature optimization that was relevant in the era of slower CSS engines, but isn't very helpful in our days when the performance of CSS selectors is usually negligible (comparing to other parts of the rendering process)? Wouldn't it be better to drop it at all rather that to rename it?

[Loirooriol]

@SelenIT Of course lots of people would love :has() in the live profile. But I disagree that having it only in the non-live profile is useless, as proven by the widely-used selector-based JS libraries like jQuery.

You mention other selectors which depend on nested or following elements. An implementator would know better than me, but I'm not sure these are that expensive. For :focus-within you only need to set flags to the ancestor elements when focus changes, then :focus-within matches if the flag is set on that element (e.g. see Firefox's implementation). :empty should also be easy, you only need to know if the element has some child node, and in most cases the engine will know this. Browsers usually render content in chunks, so presumably the problem is when the current chunk ends just after the start tag of the element, in this case the next chunk might add a child, but this only requires recalculating the styles of a single element, there is no subtree to be updated. :nth-last-* seems more complex, I don't know what browsers do but I guess they use some trick to avoid big performance impacts in most cases.

What I mean is that it can be reasonable to add some specific selectors to the live profile even if they depend on nested or following elements, but :has() covers the general case and thus is so hard to optimize. It might eventually be possible to add :has() to the live profile (maybe imposing some restrictions to its argument?), but meanwhile I think it's good that :has() in JS is not held back.

[tabatkins]

But I disagree that having it only in the non-live profile is useless, as proven by the widely-used selector-based JS libraries like jQuery.

Yup, I used :has() a lot back when I was using jQuery. It's quite useful!

:nth-last-* seems more complex, I don't know what browsers do but I guess they use some trick to avoid big performance impacts in most cases.

Mostly it's just that elements don't tend to have very many siblings, so recomputing isn't too expensive. This is not the case for descendants, which elements often have a lot of (and some obvious use-cases for :has() involve using it on the body element...)

It might eventually be possible to add :has() to the live profile (maybe imposing some restrictions to its argument?)

It's been suggested (and vaguely approved of by bz, as in he said it wasn't obviously horrible) to have something like :has-following-siblings() or :has-children(), because it's relatively constrained in how much it has to evaluate and how far up the tree it can invalidate.

but meanwhile I think it's good that :has() in JS is not held back.

Yup!

[SelenIT]

but meanwhile I think it's good that :has() in JS is not held back

Wait, isnt't it? I've been pretty sure it is held back by implementors (at least, according to the MDN's compatibility table). I suppose it might be because browser vendors aren't very interested in implementing it because the same result in JS can already be achieved with existing tools (including Selector API — for .something:has(.somethingElse), either by selecting all .something .somethingElse entries and then looking up the chain of ancestors or by selecting all .something elements and then filtering them with element.querySelector('.somethingElse'), like jQuery does). The current proposal has been there since 2014, but the best vendor response I've seen so far was "Under consideration with Priority: low" from Microsoft (please correct me if I missed something).

I didn't mean that the functionality of :has() selector in JS is completely useless itself, I just supposed that implementors aren't very interested in implementing it because the limited use of this feature doesn't seem to be worth the effort to them. But I hope this could change if this limitation goes or significantly relaxes.

I like the idea of separate :has-following-siblings() and :has-children() selectors (or something similar). Probably it would be a good starting point to add this functionality to CSS.

[fantasai]

Agenda+ to consider the latest suggestion, in #1694 (comment) ; add a comment if there are other suggestions you think we should consider. :)