Live data from Hacker News

Google unkills JPEG XL?

tonisagrista.com

41–50 of 283 posts

Re: Google unkills JPEG XL?

#41
post #27

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.

How about the users and web authors?

Re: Google unkills JPEG XL?

#42
post #12

As 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.

And this will land in Chrome how?

Re: Google unkills JPEG XL?

#43
post #32

As 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.

Then what is this article about?

Re: Google unkills JPEG XL?

#44

As 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.

Which is why Firefox is steadily losing market share.

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?

#45

Earlier 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.

> Lack of metadata for collecting

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?

#46
Have 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.

Re: Google unkills JPEG XL?

#47
post #43
post #32

Earlier quoted context omitted.

Nobody is stopping you from using jpegxl.

Then what is this article about?

It's a meta-commentary about the death of critical thinking and the ease with which mindless mobs can be whipped.

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?

#48

Have 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.

That's why both Mozilla and Google have predicated their JXL support on a memory-safe implementation. There's a Rust one in the works.

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?

#49

Have 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.

> Have 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.

Post reply on HN