Earlier quoted context omitted.
There are other key browser implementers. Google should not have more than an advisory role in any standards organization.
The other key browser implementers are also part of WHATWG. Who do you suppose should be in charge of web standards? I can’t imagine the train wreck of incompetence if standards were driven by bureaucrats instead of stakeholders.
Google unkills JPEG XL?
41–50 of 283 posts
Re: Google unkills JPEG XL?
#42As a monopoly, Google should be barred from having standards positions and be legally required to build and support the web standards as determined by other parties. The insanity that the web platform is just "whatever Google's whims are" remains insane and mercurial. The web platform should not be as inconsistent as Google's own product strategies, wonder if XSLT will get unkilled in a few months.
Barred by who? There is no governing body who can do such a thing, currently. As it is, nothing stops any random person or organization from creating any new format.
Re: Google unkills JPEG XL?
#43As a monopoly, Google should be barred from having standards positions and be legally required to build and support the web standards as determined by other parties. The insanity that the web platform is just "whatever Google's whims are" remains insane and mercurial. The web platform should not be as inconsistent as Google's own product strategies, wonder if XSLT will get unkilled in a few months.
Nobody is stopping you from using jpegxl.
Re: Google unkills JPEG XL?
#44As a monopoly, Google should be barred from having standards positions and be legally required to build and support the web standards as determined by other parties. The insanity that the web platform is just "whatever Google's whims are" remains insane and mercurial. The web platform should not be as inconsistent as Google's own product strategies, wonder if XSLT will get unkilled in a few months.
Which other parties? Because Mozilla's stance on JPEG XL and XSLT are identical to Google's. They don't want to create a maintenance burden for features that offer little benefit over existing options.
If Mozilla wanted Firefox to succeed, they would stop playing "copy Chrome" and support all sorts of things that the community wants, like JpegXL, XSLT, RSS/Atom, Gemini (protocol, not AI), ActivityPub, etc.
Not to mention a built-in ad-blocker...
Re: Google unkills JPEG XL?
#45Earlier quoted context omitted.
It'll be in PDF sooner, and my experience is that PDF >> any other system for ebooks. I liked the idea of EPUB but when I recently installed an EPUB reader to read some files I was shocked at how awful it looked whereas for 15 years I've been reading PDF files on tablets with relish.
That's interesting, I absolutely hate PDF. Lack of metadata for collecting, format is difficult to support, doesn't layout well on mobile, and very limited customization (like dark mode, changing text size, etc). Only benefit is browsers have built-in support for the format.
PDFs have pretty excellent support for metadata. If the collection software doesn't support at least Dublin Core, that may be kind of their own fault...
Re: Google unkills JPEG XL?
#46Re: Google unkills JPEG XL?
#47Earlier quoted context omitted.
Nobody is stopping you from using jpegxl.
Then what is this article about?
From the jump, the article commits a logical error, suggesting that Google killed jpegxl because it favors avif, which is "homegrown". jpegxl, of course, was also written by Google, so this sentence isn't even internally consistent.
Re: Google unkills JPEG XL?
#48Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen.
I think Google are aiming to replace all of Chromiums decoders with memory-safe ones anyway, even for relatively simple formats.
Re: Google unkills JPEG XL?
#49Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen.
At this point, in 2025, any substantial (non-degenerative) image processing written in C++ is a security issue waiting to happen. That's not specific to JPEG XL.
Re: Google unkills JPEG XL?
#50Starting to feel like this whole "standards" thing is a giant farce