> Unlike other selectors, :has pseudo class gives a way to apply a style rule to preceding elements (preceding siblings / ancestors / preceding siblings of ancestors) of a certain elements.
> This difference is attractive to web developers, but also it generates lots of concerns mainly about performance and complexity. So there have been discussion about these over the years, but it was difficult to get those discussion moving forward.
> It is true that it can generate performance issues and complex cases. But it is also true that there have been clear demands for the usage.
> We thought that, clarifying those concerns would be helpful for the discussion. So we started to check feasibility on blink, and were able to get some meaningful and reasonable results from this step. Based on the results, we are going to move forward by prototyping.
Right now the estimate is that they can ship in Chrome 105, but this still in advance. I often hear Safari-defenders say their browser is faster, that Chrome is bloated, and I think this is a great case demonstrating an opposite direction, showing a Chrome that is very focused on making sure the web stays healthy & doesn't have pitfalls & doesn't accidentally get slow.
But Chrome is willing to play ball, has acknowledged the lack of this feature hurts, and has come around & tried to meet developer desire, rather than stay fast, & has followed what Safari has pushed for.
Roberto, I had a really frustrating & negative time dealing with your pro-Safari anti-Chrome skepticisms[1] yesterday, which I felt were aimed primarily at snubbing & shorting. I hope if we engage again this time we can have a more earnest & forthright discourse.
Has Safari pushed for it? Or is it simply that Google is slow to adopt the spec? If Safari is faster with features than Chrome is without, maybe it’s Chrome that’s the problem, and we shouldn’t let it hold back the web.
It comes from Safari. No one else advocated for it. Firefox hasn't registered a position on it, has nothing underway.
> Google is slow
> Safari is faster with features
> maybe it’s Chrome that’s the problem?
Again you seem to be slanting everything very highly. And using endlessless questions? This is really some dogshit disingenuous debating, that looks like the dissembling crap you pulled yesterday. Please sir, man up & quit this crap.
What makes you think Apple created it? It’s been in the draft spec for four years. Google’s been working on it for a year at least. But Apple did get it first and now we’re waiting on Google.
According to still-current PRs[1], :has() psuedo-selector is optional and at risk. The working group then noted "no one has figured out how to do it in a performant way," and there's still no clear evidence this capability will indeed be safe & free of pitfalls in any browser (and plenty of counter-evidence against). But Safari is implementing (risking performance pitfalls), & Chrome has decided that the risk of killing performance is an acceptable trade-off for the feature. They began some very early prototyping a year ago, to explore[2].
> It’s been in the draft spec for four years.
First, that's a draft spec. Not published. Safari typically doesn't even start implementing until features are published, so this is all pretty different than where we normally are.
Second, it's been in draft for >8 years[3]. It's barely been touched or worked on. It's a huge scary dangerous feature, that Apple has pushed, only recently. But you're right: I don't think Apple created it. I'm not sure where the suggestion came from; a Google editor wrote it initially but that doesn't mean it was their idea.
I think it's misrepresentative to state this as a clear & surefire win. To keep score over a matter of months for a standard which is risky, in draft, and has been outstanding for 8 years seems like a high definition of petty scorekeeping. Trying to portray this like a real win is for-sure too-soon & risking bullshit. We don't even know that delivering it is going to actually be ok: it's still at risk, we might find it is as dangerous as Chrome said, csswg might remove it from the draft.
> “At-risk” is a W3C Process term-of-art, and does not necessarily imply that the feature is in danger of being dropped or delayed.
And your “that no one has figured out how” quote is from three years ago, and was followed by “If a browser figures out how to do it we'd be happy”
So, sounds like Safari has figured out a way and is pushing the web forward. That’s good, right? Or is it only good when Google wants a browser to have access to serial devices?
Incorrectly confident without reservation, undermining in mis-truthful ways. Again. This is not playing straight, & is taking too much rope.
Google's warning in their Intent to Ship[1] is still clear:
> Ergonomics risks: Authors can easily increase complexity of selector query or style invalidation by using ':has()' pseudo classes.
This could still fail. Safari hasn't "figured out a way to do it." (And their implementation is significantly less complete at that.) They're taking a gamble, a bet, that this feature will be Good-Enough and Not-Too-Bad. This bet could hurt the web badly. We should not jump to conclusions on this. You are counting the chickens before they hatch. Again, to seek to award points here, to say either company is doing better: it seems a misdeed (the releases are, relatively speaking, very near each other) and premature (this could be a fast or slow catastrophe).
I feel like you continue to play up bad side of Brandolini's Law[2], which I had hoped we could avoid tonight unlike last night. "The amount of energy needed to refute bullshit is an order of magnitude larger than is needed to produce it." You have some ok-ish areas of inquiry, but they're always intricately inter-woven with hyper-politization point-scoring sabotage. The question establishes legitemacy, then the nails of doubt & questioning shatter any established said facts: this is not to understand, it's to spread confusion/doubt. Never have you acknowledged a single point said, only spread more doubt.
But not when Chrome does it, right? Not when Chrome implements an avalanche of non-standards from incomplete pre-draft specs authored by no one else but Google? Then it's "pushing the web forward" and it's the "backwards Safari that is holding the web back"?
Chrome has an incredibly responsible practice, of reporting well ahead of time their "Intent to Experiment" & "Intent to Prototype". (Safari just drops festures.) Chrome runs Origin Trials so prpblems can be found & developers understand they are using experimental, liable to change features. Chrome engages the TAG & security folk actively as they're working. It files requests for position. Chrome wants & believes in an alive standards making process, in advancing, carefully, cautiously.
People do push back against changes sometimes on Chrome. And sometimes they get plowed over & ignored. But damn is it rare. Really really rare. The community is extremely open to debate & critiques, is ultra-public, ewth foredes ribed planning & accountability & transparency far surpassing any other software development effort on the planet.
Backwards Safari holds the web back, yes, 100%, but risks like :has() are not to what Im talking about when I say that. This thread was trying to mamipulatively shade on Google for not going fast on one specific feature, and I've been explaining how this specific situation is very complex. I'm glad Safari pushed for it, even though it is a hazard, this is not Safari holding the web back (although it should be regarded as an experimental feature at this point), but this mini PR-campaign to shine up Safari & berate chrome: it's disingenously ommited & talked around a lot of problematic details about this 8 year old drafted idea.
> Chrome wants & believes in an alive standards making process, in advancing, carefully, cautiously.
Ah yes. Carefully and cautiously as in: shipping 400 new Web APIs a year with very little to no discussion and dismissing most concerns from other browser implementors.
The rest of your comment is your regular madman rant with zero substance (because you know nothing of substance on this topic)
Dude, again, you could not be speaking more opposed my language. The gang marching against awesome great kick ass work like web bluetooth, web midi, web hid is absurd. These are epically useful & straightforward wins, huge capabilities, and this hemming & hawing & wringing of hands could not come off as more misguided & consevative & close-minded. But that wasnt even the case here, it was just... we dont get it. And you showed up in the thread & went off? Railed unreasonably?
Someome had to come & add, fill in the half dozen process events you ignored when you ultra-rudely came into the thread to piss all the situation. You are not hurting chrome by citing tbis, you are demonstrating your own axe grinding intempernace & hostile volatility.
Would you please stop posting flamewar comments to HN? It's not what this site is for, and it destroys what it is for. I don't want to ban you, but this has been a problem repeatedly in the past and we've had to ask you to stop more than once. Please really stop doing this, regardless of how strongly you feel about web browsers. You can make your substantive points thoughtfully if you want to, so please do that instead.
> The gang marching against awesome great kick ass work like web bluetooth, web midi, web hid
"The gang". "Marching".
> is absurd
1. It's not absurd if you stopped for a second and looked into why Firefox and Safari are opposed
2. I even gave you a link showing how patently false your statements about Google being careful with specs are
> And you showed up in the thread & went off? Railed unreasonably?
I showed up in the thread and showed the timeline of Google being "careful", and "reasonable" and whatever other adjectives you choose to paint them with
> you ignored when you ultra-rudely came into the thread to piss all the situation.
There was nothing ultra rude with me stating the facts.
> you are demonstrating your own axe grinding intempernace & hostile volatility.
Says the only person in this thread slinging vile insults left and right
Please don't break the site guidelines yourself, regardless of how badly another commenter is breaking them or you feel they are. That only makes everything worse.
> Says the only person in this thread slinging vile insults left and right
Maybe? We're both pretty hot here, perhaps; I can ignore that jive. The difference is, I am swinging for progressiveness & growth & possibility. Yes I am anti a lot of what I see. I'm huge anti. I'm anti-fascist, I'm anti-top-down-control, I'm anti-conservative-mindsets, because these things threaten diversity, progress, possibility, & growth. The whole purpose & nature of tech is to enable possibility, to beget enhanceability, & rejecting that is folly. There are many enemies about to letting people do things with computers, alas. (Plenty just need a little more help, some deserve vitriol.)
> 2. I even gave you a link showing how patently false your statements about Google being careful with specs are
That's what I was replying to. Let's sidestep your overreaction there-in & ignoring a vast swarth of evidence about process you just straight up ignored (both times) in that thread, & talk about the spec.
Yes, Mozilla team/present-leader Martin is far far far less willing to entertain any possible "risk," here & more at length in WebUSB[1]. Fear that devices might not want to be accessible, to me, reads more like propaganda against the Hacker spirit & creativity, bends to the corporation owning our devices & not us. We do need to shield users, but shielding users absolutely from any possibility, to save them from a couple possibly risky possibilities, is a damned & infernal decision. Alas Mozilla/Martin not only make a harsh & greatly constraining decision readily, they make this decision lightly & without any interest in remedy, show no interest in exploring possibility.
Martin's complaint in WebUSB seems to revolve entirely around imagining that it'll be hard to update a blocklist to access usb-bluetooth (and potentially other high security devices) devices:
> This proposal also uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a significant risk to users and their devices
For one, I'm not even sure why we'd want to block access to bluetooth devices. If a user wants to go to a webpage that tries to act like a bluetooth sniffer (or something far more prosaic), & give the page permission to use their bluetooth devices, I don't think that's unreasonable or should be prohibited. But let's grant that mid-level bluetooth interfacing is just too much freedom to handle. There's still nearly zero evidence this blocklist has been hard to maintain. Google has required scant updates. The concerns Martin projects haven't panned out yet: vanishingly few cases of abuse, and the blocklist has required nearly no tending to. Even though the most popular browser on the planet has shipped this feature for half a decade now. As a recent-ish comment says:
> The discussion here seems to mostly be around vague concerns that have not been proven to be problematic [in the half-decade since it got shipped].
I find the Mozilla positions here to be immoral & indefensible, especially as they stand without any suggestion of remedy. Denial of possibility, without suggestion or willingness to progress, is an anethema, & Mozilla has been unwilling to demonstrate any buy in, hasn't shown any interest in helping progress things. Their pretenses of security-mindedness are damaging & detrimental, & out of touch, inflexible, and haven't changed across half-a-decade of evidence stacked against them. Denying WebUSB & WebHID is a tragedy, firewalls off the web from essential & basic computing that it ought be able to involve itself with, & that is used to enormously good effect, such as the schoolchildren's ability to work with their BBC:MicroBit[2] with whatever computer they have about.
I'm sorry it's like this- I wish there were healthier engagement on all sides- but the harsh descriptions I keep using are deserved. Mozilla and Safari seem to have "ganged" up, & have a campaign "marching" against growing the web. I'm not sure where to go find the links, but like ~2 years ago there was a big series of blog posts by Apple and Mozilla proudly advertising that they were rejecting many features like Battery sensors, Ambient Light sensors... I get that a lot of people don't think this stuff is valuable, that it's trendy to want a minimalist web. But this conservative software ideology[3] isn't about helping people. It's about jumping on a bandwagon, about being vile and nasty. There's no evidence these company's are interested or willing to talk about what we could to offer elevated capabilities, to make maybe PWA's for example get access to these capabilities. It's a party of haters (and astroturfed covert App-Store interests). Yes, I do keep being a bit strong in my accusations, because these people are doing bad, & uncompromisingly so.
:has() is actually useful, Chrome pushes features that are largely a waste.