It's especially useful for blocking ads or unwanted elements of a website that has cryptic and ever-changing IDs and classes. With the :has() selector, you can now block an element by its structure, instead of IDs or classes. Some of my personal uBlock filters that might be useful for others:
! Hide question suggestions
www.quora.com##div.qu-borderAll:has(div:has-text(/^Questions for you$/))
! Hide space suggestions
www.quora.com##div.qu-borderAll:has(div:has-text(/^Discover New Spaces$/))
! Hide 1) left nav bar, 2) footer (clap, comment), 3) right side bar
medium.com##div:has(> nav)
medium.com##div:has(> div:has(> article)) ~ div:last-child
medium.com##div:has(> div:has(> div:has(> div:has(> a[href^="https://help.medium.com"]))))
! Hide non-relevant seach results
www.youtube.com##ytd-search ytd-shelf-renderer:has(h2:has-text(People also watched))
www.youtube.com##ytd-search ytd-shelf-renderer:has(h2:has-text(For you))
www.youtube.com##ytd-search ytd-shelf-renderer:has(h2:has-text(Previously watched))
www.youtube.com##ytd-search ytd-shelf-renderer:has(h2:has-text(Results for similar searches))
www.youtube.com##ytd-search ytd-shelf-renderer:has(h2:has-text(New for you))
! Hide unused buttons (useful for vertical monitors)
www.youtube.com##ytd-toggle-button-renderer:has(yt-formatted-string:has-text(Dislike))
www.youtube.com##ytd-button-renderer:has(yt-formatted-string:has-text(Share))
www.youtube.com##ytd-button-renderer:has(yt-formatted-string:has-text(Thanks))
www.youtube.com##ytd-button-renderer:has(yt-formatted-string:has-text(Clip))
I used ublock origin for removing recommendations and trending topics on sites like twitter, but it never occured to me how easy I can create them using has().
I think :has() is probably the most anticipated addition to CSS 25 years (although rounded corners is probably also up there). I’m really looking forward to being able to use it. However it’s almost a shame it took so long, I’m not sure how it will fit in with utility class frameworks that are so in vogue. It’s much more closely aligned with the traditional separation of concerns.
Also very happy to see Apple and the Safari team push web standards forward!
Rounded corners really were all the rage for a while and we needed support for it! I remember in the early days cobbling together elements with top-left, top-right, etc image slices. Want't really too long ago.. maybe 10 years?
I remember in the late 90s building content boxes with 3x3 tables, outer cells containing image slices for the border, drop shadow and rounded corners. Macromedia Fireworks had brilliant tools for both creating these sort of graphics, but also slicing them up for use in tables. I still miss Fireworks, Adobe killed it though as they perceived that it competed with Photoshop when it really didn’t. It’s the spiritual precursor to all ui/ux design tools like Figma and Sketch.
I am referring to the image slicing technique and rendering fancy buttons and sidebar "blocks" using tables in the likes of PHP-Nuke and other content management systems of the time.
> I remember in the early days cobbling together elements with top-left, top-right, etc image slices. Want't really too long ago.. maybe 10 years?
To me this is core ajax and php era, so ~2002-2006 which would be about 18 years ago.
By the time CSS standards for rounding corners arrived a lot of pain has been inflicted on us developers, but by now it feels as if this era never existed (same with pre/post flex to take another CSS milestone)
Preprocessors and CSS methodologies essentially solved that problem already. Container queries are nice, but :has() gives developers novel functionality to CSS that wasn't possible before without JavaScript and DOM traversal.
Is it possible you are confusing container queries with something else? I don't think preprocessors and/or CSS methodologies have anything to do with that. I don't see any way they could solve the problem that container queries are tackling. At least not without JavaScript. But I'm more than eager to learn that I'm wrong about that.
Functional classes with pre-established breakpoints solve a lot of the problem that container queries are tackling. It's a nice feature set, but it wasn't impossible to do before, unless I am misunderstanding something.
It's already in Chrome Beta meaning "has" will be shipping in Chrome within 1-4 weeks. It's not like Safari are leading with this feature and others are catching up.
Leading is when you implement something and no one else as started. Example, Firefox and Chrome shipped WebGL2 and Safari did nothing for 4 years.
When multiple browsers are implementing the same standard at the same time and one ships a couple of weeks earlier that's not leading. Leading implies followers. Maybe in this case Firefox will follow both Chrome and Safari since Firefox has (no "has" support in Firefox Nightly)
> It's not like Safari are leading with this feature and others are catching up.
You seem to be reacting with some anti-WebKit bias here, didn’t read the article about the history of this feature, or are taking a very odd view of “leading” to avoid giving credit to the WebKit team.
The article gives the history, and links you to it:
- eyeo approached Igalia to sponsor work on has:() in early 2021 (Igalia blogged about it May 2021, after having been working on it for a little while)
- Igalia worked on early prototypes to collect data and write tests to drive the conversation around :has() forward
- the WebKit team at Apple picked it up and started doing the hard work of a real and powerful implementation
- they shipped :has() in Safari Technology Preview 137 in December 2021
- they shipped :has() in Safari 15.4 on March 14, 2022
- Igalia did the engineering work to implement :has() in Chromium, which will ship in Chrome 105 on August 30, 2022
- the Chrome issue for :has(), which was created in May, you’ll see it openly references using WebKit’s work and approach
- other browsers built on Chromium won’t be far behind
- Mozilla is currently working on the Firefox implementation
> It's not like Safari are leading with this feature and others are catching up. Leading is when you implement something and no one else as started.
I think, given the timeline and everyone who is actively involved referencing WebKit with the real-world proven and shipped implementation, it’s exactly like that.
> When multiple browsers are implementing the same standard at the same time and one ships a couple of weeks earlier that's not leading. Leading implies followers.
This isn’t a couple-week lag. WebKit has (and continues to) lag in areas—but :has() isn’t one of them, as WebKit is literally the reference implementation here, was in Tech Preview 8 months ago, and has been released in Safari for 5 months. I think it’s fair and accurate to acknowledge that WebKit :has(followers).
I didn’t use the word “leading” or imply they were…
I’m happy that Safari, who have been at times been criticised for not keeping up, are on this occasion helping to push web standards forward. That has nothing to do with who was “first”, but in this case they happen to have been. If they were two weeks behind I would have made the same comment on a thread about a blog post on their own blog.
It's not like Safari are leading with this feature and others are catching up.
With this particular feature, that's exactly what's happening. It's not the first time Apple shipped a new web platform feature before Google and Mozilla; it's the fact that it's been the most highly anticipated CSS feature in the recent history of the web platform.
Leading implies followers.
Apple shipped :has() December 2021 in Safari Technology Preview 137; it's been shipping in production since March 14, 2022 with Safari 15.4. That's a big gap in web time before Chrome ships in production.
thanks! i was just last week looking for what the config might be to turn this on for firefox and didn't find it (didn't try very hard tho).
i tried using firefox's experimental :has() on my personal css framework that's using all the latest features css features like :has(). on first glance, it looks like there are some bugs with firefox, but i'm excited that they're working on it. the simple parent selector case seems to work, but complex layout seems to confuse the layout engine.
:has() is easily my most anticipated css feature since grid at least (wish safari would support subgrid!).
One interesting thing about that Firefox bug is that they support pseudo inside :has() which sounds really useful, but that the currently in-flux spec has just banned that, so they'll have to turn it off.
I think it's noteworthy that feature was pursued and implemented by Igalia, an independent open source dev house whose HQ is in Spain, and is run as a co-operative. They've built up quite a powerhouse of core browser experts.
Why co-ops? Because the profit goes back to the people who work there instead of shareholders, and they get a say in their own management. It shares control of the company between those who work there. It's a much better environment to work in vs something like Activision or EA where you're just an abused cog in the machine.
At least on paper. In reality, the smaller coops don't grow big enough and so can be resourced starved and kinda get stuck in a death spiral as people leave to pursue other alternatives while the remaining members hoard power and control for themselves and make new employees basically not full owners but minions, etc.
There's no perfect system but I'd rather take the risks of equality than work under an oppressive hierarchy.
Not everyone cares about that though. Some would rather earn the big bucks, be led by execs, and not have to worry about the rest of the business.
Igalia shares equal ownership and all new employees are expected to become owners eventually. It's been growing faster too lately. WebKit Team is hiring :)
Because Chrome has such a dominant market share, Safari doesn’t get credit when they implement features first. No one’s going to use or even hear about a Safari-only feature because the people who are making the websites are using Chrome.
On the other hand, if Safari doesn’t support a feature Chrome supports, then that’s a problem for Safari because developers are going to be using that feature.
There’s this sort of naive attitude that “all browsers should just implement all the specifications.” But in reality all browsers take a fair amount of leeway with what specifications they implement, what timeline they implement them in, and etc. There are plenty of fundamental differences between engines that effect browser compatibility, that haven’t been addressed for years.
“Safari is behind Chrome” is just way too linear of a narrative. Web compatibility is a patchwork of over a thousand specifications.
See the moribund state of web development from approximately 2003 - 2013 when the web was bound to a monoculture of Internet Explorer. Current the Blink team are running behind both WebKit and Mozilla in meeting the agreed upon goals for interop 2022. https://wpt.fyi/interop-2022
> See the moribund state of web development from approximately 2003 - 2013 when the web was bound to a monoculture of Internet Explorer.
I think that's a bit of an exaggeration/retconning. Between NetCaptor, Maxthon, etc., that's the era that gave us huge innovations: tabbed browsing, popup blockers, ad blocking, site groups, search in the URL bar, and so much more. And CSS, and GeoCities, and streaming video and animated applets/games/Flash...
There was so much innovation going on, the real difficulty was in being able to display your content to your audiences. CanIUse wasn't around then and there were huge incompatibilities between IE, Netscape, Opera, eventually Phoenix, etc.
It wasn't the diversity in engines that allowed innovation, it was the market exploring different features and eventually converging on the ones that people really wanted. If anything, having redundant engines slowed down actual development. IE6 was king for a few short years, and in those few years the web was more stable than it ever was before or since, and content was king instead of engine differences.
For now Chrome has the best of both worlds: market dominance and rapid innovation. They have no meaningful challengers anymore... Firefox/Gecko is dead and WebKit is only a thing because of iOS, and thankfully it at least shares a heritage with Blink.
I think your link proves the opposite point: that the web ecosystem is wasting time on interop instead of actual features. We don't need three renderers that do roughly the same thing, but nothing exactly the same. It was Chrome's hegemony over the last 5-10 years that actually gave us huge leaps in web usability, dev specialization, best practices, and content creation. The real changemaker was making Javascript safe and fast enough that native in-browser programming became a reality.
There is no such thing as web standards in reality, only Blink and WebKit's mostly-compatible implementations. If we could move past that delusion and just converge resources on Blink/V8 and just evolve that, the web would be better off for it.
Google has far too much power over the direction of Blink for any meaningful debate to take place. They have a tendency to steamroll through already and this behavior would no doubt intensify if Blink were the only game in town.
It would have a far better chance of working if the Chrome/Blink team were spun out of Google into a nonprofit that is protected from the financial influence of Google.
Chrome has been doing some terribly shady stuff with Blink whether we look at their various tracking proposals, “portals” which are a blatant attempt at ossifying Google as basically the internet itself, or the extreme standard-stuffing they continue to participate in to ensure no further competitors can pop up.
But beyond that nearly every point you raise here is completely off.
WebKit is superior to Blink, in almost all ways. It’s simply a much better browser and has been for a couple years now. Faster, lighter, and supports nearly everything you need. Every time I’m forced use Chrome, it’s like having to walk through a shady neighborhood - I literally can’t wait to close it. That thing sucks memory and battery in a way no app should, and Googles numerous shady tactics in trying to get you to login so they can avoid your privacy settings is downright hostile.
Leaps in best practices? Is that a joke? Web Components pushed by them is one of the worst things to happen to the web. Half of the standards they’ve pushed are actually regressions.
And again, Chrome is much slower and more bloated. If anything Safari is far better today for delivering a more native experience.
And your last paragraph is very much the kicker. The funny thing is the Safari thing is the only thing keeping Chrome in check. If this is what they’ve tried to get away with with Safari, I don’t understand how you can be advocating for even less competition. Interop is an incredible project that will save developers massive amounts of time, while ensuring we don’t end up with the most privacy invasive and manipulative company of all time controlling the web for the next 1000 years. Thank god for Safari.
PR and development was led by them and it was designed so that they could basically turn the AMP frame into a first class spec so they could capture your activity past the search page.
The browser is the pipe between enterprises and users on the web.
You might want an advertising company to have unilateral control over the shape of that pipe, but some of us feel more comfortable knowing there’s a viable alternative with competing priorities.
webp and lazy loading are so powerful that having to do things without it really feels like IE. The big difference is that IE users for some reason failed to install something better. Safari users are locked in.
Safari supports lazy image loading, which is probably what you want. Just not iFrame lazyloading, which you shouldn’t be using all that much anyway.
It also supports webp, even though I never use it. It’s a Google thing, not widely supported by image editors and which fails to be consistently better than a properly optimized jpeg.
If you thing you need webp try running it through MozJPEG first
MozJPEG is truly magical. My image editor of choice Acorn added it and I've been using it heavily ever since when I want to share a screenshot of reasonable fidelity but would rather it not be 3.8MB.
I would like to see a decent true successor to JPEG which does stuff like alpha channels, but the annoying extend-embrace-extinguish approach Google used with WebP has turned me off of considering it very seriously.
Which won’t open in Photoshop 2021, or your parents notSoSmart TV.
Questions like: will you be able to open them in 20 years, does this version of ImageMagic supports it, are not things I’d want to deal with daily.
Yeah, thanks but no thanks.
Hard to compete with standards with expired patents and equivalent if not better performance when the other side is sponsored by a single company. Especially one not particularly known for long term commitment to their projects.
I don't think webp was ever meant to be an archival format, especially when used lossily. I wouldn't want a dithered blurred png to be the one archived image I have, either.
Typically I've seen webp served at the CDN or client, where a png or jpeg alternative is also available, and where (hopefully) the website owner has the original asset somewhere safe.
Between "now" and "nobody uses webp" anymore, it's still a super useful format to speed up pages for a majority of users. That doesn't mean you should rely on it to be a safe archival medium, but that's not the only consideration.
Of course nobody is going to force you to use that (or really notice if you don't). It's just one image format out of gazillions.
Safari team is really strange with their priorities, most of the time they are dead set on implementing specs last, but every once in a while they decide a feature is important and they implement it faster than everyone else. For example, backdrop-filter was supported in safari way back in 2015, while other browsers added it multiple years later.
I suspect it is the influence internally from other product teams. WebKit is used in so many places within MacOS and iOS, someone recently wrote a blog post looking at the CSS used by Apple, :has() and some other WebKit only css was heavily used.
They are first but it's not like other browsers are far behind, Chrome is already shipping :has, being first for one feature doesn't mean much while you are years behind implementing non controversial features already in other browsers, not even talking about Safari bugs..
It seems so fake... Apple adds "privacy" by crippling their competitors, then turns around and adds a bunch of their own intrusive advertising. They don't care about you, they just want to be the next Google
I love them to an extent. There should be some sort of request API available for temporarily disabling the more stringent media restrictions for a session.
I worked on a media heavy fashion site a few years ago and dealing with Safari not allowing you to dynamically add new audio/video elements with auto play (or to auto play at all in low battery mode) was a real headache. By default it’s great, just offer the option to get permission for experiences that require it.
Auto playing media is not something that should ever be allowed anyway. Apple forcing sites to respect their users is actually a great reason to buy Apple products.
Autoplay on page load, no. But you’re going to severely limit the web experiences available to Safari users (and probably in turn the number of people who use Safari) if you don’t allow some way of getting reasonable consent to auto play media after page load.
Currently most solutions are to load a number of empty audio buffers when the user first clicks and repurpose those for auto playing content later.
If a user has visited a multimedia focused web site (eg: online catwalk show), why not allow them to opt in for that session rather than force them to have a cut down experience?
Because allowing these perfectly reasonable things also means allowing abuse. We can't have nice things because of people who think they can just autoplay random stuff we don't care about while we're trying to concentrate on some text. There is nothing more aggravating than opening a website and having some unexpected loud sound start autoplaying.
I remember a time when this site didn't take the most uncharitable reading of everything all the time.
And yes. Making a streaming application. The CDN that the media is provided through uses cookies to coordinate "side band" metadata. On Safari, there's no way to get at the metadata due to the cookie policy. So, you get the media, but literally no metadata or features associated with it. It's a worse experience for any Safari user and doesn't actually enhance their privacy in any way whatsoever.
The workaround was to get the streaming provider to allow the correlation ID that would normally be conveyed through a cookie to be conveyed through URL parameters instead.
So.. to the extent that I could track you between two sessions, the workaround means I still can. Not that I need to track you, but because I need to correlate two streams between two different servers onto one device.
Many commenters praising this here but parent selectors have been in discussion almost since the creation of CSS and the repeated conclusion has always been that they're a performance nightmare by definition.
The CSS WG spent quite a lot of time and effort deliberating on a standard which wouldn’t have a significant performance impact. They only support a subset of selectors as arguments, to minimize their complexity.
True in the sense that you mean and alao in pure CS theory terms but also the TFA also links to some serious documentation on practical solutions to many real world performance problems and browser codebases have most of the underlying complexity for other less obvious performance issues. E.g. https://github.com/Igalia/explainers/blob/main/css/has/has-s...
Thanks for the deeplink, I should spend some time digging in.
Though as far a pre-existing complexity in modern engines goes: engine performance has regressed (in absolute end-user terms), and engine conplexity is also a barrier to entry for competing/new engines. So this isn't exactly "good".
I love having access to the has() selector as a user for custom CSS on shitty websites. Ad blocker cleaning rules can get a lot better with this selector.
However, for actual CSS, I don't think this is a good idea. You shouldn't need the has() selector if you write your own CSS and HTML.
Why not? The figure example seems like a perfectly valid use-case. How else would you do something like that?
Edit; I actually had a use case were I was building an expanding menu, without JavaScript, it involved a ~ and > selector on a checkbox to get that to work. The :has selector would’ve made it straight forward.
When you use "has()" you can be pretty sure that you also have the context to just use a class name. Using CSS to traverse a tree of elements rather than structure the elements in a way to make your CSS makes sense just feels like backwards design to me. Your CSS should describe how the HTML looks, it shouldn't be trying to figure out what you did to the poor DOM tree to find the right style to apply.
I think the article shows brilliant examples of where that isn’t really possible, and uses where it replaces JavaScript. It also stops you needing to repeat yourself, the figure example for example with your suggestion would need both a class and a caption tag.
Also going back to the roots of CSS, :has() is ideal for semantic markup where you don’t want or need to use excessive class names. Obviously with class heavy frameworks and methodologies that are in vogue :has() is less relevant.
There is more than one way to use CSS.
> Your CSS should describe how the HTML looks
That’s literally what :has() does, based on the structure of the document.
You have a point, but there are cases where designers are doing something like styling CMS output and either don't have the skills or the possibility of doing something like adding classes conditionally to its output. Or perhaps asking a developer something like "Hey, can you add a class to X whenever it contains Y?" involves filing a ticket and waiting patiently for stakeholders to decide if and when it's necessary enough to devote developer resources to.
And at any rate, removing classes and IDs as much as possible and just having a page full of semantic tags is generally a goal for a certain school of web development.
Maybe i’m either misinterpreting you, or misunderstanding the article, but figure:has(figurecaption) perfectly describes a valid DOM tree, it’s not trying to do anything weird. I’m sure it can be abuses, just like anything else.
I disagree, so many times I had to do what the examples show on the article: having component displaying slightly differently based on content. Could be a simple as margins/padding, etc., or even colour based on the designer's choices.
So now, instead of adding class to an element to choose how to display those differences of content, I can just use :has() selector. Thus removing even more design concerns from the HTML back into the CSS where it belongs.
stuff like this really brings us closer to the dream we all had back when we served largely-static content with some scripts thrown in -- of being able to say what we meant in the css and keeping the markup ~semantic~
now that we throw our hands in the air, say “fuck it”, and first&foremost serve “apps”, single-page or not, styled with utility class systems like tailwind, it feels a lot less meaningful to the average poor sap hired to make web frontends
The article gives a few examples where a pseudo-class fits better with how CSS normally works. For example, the selector matches the last item in the selector. With ‘<‘ it would match ‘parent’ in your case.
You can also match descendants of something with the :has() selector. It really is more than a “parent selector”
which matches a link inside a div that also contains bold text. The important part is that 'b' and 'a' can be very different places in the hierachy, they don't need to be same like like a 'b + a' selector.
```css
figure:has(input[type="checkbox"]:checked) figcaption {
/\* if a figure has a checkbox checked,
apply this to its figcaption... \*/
font-size: 90%;
font-style: italic;
margin: 0.6rem 0 0.1rem;
}
```
It looks extremely useful. It’s slightly different to what I imagined a parent selector to be many years ago. When I think of “parent selector” I imagine putting the logic with the sibling and not the parent e.g. “if I’m in a hover state make my parent green, regardless of who/what the parent is”. It’s a small difference that in reality can be achieved with :has and collocating logic higher up but it’s an interesting difference.
:has() can be described as "elements whose children match some selectors". Your expectation would have been (if I understand it correctly) "match elements with some selectors and get their (direct?) parent". Aside from reversing the logic, it seems to me that it is the exact same thing, isn't it? The selector could have been called "children pseudo-class selector" or similar, though.
Personally, I prefer the actual syntax over your expecation. The first thing in the selector are actual elements that will be styled if certain conditions are met. That also matches how the existing pseudo-classes have been applied.
> “if I’m in a hover state make my parent green, regardless of who/what the parent is”
About time, though I wonder what's the impact on performance. I realize these are not the jquery days where most people would write stupid selectors over and over again but nothing is free and I feel it's important have performance in mind even when it seems most of the web don't.
As someone who primarily uses Safari on an 8GB Mac mini and 8GB MBA, I've found there's two things which reliably cause memory to spike.
One is opening the developer tools. Have more than a couple tabs with the dev tools open and I can easily have Safari itself go over 8GB and I start to feel the thrashing when switching between apps and stuff. Closing dev tools for certain tabs when I no longer need them helps.
Two, for whatever reason, is streaming YouTube videos - not playing pre-recorded ones but watching livestreams. I suspect the culprit is actually the chat box but I'm not sure. For now, if I want to watch a YouTube stream for more than a couple minutes, I'll usually pass it to Streamlink which allows me to watch the stream through VLC and bypass the web interface entirely - I don't participate in or care about the chats anyway.
Incidentally, if you open up Activity Monitor and go to the Memory tab, it'll show you how much memory each Safari tab is using… well, sort of. It uses the domain name of the site as the "Process Name," but that's not very useful if you have more than one tab open with a page from the same domain name. I really wish they'd put the full page title and/or URL in there and/or let you switch directly to the offending tab from Activity Monitor.
All that being said… Naturally, Safari is the most well-integrated and performant macOS browser, and it puzzles me why even self-described Mac fans would use anything else for anything other than testing.
I don’t use Safari because it breaks more random stuff on websites than any other browser, has horrible support for WebGL, struggles to render gradient / animated SVG under many circumstances, has a terrible extension ecosystem, and has a lot of random bugs that annoy me. I also have 0 performance problems with browsers because I have the luxury of owning many powerful machines, each with 64gb ram.
Very exciting. I wonder if :focus-within is on its way out as a result of this.
Granted, it would have a lower specificity than, say, .bordered:has(input:focus).
The demo where you can have different themes for your site ws pretty cool. I wonder if this will put even more stuff currently in the realm of js into css.
I still think this is a bad idea, because it leads to parent:child combinatorial explosion.
Instead, try to avoid the need to define styles that way. Learn to rely on the cascade. Pick an authoring style for sizing, margins and paddings and stick to it. I tend to prefer h-margin and v-padding on containers and v-margins and h-padding on content.
I wish Safari developers would spend their valuable time on fixing the horror Safari is. It's literally the new Internet Explorer. If you work on building web apps with complex interactions, animations, etc, you get to hate Safari with all your heart in a very short amount of time.
There are things they've done that are amazing, and which I respect (like JavaScriptCore), but overall Safari is the worst popular browser. I don't get how people can stand it, but again I don't get how people can stand iOS either.
Uhm this is exactly what :has is, fixing the ‘horror’. This is such an outdated idea, the WebKit team have been killing it the past 12-18 months as evidenced by the efforts on interop 2022. https://wpt.fyi/interop-2022
A vanishingly small percentage of the web I make regular use of has any legitimate need for anything beyond what web browsers were capable of 4-6 years ago. In the odd case that I run into a site that’s broken in Safari, I can usually find an alternative that works fine in a few seconds.
What has the biggest impact on me as a user isn’t the quantity of bells and whistles the browser’s engine has, but how efficient it is because nobody likes battery vampire apps and how much the browser tilts the balance of control in favor of the user, because third parties on the web are best treated as adversarial until proven otherwise.
Chrome provides a nice experience for devs, but its user experience continues to slip.
Can you elaborate or is this just an uninformed rant?
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".
With all due respect, it looks to me you're the one sharing an uninformed opinion. Have you seen any benchmarks, tried some? No? Your claims are based on what the authors say. That is not enough. Never has been.
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.
I was neither sharing an opinion nor did I claim anything. I asked OP to elaborate and referred them to content of the article.
> 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.
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.
March 2022 you say? Great. Are there any benchmarks? Nothing fancy, just some 3rd party comparisons to other selectors or combinations. Because that would be preferable to buying myself a safari capable device just to prove point that I wasn't making in the first place
I'm not aware of any benchmarks. Neither am I aware of any performance deterioration in Safari 15.4+.
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.
