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
12 sourcesI don't know the timeline, but Apple has committed [1] to adding WebTransport support to WebKit.
[1]: https://github.com/WebKit/standards-positions/issues/18#issu...
In Replacing WebRTC: real-time latency with WebTransport and WebCodecsNot yet but one day: https://github.com/WebKit/standards-positions/issues/18#issu...
In quic.video - Live Media over QUICI'm not using them because WebKit (i.e. Apple), in a long-standing vendor pissing contest¹ they've tunnel-vision'd themselves into, still refuses²³ to implement the customized built-in elements⁴ part of the standard, without which the content model for HTML cannot be fully realized (e.g. custom elements inside a table), and to make matters worse, without offering a firm proposal or implementation of an equivalent alternative.
(and this is something a polyfill can only partially bridge)
[1] https://github.com/WICG/webcomponents/issues/509#issuecommen...
[2] https://bugs.webkit.org/show_bug.cgi?id=182671
[3] https://github.com/WebKit/standards-positions/issues/97
[4] https://html.spec.whatwg.org/multipage/custom-elements.html#...
In If Web Components are so great, why am I not using them?I wanted to write some proper feedback on the GitHub repo, but they've closed issues and PRs. Until they open it back up again, here are my thoughts on the spec:
- Mozilla is already publicly and officially opposed (https://github.com/mozilla/standards-positions/issues/852#is...), on principle ("Any browser, server, or publisher that implements common standards is automatically part of the Web") as well as on technical concerns around the safeguards and downsides of the proposal.
- WebKit is not committed to a position, but has mentioned several concerns (https://github.com/WebKit/standards-positions/issues/234):
"We have Private Access Tokens (aka Privacy Pass) for some of the claimed use cases of this spec. We think it's a more privacy-respecting solution. The Explainer isn't very clear on why specifically Web Environment Integrity is b
Read the rest
etter. It mentions a feedback mechanism, but not the specific mechanism. It also exposes more info to the page. The Explainer claims this spec is necessary because Privacy Access Tokens don't support feedback from websites on false positives / false negatives, however, neither the spec nor the explainer include a feedback mechanism. Without more specifics, we would not be enthusiastic about duplicating an existing standards-track solution for the same use cases."
- Vivaldi is clearly opposed, per this blog post.
- Holdback as a mechanism is a weak defense against abuse. Some potential stakeholders are already suggesting to scrap holdback to support their use-cases (https://github.com/RupertBenWiser/Web-Environment-Integrity/...), leading to the possibility that it may not even be part of the final standard. Holdback is not technically enforced: a user agent can choose not to hold back, and if they are sufficiently popular they may induce web site operators to rely on their signal (at least for that browser) which would have the exact "DRM" effect that the proposal claims to avoid. The exact implementation of holdback matters a lot: if it's e.g. per-request, a site can simply ask repeatedly; if it's per-session or per-user, a malicious agent can pretend to be heldback the entire time.
- Since holdback is being touted as essentially the only defense against "DRMing" the web, it's a real mistake to have it be so poorly specified. The way it's currently specified makes it sound more like an afterthought than a serious attempt to mitigate harm.
- Compared to Private Access Tokens, WEI leaks far more information. WEI allows attesters to provide arbitrary metadata in their (signed) attestation verdict, whereas PAT tokens are fully opaque and blindly signed. Furthermore, PAT tokens can be in principle obtained through alternate attestation mechanisms (e.g. captcha, authentication, ...) without leaking the details of how that attestation is performed. WEI does not provide for this, and instead is designed around explicitly validating the "web environment".
WebKit Web Environment Integrity API
2 points · Open discussionA position request was raised in February for both Mozilla[1] and WebKit[2] and neither have been responded to.
[1] https://github.com/mozilla/standards-positions/issues/753
[2] https://github.com/WebKit/standards-positions/issues/142
In Mozilla Standards Positions Opposes Web Integrity API“Topics API or third-party cookies” kinda goes beyond being a false dichotomy to being a blatant lie. The conflict of interest demonstrates how Google is unfit as the custodian of a leading browser. This is a single-vendor thing to bolster their own interests and which they can only do because they’re a leading advertising company, and which no one else supports in any way.
Firefox and Safari have already stopped supporting third-party cookies, and nothing bad happened.
(There are a few cases here and there of legitimate systems breaking due to relying on third-party cookies for things like login, and these have broken in Firefox and Safari, but they’ll break in Chromium too when it kills off third-party cookies, and the Topics API is completely irrelevant to these cases, being exclusively about advertising interests, so these cases aren’
Read the rest
t part of the “third-party cookies or Topics API” deceit.)
Note also how Apple and Mozilla have both taken negative positions on the Topics API: it’s extremely unlikely either’s browser engine will ever support it, making the falseness of the dichotomy even clearer.
Useful further reading, identifying various concrete problems with the Topics API (if “but why should it even exist at all?” wasn’t enough):
https://github.com/WebKit/standards-positions/issues/111
https://github.com/mozilla/standards-positions/issues/622
https://github.com/w3ctag/design-reviews/issues/726
Here are the official standards positions resources for Chrome, Mozilla, and WebKit:
https://chromestatus.com/newfeatures
https://mozilla.github.io/standards-positions/
https://github.com/WebKit/standards-positions
In I post when browser makers announce their intent to ship features in web enginesWebTransport is already available in Chrome, Edge and Firefox[0]. Safari does not have it but that is going to change soon it seems as per [1].
Could have interesting implications for many things. Interesting use case - gRPC might be natively possible in browsers with no HTTP proxies in between.
EDIT: Added link to exact label.
[0] https://caniuse.com/webtransport
[1] https://github.com/WebKit/standards-positions/issues/18#issu...
In WebKit is going to support WebTransportWebKit is going to support WebTransport
2 points · Open discussionhttps://github.com/mozilla/standards-positions/issues/698
https://github.com/WebKit/standards-positions/issues/74
Hmm. I wish some other ones got as warm of a reception as this one.
In Popover API