“Absolute colorimetric” makes no sense in this context. So the answer is always “perceptual” or “relative colorimetric”. But that alone doesn’t really tell you what to do. A rendering intent is not a gamut mapping algorithm, and there are many possible gamut mapping algorithms.

Here’s a 300 page monograph discussing more or less the state of the art 10 years ago, https://amzn.co/0470030321

But here’s the thing... it doesn’t really matter. Their current choice is to just treat everything untagged as being in the display’s profile and do no color management. This is pretty much the worst possible choice.

The specification is very clear. Untagged colors in CSS/HTML are sRGB. Period. Doesn’t matter if they are specified as RGB or HSL coordinates (P.S. it was a huge mistake to add the latter to the web; HSL/HSV should never be used for any purpose).

Currently most of the browsers flagrantly violate the specification.

The browsers have been doing things wrong since forever. People who know anything about it have been annoyed since forever, but their feedback seems to have very little influence. Everyone else is blissfully ignorant, except for often encountering weird color bugs that they don’t understand the cause of.

> Should a CSS box with "no colorspace" #ff0000, when displayed on two calibrated displays of equal luminosity but differing (sRGB, P3) color profiles, appear visually identical to the human eye (Safari) or should it be more saturated on P3 (Firefox)?

It should appear more or less the same on both. The spec explicitly specifies that it is sRGB. Under no circustances should it be naively treated as P3. However some gamut mapping algorithms might make it slightly more colorful when going from sRGB -> P3 (without significantly altering lightness/hue relationships between colors).

> What is the correct CSS declaration to specify P3

This is something to take up with the CSS spec authors. They can add some ability to opt-in to tagging non-sRGB colors. If the spec doesn’t support it, then there is no way.

* * *

Edit: Your linked draft spec clarifies that something like relative colorimetric intent must be used. “Implementations may choose to implement these steps in some other way (for example, using an ICC profile with relative colorimetric rendering intent) provided the results are the same for colors inside the source and destination gamuts.”

So your answer about the untagged #ff0000 is that it should look pretty well identical on both displays.

Glad they are adding some facility for non-sRGB colors to CSS. Of course it wouldn’t be the W3C if they didn’t also add some useless clutter in every new spec. The “HWB” color space? Who comes up with such nonsense?

(Compare to SVG trying to add turtle graphics and Catmull–Rom splines to their path specification mini-format, for basically no reason, in the latest draft spec.)