The discussion centers on a Google-led project providing coding agent skills to use modern web primitives, sparking intense debate over whether it promotes healthy innovation or dangerous Chrome monoculture. While some users appreciate the guidance for reducing legacy code bloat, others criticize the initiative as biased toward Chrome-specific features that lack broad browser support.
145 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4WebKit
standards-positions
Python2023–2026
WebKit / standards-positions
standards-positions
WebKit's positions on emerging web specifications
35Distinct people
52Mentions
0Explicit recommenders
339GitHub stars
What to know before exploring
What it is
WebKit's positions on emerging web specifications
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- mozilla/standards-positions · linked in 22 of the same discussions
- w3ctag/design-reviews · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:01:12 PM UTC.
Mentions over time
HN mentions by year52 dated mentions
Observed mentions: 2023-05-24 07:40:19 UTC to 2026-09-16 16:25:35 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 12 | 2 | 10 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 18 | 0 | 18 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 10 | 1 | 9 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
WebKit's positions on emerging web specifications
What is this Repository?
The WebKit Open Source Project uses this GitHub repository to come to consensus on various web specification proposals. We do this through issues in this repository.
Please file an issue if you'd like us to generate a position on some web-facing API.
For an overview of (settled) positions, see webkit.org's Standards Positions. For positions that pre-date this repository, see the webkit-dev mailing list archives.
Possible positions
Only once a label is assigned to an issue does it represent WebKit's position.
Individual responses to issues do not represent WebKit's position on a specification or feature thereof.
Positions are not final. We are happy to revisit positions as new information becomes available.
support - WebKit sees this specification as conceptually good, and worth prototyping, getting feedback on its value, and iterating.
neutral - WebKit does not see this specification as harmful, but is not convinced that it is a good approach or worth working on.
oppose - WebKit considers this specification to be harmful in its current state.
Note that positions on this repository do not reflect implementation status. We might like something we do not get around to implement for one reason or another. And we might dislike something we nevertheless have to implement.
Other possible issue states
proposal withdrawn - This specification is no longer being developed.
blocked - Assigning a position is blocked on issues identified with this specification.
duplicate - The issue is a duplicate of another issue.
invalid - The issue is not about a specification that would be implemented in a browser engine such as WebKit (including its dependencies).
meta - The issue is about this repository.
Resolving an issue with a position
Reviewing proposals is always encouraged and as such please leave feedback and add relevant labels to issues.
To add a "position: X" label where X is one of the positions documented above, please follow this simple process so there is opportunity for WebKit-at-large to reflect and chime in as needed. As WebKit consists of many individuals across companies and timezones some asynchronicity is desirable.
Leave a comment with your suggested "position: X" label, rationale (as needed), and a deadline for further feedback that’s at least 7 days in the future. Depending on the time of year or complexity of the item under review you might want to prolong this.
After the deadline has passed, if there were no requests for more time, no objections, and ideally you had some support through thumbs up or comments with additional context, your suggested "position: X" label can be added.
You did it! 🎉
Read the full README on GitHubWhat Hacker News says
18 sources> Jim once again you are jumping in to defend Apple no matter what the topic is. It’s a really strange behaviour yet again.
Is it possible for you to respond to me without personal attacks? This is the second time this week you have decided it’s appropriate to call me weird.
I have not misread anything. Web USB and Web Bluetooth are not web standards.
> This specification was published by the Web Bluetooth Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
— https://webbluetoothcg.github.io/web-bluetooth/
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
— https://wicg.github.io/webusb/
The specifications literally tell you they aren’t standards.
They have been rejected by both Mozilla and WebKit:
> This API provides
Read the rest
access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature makes it impossible to clearly evaluate. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted to only rely on user consent, which we believe is not sufficient protection. 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.
— https://mozilla.github.io/standards-positions/#web-bluetooth
> The low-level nature of this API means that it is insecure, has a massive privacy risk, and perhaps most importantly doesn't meet the web platform's device-independence bar.
— https://github.com/WebKit/standards-positions/issues/570#iss...
> Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
— https://mozilla.github.io/standards-positions/#webusb
> We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label. This spec also depends on a specific hardware technology, and enables dependency on specific attached hardware accessories, which risks the device independence of the web; thus concerns: device-independence.
— https://github.com/WebKit/standards-positions/issues/68#issu...
Something isn’t a web standard just because Google decided to publish a specification. No other rendering engine has accepted these specifications.
> I don’t know why you keep glossing over this no matter how many times it has been politely pointed out to you.
I don’t believe anybody has ever said this to me before, let alone repeatedly, let alone politely, but perhaps I am forgetting. Could you refresh my memory? When did this happen?
Curiously, Can I Use says:
> All major browser engines are working on implementing this spec.
However their official positions are absent:
https://github.com/mozilla/standards-positions/issues/1167
https://github.com/WebKit/standards-positions/issues/453
And Firefox’s bug for implementing it has no activity:
https://bugzilla.mozilla.org/show_bug.cgi?id=1981485
And Can I Use’s underlying data doesn’t have this note:
https://github.com/Fyrd/caniuse/blob/fedfb067aceccb2a5edadcc...
So it’s unclear why the Can I Use website is saying that everybody is working on it.
In CSS now has an if() conditional functionDid you manually change the status of those particular things? Because that’s not what I was getting at.
All I did was look at the most common things I know off the top of my head are mistaken for web standards when they are not. I did not review anything else. So if you just changed the status of those things, there’s more fixes you need to make.
For instance, I just took another look, and I saw that BackgroundSync is not marked as non-standard. But Mozilla are negative on it:
> We're concerned that this feature would allow users to be tracked across networks (leaking private information about location and IP address and how they change over time), and that it would allow script execution and resource consumption when it isn't clear to the user that they're interacting with the site. We might reconsider this position given evidence that
Read the rest
these concerns can be safely addressed.
— https://mozilla.github.io/standards-positions/#background-sy...
And Apple have concerns and have not committed to it either:
> Adding concerns: power as generally having activity running in the background is not great for battery life. In my experience as a user of "native" apps this can also be tricky to get right. Sometimes background syncing would have taken place, but the moment you open the app it does another sync and blows away the content you just started to read.
> Adding concerns: privacy as this would allow a website to monitor you switching IP addresses. As the draft notes there also some network attacker leaks due to this, revealing origins that you visit that use this functionality to them.
— https://github.com/WebKit/standards-positions/issues/14
If you look at the spec. it has “Unofficial draft” displayed very prominently all over it, and also states:
> It is not a W3C Standard nor is it on the W3C Standards Track.
— https://wicg.github.io/background-sync/spec/
So again, this seems to be a Blink-only API that only Google have implemented, not standard functionality. How many of these fails are actually just Google doing their own thing with no buy-in from other rendering engines? “PWAscore” is a reasonable thing to build, but “Chromescore” where you measure against all the non-standard things Google have implemented by themselves is not a reasonable thing to build.
Also, you have “Not supported” for push notifications in Safari, but if you check Can I Use, you will see that it works for installed PWAs and is only unavailable to websites you visit. Since the purpose of your site is to score based on PWA support, this should be a success, not a fail.
Personally, I would remove all the non-standard stuff. Not give a big list of standard and non-standard stuff mixed together.
Links on support:
https://github.com/mdn/browser-compat-data/blob/main/manifes... (data integrated into the MDN page I linked)
Chromium: https://chromestatus.com/feature/5662315307335680, implemented on Android from M71 and desktop from M89.
WebKit: standards position is neutral <https://github.com/WebKit/standards-positions/issues/11>, and https://bugs.webkit.org/show_bug.cgi?id=194593 shows plenty of developer interest but doesn’t look to have been touched by Apple.
Firefox: standards position is positive <https://mozilla.github.io/standards-positions/#web-share-tar...>, but https://bugzilla.mozilla.org/show_bug.cgi?id=1476515 has languished.
In What about using rel="share-url" to expose sharing intents?> They are actively working on the standard and Firefox has committed to it.
Mozilla standards position says neutral:
https://mozilla.github.io/standards-positions/#fedcm
Their issue tracker on the subject shows they are interested but have a lot of reservations about the details:
> However, some of our reservations on the initial positive position have not been addressed and some new issues have arisen.
— https://github.com/mozilla/standards-positions/issues/618
Apple had a vague “interested” position over three years ago, with no further detail:
https://github.com/WebKit/standards-positions/issues/309
Have these positions changed?
In Sign in with Google in Chrome- https://github.com/WebKit/standards-positions/issues/309
- https://github.com/mozilla/standards-positions/issues/618
In Sign in with Google in ChromeIt, sadly, seems unrealistic to have that API with cross-browser compatibility.
https://github.com/mozilla/standards-positions/issues/154
https://github.com/WebKit/standards-positions/issues/28
In How to FirefoxI honestly don't understand the arguments Mozilla have against it.
Safari/webkit is positive (though no official stance yet):
https://github.com/WebKit/standards-positions/issues/339#iss...
In Web Translator API> The Chrome team has also asked for formal Standards Positions from both vendors, see the Related links section. The <permission> element is an ongoing topic of discussions with other browsers and we're hoping to standardize it.
I don’t understand this proposal enough to have an opinion yet, but that sure is an interesting way to say both Firefox and WebKit oppose it.
https://github.com/mozilla/standards-positions/issues/908#is...
https://github.com/WebKit/standards-positions/issues/270#iss...
In An origin trial for a new HTML element (2024)This is an interesting set to browse through. I feel genuinely conflicted about the decisions the Webkit team makes: I appreciate that they have a far stricter standard around privacy and security that others do, but also feel like they go too far at times and potentially use those as excuses to keep the web an inferior platform.
As an example, they oppose the ability to attach screenshots to a Progressive Web App manifest for use in an install prompt:
https://github.com/WebKit/standards-positions/issues/49
The stated reason is because the screenshot could be malicious and made to look like native UI. Which... yes, I can't disagree that it could. But that's true of every image on the web. So is it genuine concern or is it a resistance to improving the state of App Store alternatives?
(not that it matters a ton, Safari doesn't even support
Read the rest
those install prompts anyway!)
(Also posted this in the other thread: https://news.ycombinator.com/item?id=44170351)
There is a specification for blocking this:
https://wicg.github.io/private-network-access/
It gained support from WebKit:
https://github.com/WebKit/standards-positions/issues/163
…and Mozilla:
https://github.com/mozilla/standards-positions/issues/143
…and it was trialled in Blink:
https://developer.chrome.com/blog/private-network-access-upd...
Unfortunately, it’s now on hold due to compatibility problems:
https://developer.chrome.com/blog/pna-on-hold
In Covert Web-to-App Tracking via Localhost on AndroidThere is a specification for blocking this:
https://wicg.github.io/private-network-access/
It gained support from WebKit:
https://github.com/WebKit/standards-positions/issues/163
…and Mozilla:
https://github.com/mozilla/standards-positions/issues/143
…and it was trialled in Blink:
https://developer.chrome.com/blog/private-network-access-upd...
Unfortunately, it’s now on hold due to compatibility problems:
https://developer.chrome.com/blog/pna-on-hold
In Covert web-to-app tracking via localhost on AndroidFirefox already has indicated that they approve of the new proposal: https://github.com/mozilla/standards-positions/issues/1060
We're only waiting on Safari now: https://github.com/WebKit/standards-positions/issues/386
In The element can now be customized with CSS> I have a filling they are stubborn for no reason and are not seeing use cases that would make their browser usable.
This is untrue. Privacy and security issues have been raised. Web Serial is not a web standard and cannot become one until Mozilla or Apple sees these issues resolved. Google cannot make this into a web standard unilaterally; standards need consensus.
Here is the Mozilla discussion: https://github.com/mozilla/standards-positions/issues/336
And here is the WebKit discussion: https://github.com/WebKit/standards-positions/issues/199
In I-cant-believe-its-not-webusb: Hacking around lack of WebUSB support in FirefoxWebUSB is not a web standard. It’s a Blink-only API cooked up by Google and rejected by both Mozilla and Apple on privacy and security grounds. It cannot become a web standard without two independent implementations, and Google have failed to convince anybody outside of Google to implement it. Nevertheless, it pops up on various websites as things Firefox and Safari are “failing” to support.
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
— https://wicg.github.io/webusb/
> WebKit declined to implement several APIs, including WebUSB, due to concerns over fingerprinting
> We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the conce
Read the rest
rns: security label.
— https://github.com/WebKit/standards-positions/issues/68
> Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
— https://mozilla.github.io/standards-positions/#webusb
Showing the 15 most recent of 18 sources. Enable JavaScript to search and browse every indexed mention.