Great question. You're 100% correct, the whole test depends on the specifics of renderer behavior. The author of the article is assuming that any screen with less than sRGB coverage will tonemap the DCI-P3 image to look exactly the same as the sRGB one.
> if I want to preserve relative perceived differences between colors, maybe I’d map the boundary of DCI-P3 to the boundary of sRGB, and then interpolate all the interior colors (possibly with some non-linearities). This would allow people with sRGB monitors to see the WebKit logo in the article’s example
Yep. This sort of tonemapping is frequently applied to video. With images, this problem is usually handled through a chosen rendering intent [1] This way of doing it is usually called a perceptual rendering intent, and there are various algorithms that do it in different ways. However, for photographic materials the preferred approach is usually a colorimetric rendering intent, usually relative colorimetric.
With relative colorimetric, white point adjustments are made (if necessary), but more importantly, out-of-gamut colors are simply clamped to the nearest in-gamut color. This means something very important: if the user's screen only shows a subset of sRGB colors, then both the sRGB image and the DCI-P3 image will be clamped in exactly the same way, and appear to be indistinguishable. So basically, the comparison relies on the renderer using a relative colorimetric rendering intent, not a perceptual one. This is usually (?) a safe assumption.
> I’m not sure I understand what you mean here, could you elaborate?
Note that I'm not 100% sure that I'm right about the browser internal specifics. Basically, I have a screen that's roughly DCI-P3 capable. The browser has access to an ICC profile that describes the properties of my screen. There are lots of things in the browser that need to be adapted from whatever color space they're in natively to the screen's color space. There are canvases, videos, CSS colors, untagged images, images with ICC tags, etc etc.
So the problem is that each one of these elements may have a different (or entirely untagged) source space, and they all have to be converted to the monitor space. The approach you take to canvases may need to be different than the approach you take to video. Video has to be done very quickly if you're going to do it at all because each frame only lives a few ms. One really easy way to do a color space conversion would be to just assume that every layer the compositor sees is sRGB, and convert that to the monitor space. You get roughly correct video rather cheaply that way, for example, because the Rec. 709 space used by most web video is almost the same as sRGB.
But this means that earlier in the chain, any part of the page that is known not to be sRGB (like ICC tagged images) will need to be converted to sRGB so the compositor can handle it. This acts as a choke point. My experience suggests that this is the approach that Chrome takes on Linux. They get color management for free for any new thing because it's usually safe to just assume it's sRGB.
Firefox does it differently. Every different page element is responsible for its own color space conversion. That's why canvases weren't color managed at all in Firefox until very recently. Video still isn't, I think. AVIF images (which are still under a feature flag) still aren't color managed either. So color management in Firefox is shaky. But for anything that is color managed, you get correct colors, even if the source color space isn't sRGB!
Chrome:
(page elements) => sRGB -> monitor space
Firefox:
(some page elements) -> monitor space
[1]
https://en.wikipedia.org/wiki/Color_management#Rendering_int...