> Not all approaches can provide a seamless upgrade. For example if you replace all `<img src="foo.jxl">` with a canvas DOM will be changed and anything expecti

> Not all approaches can provide a seamless upgrade. For example if you replace all `<img src="foo.jxl">` with a canvas DOM will be changed and anything expecting the element to be HTMLImageElement will break. Likewise, CSS Painting API [1] (a relevant part of CSS Houdini) requires you to explicitly write `paint(foo)` everywhere. The only seamless solution will be therefore a service worker, but it can't introduce any new image format; it can only convert to natively supported formats. And browsers currently don't have a "raw" image format for this purpose. JXL.js [2] for example had to use JPEG as a delivery format because other formats were too slow, as I've been told. You can get around many these compatibility issues by creating a custom element that inherits from HTMLImageElement. This provides API compatibility. For CSS compatibility, the elements you would replace in a MutationObserver would be the same tag name but a different namespace for CSS compatibility. For the CSS compatibility trick, see https://eligrey.com/demos/hotlink.js/ https://eligrey.com/demos/hotlink.js/ which replaces images with CSS-compatible (not HTMLImageElement-compatible) iframes. > - It is very hard to check if a certain image is visible or not, and react accordingly. You can use Element.checkVisibility()¹ and the contentvisibilityautostatechanged event²𝄒³ to do this. Browser support is currently limited to Chromium-based browsers. 1. https://drafts.csswg.org/cssom-view/#dom-element-checkvisibility https://drafts.csswg.org/cssom-view/#dom-element-checkvisibi... 2. https://github.com/vmpstr/web-proposals/blob/main/explainers/cv-auto-event.md#example https://github.com/vmpstr/web-proposals/blob/main/explainers... 3. https://caniuse.com/mdn-api_element_contentvisibilityautostatechanged_event https://caniuse.com/mdn-api_element_contentvisibilityautosta...