The term was coined by Heydon Pickering [0]. He's great, also responsible for the useful site Inclusive Components [1] and one of the authors of Every Layout [2].
Note that the owl selector is pretty slow when it comes to being processed by browsers. If you use it sparingly, it shouldn't be so bad, but leave it all over the place, and you'll see the impact
Ha, when I first learned about it I remade a pretty interesting navigation menu purely with :not :checked :focused :hover etc, so pure html and css, thinking it would be more performant then my previous JS version.
Its performance was not just measurably worse, it was obvious as soon as I opened the revision on my phone.
Lesson learned: it's important to think twice before using most pseudo selectors
> I remade a pretty interesting navigation menu purely with :not :checked :focused :hover etc, so pure html and css, thinking it would be more performant then my previous JS version.
That sounds so cool! Do you have a version somewhere that I can take a look at? I always like fiddling with clever CSS, even if it is too clever for its own sake, as you managed to find out
And keep in mind, that pseudo selectors are not created equal. Things like :checked or :focused usually don't have that much of a performance impact
it was just a lot more elements in the navigation with subcategories etc, but basically the same methods
(remember to check the mobile view, as thats the one thats using most selectors. Though the desktop view is arguably better)
this recreation is probably very confusing though, as the only hint that there are more links hidden for the category are the missing corners - and there is nothing hinting you have to click the category names to show these hidden options.
and i skimped on proper accessibility for this mockup, so the hidden options can't be selected without touch/mouse
The JS just emulates what opening the page would have done. It was SSR
As I mentioned above - one or two clauses like that won't hurt performance, but I have seen situations, when bad CSS (a lot of *'s, too long selectors, a lot of dead and unused clauses) actually had a measurable impact on websites' performance.
This especially comes into play, if you deal with a lot of nested HTML elements or when you modify the site's HTML a lot.
Is there a place to see css benchmarks on modern browsers, like jsperf used to be for JS?
It seems like > *+*, *:not(first-child), *:nth-child(1+n) and *:last-child { ...revert... } are all equivalent. I would be curious to know which is most efficient.
How can one even test the performance of these selector? I've been have a few pages that feel slow, and have some exotic selectors, but I've no clue what tools to uses. And searches for CSS performance tell me lame things like: minimize and use a CDN. I have the XY problem.
[0] https://alistapart.com/article/axiomatic-css-and-lobotomized...
[1] https://inclusive-components.design
[2] https://every-layout.dev