3 ms·

"jxl without a flag" can't be re-added because that was never a thing.

by pgeorgi 3y ago

albert180 3y ago
[flagged]
deleted 3y ago
[deleted]
elygre 3y ago
Or (re-add jxl) (without a flag).
eviks 3y ago
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
- pgeorgi 3y ago
  It has a flag implication because jpeg-xl never came without being hidden behind a flag. Nothing was taken away from ordinary users at any point in time. And I suppose the Chrome folks have the telemetry to know how many people set that damn flag.
  - jdiff 3y ago
    >"But the plans were on display…” > “On display? I eventually had to go down to the cellar to find them.” > “That’s the display department.” > “With a flashlight.” > “Ah, well, the lights had probably gone.” > “So had the stairs.” > “But look, you found the notice, didn’t you?” > “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’”
    - pgeorgi 3y ago
      I guess you're referring to the idea that the flag made the previous implementation practically non-existent for users. And I agree! But "implement something new!" is a very different demand from "you took that away from us, undo that!"
      - jdiff 3y ago
        > No, obviously to re-add jxl without a flag Is asking for the old thing to be re-added, but without the flag that sabotaged it. It is the same as "you took that away from us, undo that!" Removing a flag does not turn it into a magical, mystical new thing that has to be built from scratch. This is silly. The entire point of having flags is to provide a testing platform for code that may one day have the flag removed.
  - eviks 3y ago
    I suppose I'll trust the reality of what actual users are expressly asking for vs. your imagination that something different is implied
    - pgeorgi 3y ago
      Actual users, perhaps. Or maybe concern trolls paid by a patent holder who's trying to prepare the ground for a patent-based extortion scheme. Or maybe Jon Sneyers with an army of sock puppets. These "actual users" are just as real to me as Chrome's telemetry. That said: these actual users didn't demonstrate any hacker spirit or interest in using JXL in situations where they could. Where's the wide-spread use of jxl.js (https://github.com/niutech/jxl.js https://github.com/niutech/jxl.js) to demonstrate that there are actual users desperate for native codec support? (aside: jxl.js is based on Squoosh, which is a product of GoogleChromeLabs) If JXL is sooo important, surely people would use whatever workaround they can employ, no matter if that convinces the Chrome team or not, simply because they benefit from using it, no? Instead all I see is people _not_ exercising their freedom and initiative to support that best-thing-since-slices-bread-apparently format but whining that Chrome is oh-so-dominant and forces their choices of codecs upon everybody else. Okay then...
      - 149765 3y ago
        I tried jxl.js, it was very finicky on iPad, out of memory errors [0] and blurry images [1]. In the end I switched to a proxy server, that reencoded jxl images into png. [0]: https://github.com/niutech/jxl.js/issues/6 https://github.com/niutech/jxl.js/issues/6 [1]: https://github.com/niutech/jxl.js/issues/7 https://github.com/niutech/jxl.js/issues/7
        pgeorgi 3y ago
        Both issues seem to have known workarounds that could have been integrated to support JXL on iOS properly earlier than by waiting on Apple (who integrated JXL in Safari 17 apparently), so if anything that's a success story for "provide polyfills to support features without relying on the browser vendor."
  - lonjil 3y ago
    > And I suppose the Chrome folks have the telemetry to know how many people set that damn flag. How is that relevant? Flags are to allow testing, not to gauge interest from regular users.

"jxl without a flag" can't be re-added because that was never a thing.

albert180 3y ago

[flagged]

deleted 3y ago

[deleted]

elygre 3y ago

Or (re-add jxl) (without a flag).

eviks 3y ago

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

pgeorgi 3y ago
It has a flag implication because jpeg-xl never came without being hidden behind a flag. Nothing was taken away from ordinary users at any point in time. And I suppose the Chrome folks have the telemetry to know how many people set that damn flag.
- jdiff 3y ago
  >"But the plans were on display…” > “On display? I eventually had to go down to the cellar to find them.” > “That’s the display department.” > “With a flashlight.” > “Ah, well, the lights had probably gone.” > “So had the stairs.” > “But look, you found the notice, didn’t you?” > “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’”
  - pgeorgi 3y ago
    I guess you're referring to the idea that the flag made the previous implementation practically non-existent for users. And I agree! But "implement something new!" is a very different demand from "you took that away from us, undo that!"
    - jdiff 3y ago
      > No, obviously to re-add jxl without a flag Is asking for the old thing to be re-added, but without the flag that sabotaged it. It is the same as "you took that away from us, undo that!" Removing a flag does not turn it into a magical, mystical new thing that has to be built from scratch. This is silly. The entire point of having flags is to provide a testing platform for code that may one day have the flag removed.
- eviks 3y ago
  I suppose I'll trust the reality of what actual users are expressly asking for vs. your imagination that something different is implied
  - pgeorgi 3y ago
    Actual users, perhaps. Or maybe concern trolls paid by a patent holder who's trying to prepare the ground for a patent-based extortion scheme. Or maybe Jon Sneyers with an army of sock puppets. These "actual users" are just as real to me as Chrome's telemetry. That said: these actual users didn't demonstrate any hacker spirit or interest in using JXL in situations where they could. Where's the wide-spread use of jxl.js (https://github.com/niutech/jxl.js https://github.com/niutech/jxl.js) to demonstrate that there are actual users desperate for native codec support? (aside: jxl.js is based on Squoosh, which is a product of GoogleChromeLabs) If JXL is sooo important, surely people would use whatever workaround they can employ, no matter if that convinces the Chrome team or not, simply because they benefit from using it, no? Instead all I see is people _not_ exercising their freedom and initiative to support that best-thing-since-slices-bread-apparently format but whining that Chrome is oh-so-dominant and forces their choices of codecs upon everybody else. Okay then...
    - 149765 3y ago
      I tried jxl.js, it was very finicky on iPad, out of memory errors [0] and blurry images [1]. In the end I switched to a proxy server, that reencoded jxl images into png. [0]: https://github.com/niutech/jxl.js/issues/6 https://github.com/niutech/jxl.js/issues/6 [1]: https://github.com/niutech/jxl.js/issues/7 https://github.com/niutech/jxl.js/issues/7
      - pgeorgi 3y ago
        Both issues seem to have known workarounds that could have been integrated to support JXL on iOS properly earlier than by waiting on Apple (who integrated JXL in Safari 17 apparently), so if anything that's a success story for "provide polyfills to support features without relying on the browser vendor."
- lonjil 3y ago
  > And I suppose the Chrome folks have the telemetry to know how many people set that damn flag. How is that relevant? Flags are to allow testing, not to gauge interest from regular users.