I don't have any strong opinion on JPEG XL, asides from the general observation that adding more image decoders written in memory-unsafe languages is a generally sad thing to do. (I'm still not happy about how we were forced to support JPEG 2000 a couple years back due to websites using Akamai Image Manager.) In particular, I notice that libjxl is quite a lot of C++ code. On the other hand, given that WebKit is itself all C++, you could reasonably say something about "people in glass houses should not throw stones." :) So even though image decoders are quite sensitive, that shouldn't be a blocker IMO.
The most important point you need to know is that Safari doesn't use WebKit's image decoders at all, so if you want JPEG XL to work in Safari, contributing JPEG XL support to WebKit is not likely going to achieve your goal. Even if Safari did use our image decoders, which it doesn't, we don't copy third-party projects into the WebKit source without a *very* exceptional reason to do so (as for ANGLE or libwebrtc), so OS support for JPEG XL is going to be key. There are two cases:
(1) Non-Apple platforms use image decoders under Source/WebCore/platform/image-decoders. Depending on libjxl if it is installed as a system library, and using it to implement a JPEG XL image decoder under Source/WebCore/platform/images-decoders/jpegxl, seems OK to me. (Whereas copying libjxl into the WebKit source repo would certainly not be OK. That's way too much code.) There would need to be a CMake build option to disable the dependency for systems where libjxl is not available as a system library. It would only make sense to do this if somebody makes an effort to package libjxl for at least a few major Linux distros, otherwise it won't be used in practice. PlayStation and Windows ports can then build libjxl themselves if they so choose.
(2) Apple platforms use CoreGraphics for image decoding, see Source/WebCore/platform/graphics/cg/ImageDecoderCG.[cpp,h]. I don't know much about this, but I don't think it's open source, so I would guess that contributions are probably not possible. I'm not sure what to tell you here. Hopefully somebody from Apple will comment.
This is pretty much accurate as far as the Apple port is concerned; image format support depends on OS library support, rather than anything in WebKit. And indeed, the relevant OS libraries aren’t open source. And to be clear, Apple’s OSes do not currently support JPEG XL. /Sam