Totally unnecessary feature that will do just harm to slow devices than to move the web forward.
Lazy developers rejoice.
The article that you are commenting on explicitly mentions the focus on performance while considering this feature. They even state to have been able to achieve "fantastic performance, even in the presence of large DOM trees and large numbers of :has() selectors".
The idea is not new at all. People have been asking for something like this for many years. You know why it never happened? Because it would be slow. Maybe the webkit devs have found a really fast and clever way to do it. But shitting on people for voicing their well founded skepticism is not a good sign. Especially when all we have is their word.
> You know why it never happened?
Yes, I do.
> Especially when all we have is their word.
Does that mean you don't trust their word? Good. Would you trust their own benchmark? No? The parent selector has been in Safari 15.4 since March, 2022. So feel free to do your own benchmark. There is not just their word.
You might also find the lengthy explainer of Igalia, where performance is discussed, interesting: https://github.com/Igalia/explainers/tree/main/css/has
Being skeptic is not a bad thing. But (uninformed) criticism without any specifics is far from "well founded skepticism". JavaScript interpreters used to be very slow twenty years ago, now they are extremely fast. That can happen to CSS evaluation, too.
What is your point exactly? That performance should be one of the most important aspects in browser engine development? I agree. Hence, I asked OP to elaborate their claim that this selector harms slow devices. And I'm not interested in the (outdated?) historical concerns of a parent selector. But the actual effect of the specific selector implementation in WebKit which this discussion is about.