No, I haven't. But I'm assuming it is based on the "right to left" concept while you are assuming it isn't based on browsers' ability to optimize this. The spec

No, I haven't. But I'm assuming it is based on the "right to left" concept while you are assuming it isn't based on browsers' ability to optimize this. The spec says nothing about it and I have never seen any documentation saying "this case will be optimized." And this is the problem with it, imho. Why would this be optimized but not .cls :has(.foo) .bar? Is :nth-child optimized? Should I do [attr]:nth-child or :nth-child:is([attr])? There are several ways to write the same complex selector and a lack of first-party guidelines about the best way to do it. Edit: to illustrate my point better, it used to be that if you wanted to make a table with alternating row colors you just used a class on each row. Then :nth-child(odd) and :nth-child(even) came out and everyone was like "just use that instead! No more classes in every row!" And now we have .foo-table :nth-child(odd) > td because obviously there's a tbody/thead/tfoot between tr and table and nobody knows if you should do this or .foo-table > :is(thead, tfoot, tbody) > :nth-child(odd) > td or which one is faster or if you should just use .odd > td because HTML TABLES ARE THE REAL EVIL TABLES IN WEB HISTORY. CSS TABLES WERE SAINTS COMPARED TO THIS. Anyway, every browser has different optimizations, and I have 5 different ways to make a row color alternate. This is the problem. When we have actual complex styling that makes use of the most powerful CSS selectors, all common optimization for simple stuff fall apart. So why even use powerful CSS selectors when they have potential to be permanently slow on HTML code that you may not ever be able to change in the future?