A full-resolution, maximum-size JPEG XL image (1,073,741,823 × 1,073,741,824): Uncompressed: 3.5–7 exabytes Realistically compressed: Tens to hundreds of petabytes Thats a serious high-res image
Google unkills JPEG XL?
21–30 of 283 posts
Re: Google unkills JPEG XL?
#22A full-resolution, maximum-size JPEG XL image (1,073,741,823 × 1,073,741,824): Uncompressed: 3.5–7 exabytes Realistically compressed: Tens to hundreds of petabytes Thats a serious high-res image
Re: Google unkills JPEG XL?
#23Earlier quoted context omitted.
Well, they said they would unkill xslt if someone would rewrite and maintain it so that it's not the abandonware horrorshow it was. As for JPEG XL, of course they unkilled it. WEBP has been deprecated in favor of JPEG XL.
Webp deprecated? According to what?
Similarly, AVIF uses little more code than the AV1 keyframe decoder, so since every browser supports AV1, every browser also supports AVIF.
Re: Google unkills JPEG XL?
#24Earlier quoted context omitted.
Well, they said they would unkill xslt if someone would rewrite and maintain it so that it's not the abandonware horrorshow it was. As for JPEG XL, of course they unkilled it. WEBP has been deprecated in favor of JPEG XL.
honestly hate webp so happy about this
Re: Google unkills JPEG XL?
#25A full-resolution, maximum-size JPEG XL image (1,073,741,823 × 1,073,741,824): Uncompressed: 3.5–7 exabytes Realistically compressed: Tens to hundreds of petabytes Thats a serious high-res image
Re: Google unkills JPEG XL?
#26Earlier quoted context omitted.
Didn't Mozilla basically say they would support it if Google does? Mozilla doesn't have the resources to maintain a feature that no one can actually use; they're barely managing to keep up with the latest standards as it is.
They have many millions to spend on engineers. They should do that.
Re: Google unkills JPEG XL?
#27Earlier quoted context omitted.
Having key browser implementers not involved in the standards processes is what lead us to the W3C wasting several years chasing XHTML 2.0.
There are other key browser implementers. Google should not have more than an advisory role in any standards organization.
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.
Re: Google unkills JPEG XL?
#28As 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.
Well, they said they would unkill xslt if someone would rewrite and maintain it so that it's not the abandonware horrorshow it was. As for JPEG XL, of course they unkilled it. WEBP has been deprecated in favor of JPEG XL.
Can you point to somewhere that Google or anyone else indicated that they would support xslt once there’s a secure, supported version?
Re: Google unkills JPEG XL?
#29A full-resolution, maximum-size JPEG XL image (1,073,741,823 × 1,073,741,824): Uncompressed: 3.5–7 exabytes Realistically compressed: Tens to hundreds of petabytes Thats a serious high-res image
Re: Google unkills JPEG XL?
#30As 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.
Well, they said they would unkill xslt if someone would rewrite and maintain it so that it's not the abandonware horrorshow it was. As for JPEG XL, of course they unkilled it. WEBP has been deprecated in favor of JPEG XL.
Who said this? I was never able to find any support among the browser devs for "keep XSLT with some more secure non-libxslt implementation".