4 ms·
Not to mention the complexity is mostly offloaded to the maintainers of the library itself, not the browser that calls it. I wish Mozilla had gone ahead and en
by pedrovhb 4y ago
Not to mention the complexity is mostly offloaded to the maintainers of the library itself, not the browser that calls it.
I wish Mozilla had gone ahead and enabled it by default in Firefox, as I'd hoped it would. Still salty it didn't happen (yet, at least). It seems like such a clear choice to developers that there's actually people being vocal about it (as evidenced by the sparse but constant stream of e.g. posts on HN about browser image codecs, which is a topic _no one_ finds sexy otherwise), but browser vendors still won't budge. It's weird to see them say "sure it's better, but it's not better enough than the alternatives". There's a large enough discrepancy in my own perception of the merits of jxl and that of the people making choices for browsers that I genuinely wish I understood them, because it feels like I'm missing something.
I still convert my pictures to jxl locally and, and the space savings are enough of a reason to go through the trouble of converting - it just seems like a no-brainer that it'd be even more valuable on the web, as bandwidth savings are generally even more important than disk storage, and then there's still the plethora of other features on top of that.
- izacus 4y agoThe browser developers defacto become the library maintainers since they're now on the hook for any security issue within that library forever. Even if the "real" maintainers go play with something else.
- skywal_l 4y agoIndeed, once you officially support a format and it becomes a standard, you have to support it forever. Sunsetting a feature is not that easy on the web. So if for some reason the maintainer of a library used by the browser drops the ball you are on the hook for anything. And decoding binary data coming from unknown potentially malicious source is full of potential security traps.
- toastal 4y agoConsidering <picture> and image() exists and should be seen as a best practice, adding and removing image formats/codecs should have a few less problems than some other libraries, no?
- eyelidlessness 4y agoThey provide some resilience, assuming their fallback usage includes multiple formats. Which isn’t a safe assumption, but even granting it, there are other problems with removing a codec. The most obvious being abruptly increasing the bandwidth requirements for all users of the removed codec. Even if that bandwidth is “free”, it can be significant enough to prevent access by end users with slow/spotty connections. Depending on the use case, that can have the consequence of also basically obsoleting the site serving those users. Just as some innovations enable whole new use cases, reverting the innovation can have the opposite effect.