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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03: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
52 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> 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 ChromeShowing the 15 most recent of 52 sources. Enable JavaScript to search and browse every indexed mention.