standards-positions

Web HID timeline: https://github.com/mozilla/standards-positions/issues/459#is... Same happened to WebRTC, by the way. Stable spec version was finally complete in 2018, 7 years after Chrome spat it out and called it a standard. And so on and so on.

in the face claiming that "it's Safari that's holding the PWAs back". Where reality is more complex and the narrative is mostly driven by Chrome, unfortunately.

ature of JPEG XL. It allows seamless transition to the new format by converting old images. AVIF can't do that. To be honest, their explanations feel like post-hoc rationalizations. It seems Google invested too much into an inferior format (AVIF) and now because of the sunk cost fallacy they can't pivot to JPEG XL. [1] - https://bugs.chromium.org/p/chromium/issues/detail?id=117805... [2] - https://helpx.adobe.com/camera-raw/using/hdr-output.html [3] - https://github.com/mozilla/standards-positions/issues/522#is... [4] - https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c23 [5] - https://github.com/exiftool/exiftool/blob/master/Changes#L44... [6] - https://git.videolan.org/?p=ffmpeg.git;a=commit;h=0008c15956... [7] - https://www.gimp.org/news/2021/10/20/gimp-2-99-8-released/#i... [8] - https://imagemagick.org/script/formats.php [9] - https://docs.krita.org/en/general_concepts/file_formats/file...

l) wanted this feature, so Chrome shipped it against clear objections from both Safari and Firefox. And then refused to move the feature back under a flag because "0.8% of page views in Chrome" were suddenly using this feature. And proceded to gaslight other browsers' developers https://github.com/WICG/construct-stylesheets/issues/45. See e.g. a response to that https://github.com/WICG/construct-stylesheets/issues/45#issu... Of course there's now a "looking ahead" that wants to do exactly what Safari and Mozilla wanted to do in the first place: https://web.dev/constructable-stylesheets/#looking-ahead In general, Chrome pushes 40 to over 100 new Web APIs with each release (that is, every two months). How many of them are actual standards that had actual input from other browser developers? In how many Chrome actually listened and implemented suggestions? https://web-confluence.appspot.com/#!/confluence

there-in & ignoring a vast swarth of evidence about process you just straight up ignored (both times) in that thread, & talk about the spec. Yes, Mozilla team/present-leader Martin is far far far less willing to entertain any possible "risk," here & more at length in WebUSB[1]. Fear that devices might not want to be accessible, to me, reads more like propaganda against the Hacker spirit & creativity, bends to the corporation owning our devices & not us. We do need to shield users, but shielding users absolutely from any possibility, to save them from a couple possibly risky possibilities, is a damned & infernal decision. Alas Mozilla/Martin not only make a harsh & greatly constraining decision readily, they make this decision lightly & without any interest in remedy, show no interest in exploring possibility. Martin's complaint in WebUSB seems to revolve entirely around imagining that it'll be hard to update a blocklist to access usb-bluetooth (and potentially other high security devices) devices: > 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 For one, I'm not even sure why we'd want to block access to bluetooth devices. If a user wants to go to a webpage that tries to act like a bluetooth sniffer (or something far more prosaic), & give the page permission to use their bluetooth devices, I don't think that's unreasonable or should be prohibited. But let's grant that mid-level bluetooth interfacing is just too much freedom to handle. There's still nearly zero evidence this blocklist has been hard to maintain. Google has required scant updates. The concerns Martin projects haven't panned out yet: vanishingly few cases of abuse, and the blocklist has required nearly no tending to. Even though the most popular browser on the planet has shipped this feature for half a decade now. As a recent-ish comment says: > The discussion here seems to mostly be around vague concerns that have not been proven to be problematic [in the half-decade since it got shipped]. I find the Mozilla positions here to be immoral & indefensible, especially as they stand without any suggestion of remedy. Denial of possibility, without suggestion or willingness to progress, is an anethema, & Mozilla has been unwilling to demonstrate any buy in, hasn't shown any interest in helping progress things. Their pretenses of security-mindedness are damaging & detrimental, & out of touch, inflexible, and haven't changed across half-a-decade of evidence stacked against them. Denying WebUSB & WebHID is a tragedy, firewalls off the web from essential & basic computing that it ought be able to involve itself with, & that is used to enormously good effect, such as the schoolchildren's ability to work with their BBC:MicroBit[2] with whatever computer they have about. I'm sorry it's like this- I wish there were healthier engagement on all sides- but the harsh descriptions I keep using are deserved. Mozilla and Safari seem to have "ganged" up, & have a campaign "marching" against growing the web. I'm not sure where to go find the links, but like ~2 years ago there was a big series of blog posts by Apple and Mozilla proudly advertising that they were rejecting many features like Battery sensors, Ambient Light sensors... I get that a lot of people don't think this stuff is valuable, that it's trendy to want a minimalist web. But this conservative software ideology[3] isn't about helping people. It's about jumping on a bandwagon, about being vile and nasty. There's no evidence these company's are interested or willing to talk about what we could to offer elevated capabilities, to make maybe PWA's for example get access to these capabilities. It's a party of haters (and astroturfed covert App-Store interests). Yes, I do keep being a bit strong in my accusations, because these people are doing bad, & uncompromisingly so. [1] https://github.com/mozilla/standards-positions/pull/368/file... [2] https://microbit.org/get-started/user-guide/web-usb/ [3] https://gist.github.com/cornchz/3313150

itself is signed. However, this requires the server to use web bundles in the first place, which likely isn't happening any time soon. Mozilla considers the proposal harmful: they expect Google will serve the majority of web bundles, allowing them to see what sites the user is visiting. https://github.com/mozilla/standards-positions/issues/264 https://www.ghacks.net/2020/08/30/google-proposed-web-bundle...

s means that Safari's stance may also change. Same goes for other hardware APIs: from the point of view of both Safari and Firefox those specs have security and privacy holes the size of Jupiter. Not to mention that the quality of some of these so-called specs is very low. If/When these issues are resolved, we may see them implemented in these browsers, too.

reality at best and a blatant lie at worst. And this is always the case. But sure. "Safari is the bad guy".

dards-positions/issues/459#is... etc. > It's also really important to be specific as to why the behaviour is harmful to end consumers. We also need to order the issues in terms of priority and how damaging they are to the wider ecosystem. You've already stated your priorities loud and clear > and respecting a user's browser choice via Android or Google apps. Yup, it's s good one. Since Google doesn't respect that and ignores all/most input on the non-standards it's pushing out at neck-breaking speed, you can see where it's going if you "allow browser choice on iOS"