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 searched that page and their github repo for "inputmode" (my example from before you posted) and couldn't find anything.
https://github.com/WebKit/standards-positions/issues?q=input...
I'd love to find out if anyone on the webkit project is aware of that part of the standard, and if so, the project's official position on it. I can't imagine why they'd oppose it.
In Is Chrome the New IE? (2023)I mean is there any movement in getting major browsers to adopt this?
Normally when a spec. like this is written that needs adoption from web browsers, an explainer is written and then the major rendering engines are asked for their feedback. For instance, here’s an explainer:
https://github.com/krgovind/first-party-sets
Here’s where WebKit was asked for their position on it:
https://github.com/WebKit/standards-positions/issues/93
Here’s where Mozilla was asked for their position on it:
https://github.com/mozilla/standards-positions/issues/350
Here’s the process Blink goes through to get a new feature like this going:
https://www.chromium.org/blink/launching-features/
I tried to find where this was done for GPC and couldn’t find anything. Did they just write a spec. and not bother doing any of the work involved in getting it adopted? Or i
Read the rest
s there progress being made that I didn’t see? Hence my question: Is there any movement on this at all? Or is the process of getting it adopted by Blink and WebKit at absolute zero?
This was going to be the compromise that would allow Chrome to have a path towards deprecating third-party cookies without massively decreasing its ad revenue, but they've walked away even from that: https://privacysandbox.com/news/privacy-sandbox-update/
> Instead of deprecating third-party cookies, we would introduce a new experience in Chrome that lets people make an informed choice that applies across their web browsing, and they’d be able to adjust that choice at any time. We're discussing this new path with regulators, and will engage with the industry as we roll this out... We'll continue to make the Privacy Sandbox APIs available and invest in them to further improve privacy and utility.
Discussion here: https://news.ycombinator.com/item?id=41038586
There are numerous ways that the Topics API could leak sensitive information (say,
Read the rest
for instance, increased values for a set of topics statistically related to life events with legal/health consequences) - I'm glad that opposition is being highlighted.
Apple's opposition comments are also worth reviewing: https://github.com/WebKit/standards-positions/issues/111
Request for positions on the topics API - https://github.com/WebKit/standards-positions/issues/111 also mentioned in https://github.com/mozilla/standards-positions/issues/622
The Register article on the topics api last year https://www.theregister.com/2023/06/27/google_tweaks_topics_...
In Using the Topics API (Chrome Only, Opposed by Firefox/Safari)Safari (Webkit) is the hold-out on having this: https://caniuse.com/mdn-api_customelementregistry_builtin_el...
The reasoning for choosing not to support it is here: https://github.com/WebKit/standards-positions/issues/97#issu...
In The UX of HTML (2023)> OPFS doesn’t come with graceful handling of concurrency out of the box. Developers should be aware of this and design around it.
There's a multiple readers and writers proposal [0]. It's been "position: positive" by Firefox [1], implemented in Chrome [2], and ignored by Webkit [3] (of course).
0: https://github.com/whatwg/fs/blob/main/proposals/MultipleReadersWriters.md
1: https://github.com/mozilla/standards-positions/issues/861
2: https://chromestatus.com/feature/5172892632875008
3: https://github.com/WebKit/standards-positions/issues/238
Love the shoutout to Roy Hashimoto. He's been writing VFSs for SQLite-on-the-browser and perf testing them. He's recently wrote "IDBMirrorVFS", which "is a new example VFS that keeps all SQLite files in memory while persisting to IndexedDB". It has remarkable performance, of course.
Read the rest
https://github.com/rhashimoto/wa-sqlite/discussions/189
Also, looks like Roy takes advantage of the aforementioned proposal when he wrote `OPFSPermutedVFS`, which takes 2nd pace behind `IDBMirrorVFS` w/r/t perf. https://github.com/rhashimoto/wa-sqlite/blob/master/src/exam...
Safari also has not yet implemented it and they want to wait for it to become stable then implement it.
https://github.com/WebKit/standards-positions/issues/167#iss...
In Flow Charts with CSS Anchor PositioningYou can check why Mozilla and Apple have opted to not support this.
https://github.com/mozilla/standards-positions/issues/154
https://github.com/WebKit/standards-positions/issues/28
Neither Mozilla or Webkit are satisfied that the proposal is safe by default, and contains footguns for the user that can be pretty destructive.
In iOS404Nope, was marked as WONTFIX: https://bugs.webkit.org/show_bug.cgi?id=182671
There was some more discussion in the webkit standards but looks like the answer is still unchanged: https://github.com/WebKit/standards-positions/issues/97
In Show HN: Tiniest Web Component> I think Apple didn't want to do it because it was remotely threatening to their iOS App Store and I wonder if some kind of anti-trust litigation may eventually expose their leadership around webkit like this
What actually happened: Mozilla rejected it on security grounds, then Apple agreed with Mozilla. How are you blaming Apple for Google putting together a bad spec. that no other browser vendor can accept?
This happens time and time again. Google publish a specification that is not acceptable, both Mozilla and Apple reject it on privacy or security grounds, Google ships it in Chrome anyway, then people like you complain about Apple being mean.
Here is Mozilla’s position: https://github.com/mozilla/standards-positions/issues/154
Here is Apple’s position: https://github.com/WebKit/standards-positions/issues/28
In The web just gets better with Interop 2024The new scrollbar styling properties are actually pretty consistent with native platforms. There's not that much flexibility with them - e.g. you can't define width in pixels, you just chose between thick, thin, or none, which match the existing native controls:
https://github.com/WebKit/standards-positions/issues/133#iss...
> To add more information to this issue. This property supports three values, auto, thin and none. These match nicely to WebKit's ScrollbarControlSize::Regular and ScrollbarControlSize::Thin and not rendering the scrollbar.
In The web just gets better with Interop 2024Apple puts their policy positions on GitHub too. It's just where this is done for some reason: https://github.com/WebKit/standards-positions
In Mozilla thinks Apple, Google, Microsoft should play fair