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, 10:01:16 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
10 sourcesIt is rare that someone voluntarily exposes their lack of insight and integrity so thoroughly... Kudos..?
your argument amounts to "this person is incapable of being objective, let alone decent, because they work at xyz". Moreover, you literally didn't address a single thing presented in either link that i shared - which directly refute your nonsense. Pure ad hominem, and worse.
You are not a serious person if you think that PWA installation is "simple and idiomatic on iOS". It is buried multiple menus, taps, drags etc... deep. Most chromium browsers present a button right in the address bar or at least conspicuously in the main menu. Moreover, they allow developers to ask for the ability to prompt users to install the app.
https://adactio.com/journal/18252
https://adactio.com/journal/22757
Apple forces their employees to debase themselve
Read the rest
s in order to defend this status quo. eg:
https://github.com/w3ctag/design-reviews/issues/1245
https://github.com/WebKit/standards-positions/issues/619
Take care. And keep that math not mathing!
The Apple standard-positions in this was a pretty good read, noting indeed that this is a parallel new way to define accessibility.
https://github.com/WebKit/standards-positions/issues/670
I'd also throw in schema.org Potential Actions as longstanding precedent for declaring what is on offer from the page. https://schema.org/docs/actions.html
It does get a bit tricky though. WebMCP allows the page to respond to the agent. Where-as these other systems the page itself has to update and respond.
In WebMCP: Teaching Your Website to Talk to AI AgentsI really like the general idea of webmcp. The apple position was a remarkable read though, wow!
https://github.com/WebKit/standards-positions/issues/670#iss...
There's some real fundamental things they say that I also strongly agree with. exposeTo for example seems heniously biased. But I really resonated & was energized about webmcp not specifying the actual communication protocol:
> Despite the name, the spec "does not prescribe the format in which tools are exposed" and says browsers may expose them "via Model Context Protocol, other proprietary 'function calling' methods, or any other way." So this is not really an MCP binding: it is a general mechanism for a page to register typed, callable functions for an external caller, not limited to forms or even to AI,
In WebMCP Registry – a public index for WebMCP tool contractsWebKit position stated as opposed to WebMCP
2 points · Open discussionAs far as I can see out-of-order streaming is only half the described functionality – there is also HTML streaming & revamped DOM parsing which does not have the positive signals that out-of-order streaming does:
https://github.com/mozilla/standards-positions/issues/1370
https://github.com/WebKit/standards-positions/issues/629
In API proposed by Chrome: Declarative partial updatesWhen you have questions like this, the best places to check are the "standards positions" Github repositories for Mozilla and WebKit.
https://github.com/mozilla/standards-positions/issues/1369
Mozilla hasn't officially weighed in, but one decision maker (hsivonen) did vote in favor of it.
Apple WebKit is officially in favor of it, as of just a few days ago.
https://github.com/WebKit/standards-positions/issues/628
In API proposed by Chrome: Declarative partial updates> AFAICT, this is a web standard and expected to get buy in from Safari and Firefox before shipping to users.
If it hasn’t already got buy in then it isn’t a web standard, it’s just a Google proposal. Something isn’t automatically a web standard just because Google thinks it’s a good idea.
Here are Mozilla and WebKit positions on this:
> This proposal attempts to solve multiple problems with a single solution. We (Mozilla) recognize the motivation for solving some of the problems, but believe that this is not the right solution to each problem, or in some case a step in the wrong direction.
— https://github.com/mozilla/standards-positions/issues/1076
— https://github.com/WebKit/standards-positions/issues/630
As far as I can see, nobody outside of Google has committed to implementing this.
In HTML-in-Canvas DemosI can't speak for "you guys" anymore, as I'm retired, but from my personal perspective/recollection:
The target usage for the prompt API is anything that would benefit from the general capabilities of a language model, and can't be encompassed by the more-specific APIs for summarization/writing/rewriting. Realistic use cases currently are things like sentiment analysis, keyword extraction, etc. I have a number of ideas on how to integrate it into my current retirement project around Japanese flashcards, e.g. generating example sentences. If the small (~10 GiB) model class keeps getting smarter, the class of things possible on-device in this way gets larger and larger over time.
We definitely communicated with other browsers. There were the standing WebML Community Group meetings at the W3C every few weeks. There were async discussions lik
Read the rest
e https://github.com/mozilla/standards-positions/issues/1213 and https://github.com/WebKit/standards-positions/issues/495 . (Side note, I love the contrast between Mozilla's helpful in-depth feedback and WebKit's... less helpful feedback.) There was also a bit of a debacle where the W3C Technical Architecture Group tried to give "feedback" but the feedback ended up being AI-generated slop... https://github.com/w3ctag/design-reviews/issues/1093 .
But overall, yeah, the goal with the prompt API, as with all web APIs, is to put something out there for discussion as early as possible, and get input from the broad community, especially including other browsers, to see if it's something that they are interested in collaborating on. https://www.chromium.org/blink/guidelines/web-platform-chang... (which I also wrote) goes into how the Chromium project thinks about such collaboration in general.
For now, but accepted and planned for future releases by both Safari (https://github.com/WebKit/standards-positions/issues/160) & Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1882979).
In Dictionary Compression is finally here, and it's ridiculously goodExactly, as sites start using this new tag users will see this breaking in the other browsers who will then be "pushed" into the Google way.
The line about being open to feedback while they're encouraging sites to start building using this really feels disingenuous. At least they could own their choice that they want to go it alone on this.
we're planning to push ahead with our implementation in Chromium, continuing to iterate with your feedback in mind.
https://github.com/WebKit/standards-positions/issues/545#iss...
In The HTML Element