CC'ing participants in the original discussion for visibility: @tabatkins @gregwhitworth @astearns @svgeesus @Crissov @mwatson2 @AmeliaBR @chcunningham @vi-dot-cpp

The other issue with the wording regarding "The combination of the User Agent and the output device..." is that User Agents may have different capabilities for CSS (and HTML) colors, colors in images, colors in canvas, colors in videos, etc. Which of these are required to be supported should probably be specified, both (separately) for dynamic-range and video-dynamic-range.

As a developer, I agree that it would be kind of pointless to have (dynamic-range: high) return true if the actual user agent didn't support high dynamic range colors in at least some CSS-visible sense (CSS colors or colors in images). I think removing the mention of the UA in the description of this media query would mean that we end up speccing a property that is internally consistent, but isn't useful to developers and therefore doesn't gain adoption. And then in 12 months or so we'll be in the same place again and have to specify a new user-agent-video-dynamic-range media query.

In the discussion surrounding the proposal for these queries, the idea was that this query would be a coarse representation of the display device's capabilities, and more detailed APIs such as MediaCapabilities could be used to gather specific information about the User Agent's capabilities for specific purposes.

As a participant in the original discussion, I want to give a big +1 to ^this point. The dynamic-range MQ was motivated entirely by a need to describe the screen's capabilities. This is consistent with the overall purpose of Media Queries, which describe features (e.g. resolution) for the current media device (e.g. screen).

I think folks are confused by the video-dynamic-range feature. At a glance, this looks like it indicates when the UA is capable of playing HDR <video>, so it follows that the non-video dynamic-range would correspond to non-video things like CSS. This is understandable but definitely not the intent.

Both video-dynamic-range and dynamic-range describe the screen. The video-dynamic-range proposal concerns a weird quirk of user agents implemented in TVs. Given limited system resources and a clear priority use case, these devices have a quirky implementation where video and non-video are rendered in distinct "planes", which amounts to distinct screens with distinct capabilities. Generally speaking, the video plane has a much higher resolution and dynamic range than that of non-video. Traditional user-agents have only one plane, such that video-dynamic-range and dynamic-range should behave identically.

Again, video-dynamic-range just describes the screen. It does not describe support for HDR video playback. This is a much more complicated question (w/ parameters like codec, transfer function, metadata, ...) which Media Queries is ill-suited to answer (it is instead answered by navigator.mediaCapabilities.decodingInfo()). IMO, questions about canvas, CSS, images, etc, should similarly follow this model of offering separate feature detection, choosing whatever method is most idiomatic for their respective domains.

Both video-dynamic-range and dynamic-range describe the screen. The video-dynamic-range proposal concerns a weird quirk of user agents implemented in TVs. Given limited system resources and a clear priority use case, these devices have a quirky implementation where video and non-video are rendered in distinct "planes", which amounts to distinct screens with distinct capabilities.

Yes, exactly. In other words, for most devices, these will have the same value. Only for a TV with a high-res, HDR video buffer and a (lower res, non-HDR) "graphics overlay buffer" will they have different values.

So the specification needs to more clearly reflect that.

The CSS Working Group just discussed [css-mediaqueries-5] Clarifications on [video-]dynamic-range MQs.

Having had a little side discussion with the chrome folks, the tentative conclusion is that the way Safari implemented this is what we'd like the spec to align to. Specifically:

• standard is a subset of high, in the same vein as the color-gammut media feature values.
• Even though we just have two values, we do want to keep it as "standard" and "high", not turn it into "none" and something else so that it'd work in a boolean context, because in the future we may need to add one or more values to distinguish between high and even higher, depending on what sort of device gets made.
• This is about HDR capability, not about "is HDR active". The later question could possibly be interesting, but it's a more complicated one as that means different things on different types of devices, and the primary use of the MQ is just to gate-keep you entire HDR logic
• there is no author desire for sub-dividing the querry between hdr-for-video, hdr-for-images, hdr-for-css, etc, because while that would be more fine grained, it wouldn't actually be fined grained enough to answer all your hdr questions. You might still need to wonder about image/video formats, contrast ratios, quality of tone-mapping…… So it's not really a good idea to make the MQ more complex if it's not actually going to answer the nuances, and having it as a blunt question to know if you should bother with HDR at all seems to be what authors are actually calling for.
• There's nothing unusual about this querry when it comes to testing the capabilities of the output device vs that of the user agent vs that of the combination, so we should neither put special emphasis on it, nor go out of our way to claim that we're only testing one or the other.

In other words, a hypothetical different design, like

hdr:
    none | 
    [ 
        [img | img(<img-format>)] |
        [video | video(<video-format>)] |
        css |
        canvas
    ] &&
    active?

is not actually appealing to authors, and would add complexity for no practical reason, thus we should spec what Safari is shipping.

Misconfigured the log bot while discussing this. The discussion is at https://logs.csswg.org/irc.w3.org/css/2021-12-15/#e1452098, and the resolution was :

RESOLVED: dynamic-range: standard also matches when dynamic-range: high matches