Mozilla provided feedback on the text fragments spec: https://github.com/mozilla/standards-positions/issues/194#is...
In Firefox beta supports Apple silicon nativelymozilla
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:59:22 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
12 sources> Mozilla is too busy improving the world instead of their browser and WebMIDI is not supported
That is misleading. Mozilla chose not to implement it for security concerns. More context: https://github.com/mozilla/standards-positions/issues/58#iss...
In Pianojacq, an easy way to learn to play the pianoI’ve just done a bit of investigation on the status of this in browsers. This is what I believe to be the case:
• Chrome is roughly planning to ship this in M88 (Q1 2021).
• There are no signals from Firefox or Safari, positive or negative.
• There were concerns earlier on from various spec and browser developers, but those seem to have generally been sorted out. But https://github.com/mozilla/standards-positions/issues/335 is still open and awaiting a response.
• As far as putting things into the WHATWG DOM and HTML specs is concerned, at least two implementers must be interested, so it won’t be being landed there just yet.
I invite corrections if I’ve missed anything or erred.
In Declarative Shadow DOMThere is a comment on this by Martin Thomson, Mozilla Distinguished Engineer, member of Internet Architecture Board:
"But my initial assessment is that the protections described in the spec are inadequate and I am of the opinion that this should be marked harmful." [0]
[0] https://github.com/mozilla/standards-positions/issues/154#is...
[1] Specification Positions https://mozilla.github.io/standards-positions/#native-file-s...
In The Native File System API allows web apps to save directly to files> Web MIDI API - Allows websites to enumerate, manipulate and access MIDI devices.
This API is actually a bit horrifying from a security perspective. In addition to allowing you to use MIDI keyboards as input devices on websites, it also allows websites to send binary firmware updates to MIDI devices. The reason is that it's common to use custom firmware to backup/restore settings and enable neat effects and functionality on MIDI devices.
Mozilla's engineers have reasonably pointed out that an attacker utilizing Web MIDI could use MIDI devices as a stepping stone to launch an attack against the user's PC outside of the web sandbox. One such attack might be by reprogramming the device to appear as a standard USB computer keyboard and "typing" commands to the host.
At least one well known manufacturer has vouched for the technical safety of
Read the rest
their musical instruments, noting that they're physically designed in such a way that the MIDI firmware can't alter USB firmware. But there's no way to know that every MIDI device has been similarly well designed.
As neat as Web MIDI is, I think Mozilla and Apple probably made the right security call here.
https://github.com/mozilla/standards-positions/issues/58
Google has been criticized by some experts for implementing the feature in Chrome by default since the feature can have some privacy issues. Here is a tweet https://twitter.com/pes10k/status/1229835239565905921 by Peter Snyder Security Researcher @ Brave and another comment from David Baron from Mozilla https://github.com/mozilla/standards-positions/issues/194#is....
And it looks like Google is now automatically adding Scroll To Text Fragment to Featured Snippets in Search results, this basically means that if you are on Chrome and click on the Featured Snippet they can automatically scroll and take you to the section of the page where the snippet was lifted from.
Try searching for https://www.google.com/search?q=Will+emojis+and+HTML+tags+wo... on Chrome Desktop. I was able to trigger them from Australia.
Another interesting thing is tha
Read the rest
t it only happens in Chrome, Edge and Firefox did not show them and in some cases, the Featured Snippet did not appear as well, kinda makes the SERPs on other browsers feel quite inferior IMHO. https://www.google.com/search?q=faq+page+Structured+data+typ... – try clicking on different browsers.
Even when the Featured Snippets are shown in these other browsers they don’t get the Scroll To Text Fragment treatment. https://www.google.com/search?q=scroll+to+text+fragment – try clicking on different browsers.
Obviously these other browsers don’t support Scroll To Text Fragment so it’s pointless to show them right, well in the case of Firefox yeah but Edge runs on Chromium and Scroll To Text Fragment actually works on it. Try clicking on https://tldrmarketing.com/about-us/#:~:text=Does%20Konami%20... on Edge.
From what I can see all Featured Snippets are getting the Scroll To Text Fragment treatment on Chrome desktop, would love to see examples when it’s not.
Mozilla for now has been against WebMIDI due to concerns about the scope and security implications: https://github.com/mozilla/standards-positions/issues/58
In Show HN: An online drawing tool that lets you change colors via MIDI controller"The major blocker right now is security issues related to device firmware hijacking." - https://github.com/mozilla/standards-positions/issues/58
In Firefox 73It's been kind of a headache in Firefox's WebMIDI support plans (since SysEx is sometimes used for firmware updates and it's hard to explain "this page may hack your keyboard" in a permission request dialog): https://github.com/mozilla/standards-positions/issues/58#iss...
In MIDI 2.0, first major overhaul to music interface standard from 1983This is very good news.
In my opinion, this does more to keep Google in check than had they gone with Firefox's engine, or stuck with their own. (I know not everyone agrees)
People use Chrome because they consider it a better overall experience than other alternatives, and I happen to agree. (again, I get that not everyone here agrees with that) For whatever reason, Google has the resources and talent to make a browser that is preferred to the alternatives, by most regular users.
Chromium based Edge allows users to get the best of Chrome without the worst of Google. Google knows that if they get too aggressive with decisions that are biased toward Google's bottom line (such as how they handle ad blocking and various privacy features), Microsoft can easily push back by changing these decisions in Edge. This is a very good thing.
True, ther
Read the rest
e is also pressure on Google from Firefox (people can abandon Chrome for Firefox if Google is too aggressive), and there is also Brave (and others) if you want the benefits of Chrome/Chromium without the worst stuff. But moving to Firefox is simply too big a move for most users and many don't like the downsides [1]. And Brave has their own revenue model to protect, and they don't have the deep pockets Microsoft has to resist the temptation to make decisions that benefit their bottom line in the short term.
[1] In my case, I do a lot with MIDI in the browser, i.e. connecting a digital piano and using it within web sites that support it. Firefox doesn't support this yet, after years and years of talking about it. https://github.com/mozilla/standards-positions/issues/58 There are a ton of other things, but that one is a deal breaker for me. Works beautifully in the new Edge.
Access to files is the critical issue here. Look at these examples from the article:
> Chrome OS doesn't have a robust photo editor? Don't worry, you can download an [Android] app! Chrome doesn't have native integration with cloud file services like Box, Dropbox, or OneDrive? Just download the app! Chrome doesn't have Microsoft Office? App!
The problem is that Chrome OS is attempting to be a desktop platform, using web apps and mobile apps.
Desktop OSes (Windows, macOS) are all about files. Apps are files. Your documents, photos, and videos are files. Any app can access any of your files.
On mobile, you don't normally interact with files. Apps aren't files; you launch apps directly from the app launcher, and they store data internally; when you delete an app, its data is deleted, too.
Web apps are like mobile apps: they don't have access
Read the rest
to your files. You can't make a web app photo editor that opens a file, makes some changes, and then saves those changes to the file. Instead, you have to "upload" the file to the web app, and then you have to "download" the modified file.
Microsoft Office has a web version (Office 365), but it's like Google Docs, lacking access to your local files. Dropbox has a web app, but it just lets you download files one at a time; it's impossible to implement Dropbox-like file synchronization in a web app.
Google is aware of this problem, but you might not like their proposed "solution," to develop a cross-browser standard file access API. https://web.dev/native-file-system/ Google's currently running an "origin trial," where a small number of web sites have temporary access to the feature to try it out.
I think Google's not going to ship it until they convince Apple or Mozilla to approve; it's not clear when (or if) that will happen. Here's the most recent discussion from May. https://github.com/mozilla/standards-positions/issues/154
So file access isn't technically "stalled out," but it's still going to take a long, long time.