Chromium is in the business of adding things websites should have no business concerning themselves with, like Bluetooth support, while removing support for useful things: now JPEG XL, previously RSS, MathML.
Yeah, and that's arguably thanks to Igalia and all of their sponsors. They've put a colossal amount of work into this project. If you have the means, it's worth donating for ongoing support, too: https://opencollective.com/mathml-core-support
Google just removed it and would've been content with it staying gone. They said "it wouldn’t have been a good return on investment for us to do it".
Well MIDI support is pretty cool, I could just go to Novation website and update SL49 firmware (after appropriate confirmation). Also Tasmota project has a firmware upload over serial, pretty accessible if you have Chrome.
I think Bluetooth could similarly be useful for e.g. heart rate monitoring apps for sports.
> I think Bluetooth could similarly be useful for e.g. heart rate monitoring apps for sports.
As the op commented, why not leaving the burden of managing/pairing the heart rate monitoring device to the OS? In the same way audio and input devices work?
The only real use case that comes to my mind with Bluetooth support is indeed monitoring, but it’s not about heart rate.
Because then you are limited by the use cases the browser vendors have thought of, instead of enabling new applications someone else thought of.
I mean, why not also use it for controlling a LEGO robot from a Scratch app? Configuring presets of your coffee maker without needing a mobile app? Updating the firmware of your soldering iron via vendor web page?
Just providing supervised access to Bluetooth LE would satisfy these all without adding custom interface for all current and all future devices we might want a web page to interact with.
I thought the business was Chrome, whereas Chromium was the open source (and GPLed) project that makes the code that Chrome uses and that would almost certainly not start out as GPLed if it was a new project now.
How would a web developer use a feature, which is disabled by default? Should they put up a banner saying "in order to view this page, restart your browser with this command line parameter"?
You'd use it the same way any other web feature without widespread browser support is rolled out--progressive enhancement, i.e. load it at runtime if heuristics indicate the necessary browser APIs are available, otherwise fall back to a "degraded" version.
Not the parent commenter, though one thing is to support a feature that is somehow spread across some browser families and/or versions and another thing is to support a feature that is mostly unavailable on clients. It is probably not worth it form an economical point of view once you factor in the time spent developing/maintaining the feature plus (for this case) the additional required storage.
I use it with the picture element as the preferred codec. I found often AVIF was a bigger size than WebP and JXL so I stopped bothering as the encoding times are just awful.
