Comment by pgeorgi
3 years ago
All those requests to revert the removal are funny: you want Chrome to re-add jxl behind a feature flag? Doesn't seem very useful.
Also, all those Chrome offshoots (Edge, Brave, Opera, etc) could easily add and enable it to distinguish themselves from Chrome ("faster page load", "less network use") and don't. Makes me wonder what's going on...
> you want Chrome to re-add jxl behind a feature flag? Doesn't seem very useful.
Chrome has a neat feature where some flags can be enabled by websites, so that websites can choose to cooperate in testing. They never did this for JXL, but if they re-added JXL behind a flag, they could do so but with such testing enabled. Then they could get real data from websites actually using it, without committing to supporting it if it isn't useful.
> Also, all those Chrome offshoots (Edge, Brave, Opera, etc) could easily add and enable it to distinguish themselves from Chrome ("faster page load", "less network use") and don't. Makes me wonder what's going on...
Edge doesn't use Chrome's own codec support. It uses Windows's media framework. JXL is being added to it next year.
> Edge doesn't use Chrome's own codec support. It uses Windows's media framework. JXL is being added to it next year.
Interesting!
Simply put these offshoots don't really seem to do browser code, and realize how expensive it would be for them to diverge at the core.
No, obviously to re-add jxl without a flag
"jxl without a flag" can't be re-added because that was never a thing.
It can, that's why you didn't say "re-add jxl", but had to mention the flag, 're-add' has no flag implication, that pedantic attempt to constraint is somehing you've made up, that's not what people want, just read those linked issues
11 replies →
Or (re-add jxl) (without a flag).
[flagged]