I stand corrected. It was the absolute legends at Igalia. See links and explainer here: https://github.com/mozilla/standards-positions/issues/528
In Is Chrome the New IE? (2023)mozilla
standards-positions
HTML2019–2026
mozilla / standards-positions
standards-positions
Discover this repository through its Hacker News conversations.
119Distinct people
192Mentions
2Explicit recommenders
764GitHub stars
What to know before exploring
What it is
A public description has not been verified.
Where it is used
No documented product use was verified in the last source check.
What people are saying
I love firefox except for a fairly recent feature adopted by chrome, which is the ability to update usb device firmware through a web browser via the Web Serial API. I do a lot…
cronix used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- webkit/standards-positions · linked in 22 of the same discussions
- explainers-by-googlers/web-environment-integrity · linked in 4 of the same discussions
- libjxl/jxl-rs · linked in 4 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, 6:01:32 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year192 dated mentions
Observed mentions: 2019-03-13 13:55:54 UTC to 2026-10-18 02:52:23 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 |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 11 | 0 | 11 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 30 | 3 | 27 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 15 | 1 | 14 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 39 | 6 | 33 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 30 | 3 | 27 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 29 | 0 | 29 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 26 | 1 | 25 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Mozilla's Positions on Emerging Web Specifications
See the dashboard for Mozilla's current positions.
What is this Repository?
This repo is where Mozilla decides and documents what it thinks about
emerging technical specifications for the Web. Typically they're draft documents in the
IETF, W3C (including the WICG),
WHATWG, and Ecma TC39, but they could come from
elsewhere too.
Having a clear Mozilla position on these specifications helps us align our thinking and communicate
it clearly to these standards bodies, as well as other browsers.
Implementation status (or even intention) isn't tracked here; see dev-platform.
Possible Specification Positions
We will seek to apply one of three labels to new specifications:
positive - Mozilla regards this work as a potential improvement to the web.
neutral - Mozilla is not convinced of the merits of this work, but does not see any significant negative potential.
negative - Mozilla believes that pursuing this work in its current form would not be good for the web.
These positions will be based on our best assessment of the current state of the specification and
the potential for it to benefit our users and the web as a whole. We consider the intended purpose
and the design fundamentals of each specification. Incomplete documentation, minor issues, or lack of
interoperability testing are not reasons for a negative position, provided that intent is clear.
We might also use the following labels for specifications where we have not formed a position:
defer - Mozilla takes no position on this work.
under consideration - Mozilla has not taken a position on this work and is gathering more information.
What about Firefox?
A position here does not address whether Mozilla will commit resources to developing a
specification. In particular, taking a position does not commit Mozilla to implementing a
specification in Firefox.
Requesting a Position
See our contribution guidelines for information about how you can participate.
Building locally
See DEVELOP.md.
Read the full README on GitHubWhat Hacker News says
30 sources> why would I grant a random news or social media site access to my MiniDisc player, Arduino board, Bluetooth thermometer/hygrometer etc. when it asks for it?
Part of the problem is that a vast number of users neither understand nor care about these prompts. They just click to make them go away.
There’s a few long discussions on the unsuitability of these specifications in the Mozilla standards positions repo:
Web Bluetooth: https://github.com/mozilla/standards-positions/issues/95
Web USB: https://github.com/mozilla/standards-positions/issues/100
Web MIDI: https://github.com/mozilla/standards-positions/issues/58
Web Serial: https://github.com/mozilla/standards-positions/issues/336
Here’s some Hacker News discussion about it: https://news.ycombinator.com/item?id=23679063
In DOJ will push Google to sell off ChromeI 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?
> Frankly put, I think that rule is entirely BS and needs to be completely removed.
That's what Google is essentially doing: they put up a "spec", and then just ship their own implementation, all others be damned.
Here's the most egregious example: WebHID https://github.com/mozilla/standards-positions/issues/459
--- start quote ---
- Asked for position on Dec 1, 2020
- One month later, on Jan 4, 2021, received input: this is not even close to being even a draft for a standard
- Two months later, on March 9, 2021, enabled by default and shipped in Chrome 89, and advertised it as fait accompli on web.dev
- Two more months later: added 2669 lines of text, "hey, there's this "standard" that we enabled by default, so we won't be able to change it since people probably already depend on it, why don't you take a look at it?"
--- end quote ---
Th
Read the rest
e requirement to have at least two independent implementations is there to try and prevent this thing exactly: the barreling through of single-vendor or vendor-specific implementations.
Another good example: Constructible Stylesheets https://github.com/WICG/construct-stylesheets/issues/45
Even though several implementations existed, the API was still in flux, and the spec had a trivially reproduced race condition. Despite that, Google said that their own project needed it and shipped it as is, and they wouldn't revert it.
Of course over the course of several years since then they changed/updated the API to reflect consensus, and fixed the race condition.
Again, the process is supposed to make such behavior rare.
What we have instead is Google shitting all over standards processes and people cheering them on because "moving the web forward" or something.
---
As for WebSQL: I'm also sad it didn't become a standard, but ultimately I came to understand and support Mozilla's position. Short version here: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis... Long story here: https://nolanlawson.com/2014/04/26/web-sql-database-in-memor...
There's no actual specification for SQLite. You could say "fuck it, we ship SQLite", but then... which version? Which features would you have enabled? What would be your upgrade path alongside SQLite? etc.
From "Chrome 130: Direct Sockets API" (2024-09) https://news.ycombinator.com/item?id=41418718 :
> I can understand FF's position on Direct Sockets [...] Without support for Direct Sockets in Firefox, developers have JSONP, HTTP, WebSockets, and WebRTC.
> Typically today, a user must agree to install a package that uses L3 sockets before they're using sockets other than DNS, HTTP, and mDNS. HTTP Signed Exchanges is one way to sign webapps.
But HTTP Signed Exchanges is cancelled, so arbitrary code with sockets if one ad network?
...
> Mozilla's position is that Direct Sockets would be unsafe and inconsiderate given existing cross-origin expectations FWIU: https://github.com/mozilla/standards-positions/issues/431
> Direct Sockets API > Permissions Policy: https://wicg.github.io/direct-sockets/#permissions-policy
> docs/explainer.md >> Secu
Read the rest
rity Considerations :
https://github.com/WICG/direct-sockets/blob/main/docs/explai...
Which part of "is not a w3c standard and not any standards track" do you not understand?
Do you understand that for something to become a standard, it needs two independent implementations? And a consensus on API?
Do you understand that "not on any standards track" means it's Chrome and only Chrome pushing this? That Firefox isn't interested in this either?
Do you understand that blaming Apple for everything is borderline psychotic? And that Chrome implementing something at neck-breaking pace doesn't make it a standard?
Here's Mozilla's extensive analysis and conclusion "harmful" that Google sycophants and Apple haters couldn't care less about: https://github.com/mozilla/standards-positions/issues/431#is...
In Direct Sockets API in Chrome 131I found this issue indicating a bad idea for end user safety:
https://github.com/mozilla/standards-positions/issues/431
In Direct Sockets API in Chrome 131> but didn’t (in my reading) address use of the API as being part of an otherwise essentially trusted app
That’s what the Narrower Applicability section is about <https://github.com/mozilla/standards-positions/issues/431#is...>. It exposes new vulnerabilities because of IP address reuse across networks, and DNS rebinding.
In Direct Sockets API in Chrome 131I don't know if Google has changed their position, but Mozilla is willing to accept a memory-safe (read: Rust) JXL decoder [1].
If it becomes used in Firefox, maybe there's a chance that Google would see the benefit in picking it up?
[1] https://github.com/mozilla/standards-positions/pull/1064
In How JPEG XL compares to other image codecsI was surprised too, cause initially they had some issues with the proposal [1], resolved it few years later [2], and finally implemented it since last year [3]
[1] https://github.com/mozilla/standards-positions/issues/194#is...
[2] https://github.com/mozilla/standards-positions/issues/194#is...
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1753933
In Smarter Than 'Ctrl+F': Linking Directly to Web Page ContentSept. 3rd:
> the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust
https://github.com/mozilla/standards-positions/pull/1064
In JPEG XL in iPhone 16 Pro Yields Incredible ResultsDirect link to the comment on the thread:
https://github.com/mozilla/standards-positions/issues/340#is...
In Mozilla is currently not investing in PWAsMozilla is currently not investing in PWAs (2021)
1 points · Open discussionRequest 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)There is some movement.
Google Research recently committed to help implementing it, in Rust, for inclusion in Firefox.
https://github.com/mozilla/standards-positions/pull/1064: “the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust, and integrate this decoder into Firefox. If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it.”
In JPEG XL: Industry-leading image compression and fidelityShowing the 15 most recent of 30 sources. Enable JavaScript to search and browse every indexed mention.