My first instinct is that the most-CSS-y way to handle this would be through new video-* prefixed media features, although I don't know if there need to be as many new features as suggested.

It sounds like most of the use cases would be covered by video-resolution and video-color-gamut (with values and interpretation equivalent to the resolution and color-gamut queries, but specifically for the video rendering pathway). I don't think we need to duplicate the legacy color-related queries.

For rendering within a browser window, the width and height of the screen in CSS px would remain the same, only the dppx resolution would be different, so they wouldn't need separate queries.

But for full screen video, the dimensions would be different. So maybe there would need to be full-screen-video-width/height/aspect-ratio queries. If that is necessary, it might be best to report the raw pixel counts (not CSS px), since that's what people are used to when talking about video resolution. However, this is also very similar to the dropped device-width and device-height queries, and I'm not sure why those were dropped & whether this would have the same problems.

Note that the big game changer here is the hdrSupported.

I like the "verbose but functional" suggestion to add that to both Screen and Video.

I don't want TV-oriented content to be erroneously deciding that HDR is not supported because "there is no separate video plane and everyone knows the graphics plane is SDR only", for example.

I'm going to head over to the original issue to explain why we like media features rather than media types. @frivoal please feel free to help out/correct me if wrong.

the big game changer here is the hdrSupported.

I don't like the idea of using a Boolean for this. What happens when a new "super-high dynamic range" tech comes out? Or a "HDR lite" tech (higher than standard but not as high as other HDR devices)? The benefit of using an enumeration like color-gamut is that it can be expanded in the future.

@AmeliaBR
I don't like the idea of using a Boolean for this.

Enumerating HDR (video) display capabilities would require two (2) new properties -- color-gamut and transfer-function -- to be exposed in granular detail, which gave rise to fingerprinting concerns. Since current HDR formats use the Rec. 2020 color space and PQ transfer function, the Media WG opted for a single Boolean to assuage fingerprinting concerns whilst still satisfying content providers' needs. This #118 comment explains the risk.

What happens when a new "super-high dynamic range" tech comes out? Or a "HDR lite" tech (higher than standard but not as high as other HDR devices)?

We have kind of kicked this concern around, but I do not recall a clear resolution. For the sake of my own understanding, I welcome feedback. Please let me know if this discussion should be separated into a new issue as to not derail the bi-plane discussion.

CSS doesn't do booleans, because they're often a bad design for the reasons Amelia brought up, but it's easy to assuage that with an enum that currently just has two values, but can be extended in the future.

And Chris is right; media types other than screen/print are deprecated and we don't plan to do any further work in that space. Overall they were a failure for what they intended (implying a number of MQ features as a bundle, before we invented the rest of MediaQueries), and we instead just handle their use-cases with more MQs when necessary. They were never useful for y'all's desired purpose, of reporting different values to some MQs based on what media type is being asked about, because they're evaluated totally independently of the rest; in effect they're just a (device-type: ...) MQ.

So yeah, I'm with Amelia and Chris in preferring option 2, where we define some video-* MQs that duplicate some of the existing MQs, but specifically refer to the video plane.

Like Amelia said, I don't think we need to carry over some of the weirder legacy color/sizing MQs, but I do think height/width are useful, so I suggest video-color-gamut, video-resolution, video-width, and video-height. Is there anything else that needs to be exposed for negotiation? @vi-dot-cpp mentions transfer function; is that something y'all will need?

Agree with @vi-dot-cpp - I don't think we want to add transfer function to Screen. We instead added it to mediacapabilities.decodingInfo(), which works well for both the classic desktop/laptops as well as smart TV setups.

strawman: what if we do an enum called dynamic-range, with values { standard, high }. In 2025 we can add crazy-high or whatever the marketing folks call it ;)

@mwatson2

Seems option 2 is the favorite, so this would imply adding dynamic-range as well as video-dynamic-range (in addition to other video-* prefixed @tabatkins mentioned.

dynamic-range enum is fine for us.

Actually, the dynamic range supported by the PQ transfer function is already "crazy high" and the 2020 color gamut "crazy wide". Never say never, but it will be a long long while before consumer devices are capable of fully supporting either. Content today is mastered within a subset of the range that is expressible in this pixel encoding, but that subset still well exceeds existing consumer devices. Devices are expected to map down (tone map) from the provided range / gamut of the content to their actual capabilities. Provided a device has that tone mapping capability (which we'll discover through decodingInfo) and has a display capability that is genuinely better than SDR, then we would prefer to deliver HDR. Such devices should declare high for this new enum.

what if we do an enum called dynamic-range, with values { standard, high }.

The currently defined CSS color-gamut media feature uses keywords to describe existing commercial standards: srgb, p3, rec-2020. Does that cover what you need, or is that a distinct concept?

Or, could it cover what you need when combined with a measure of color bits per pixel, as suggested by the example in the CSSOM View spec describing the colorDepth value of the Screen interface? (The color media feature provides similar information to colorDepth, although not in a directly interchangeable format.)

It would definitely be preferable to harmonize the concepts used in media queries with those used in CSSOM View, even separate from the bi-plane considerations. If we can do that, then it seems like a natural extension to handle bi-plane rendering by extending the necessary media queries to have video-* versions, and extending the Screen interface to have a screen.video sub-object.

@mwatson2 - keep me honest

The currently defined CSS color-gamut media feature uses keywords to describe existing commercial standards: srgb, p3, rec-2020. Does that cover what you need, or is that a distinct concept?

They are distinct but interconnected concepts. Color gamut describes a color spectrum while SDR/HDR is about luminance range.

In practice, different gamuts do correlate with sdr / hdr, but there are edge cases (like Apple's 2017 P3 displays, which are not HDR) and I think its not clean enough to live without a separate dynamic range signal.

@chcunningham is correct that these are distinct concepts. Color gamut, color depth and dynamic range are all distinct things that can vary independently, though not all combinations are in use.

In particular, BT.2020 color gamut is used with both standard dynamic range and high dynamic range as is 10 bit color depth. Color depth is about precision, not range. (btw, Example 3 here is wrong about this).

To further clarify the problem description, given media in a specific format we must ask first whether the media can be rendered at all in some reasonable form and second whether it should in the case the site has a choice of formats. The first is a question about UA support for the codec and pixel data format and it's ability to map that meaningfully to the output device. The second is a question about the raw capability of the output device.

We separate these questions because in some cases the site might not have a choice of formats and is only interested in whether the format can be rendered or not. If the site has a choice of formats, all of which can be rendered, it needs to know which is worthwhile and will produce the best result. Unless you have no choice, there is no point sending HDR if the output device is SDR, even if the UA has the capability to map it down.

Agreeing with others that color gamut (how saturated a color can be displayed) and dynamic range (how many photographic stops of luminance can be displayed {all at once | at various times}) are distinct concepts although they are slightly correlated (HDR tends to require WCG as well, also higher bit depth per component).

Since current HDR formats use the Rec. 2020 color space and PQ transfer function, the Media WG opted for a single Boolean to assuage fingerprinting concerns whilst still satisfying content providers' needs.

That single Boolean will struggle with content that uses Rec.2020 colorspace and the HLG transfer function, though. "Everything uses PQ" is a Film/Movie-centric view; it is true there but not so much for News or Live Sports, for example.

That single Boolean will struggle with content that uses Rec.2020 colorspace and the HLG transfer function, though. "Everything uses PQ" is a Film/Movie-centric view; it is true there but not so much for News or Live Sports, for example.

Ah, that's my own mis-remembering, not negligence on the part of the Media WG. Do you all have thoughts the dynamic-range enum? It looks to offer extensibility and preserve privacy. Thanks for proffering the strawman @chcunningham.

If we opt for this enum, should we define a rubric by which to judge the dynamic range of a display?

That single Boolean will struggle with content that uses Rec.2020 colorspace and the HLG transfer function, though. "Everything uses PQ" is a Film/Movie-centric view; it is true there but not so much for News or Live Sports, for example.

PG vs HLG is important for the can this be rendered question (which is answered by decodeInfo() but not for the should I choose this one (when I have a choice).

If we opt for this enum, should we define a rubric by which to judge the dynamic range of a display?

Good luck with that ;-) The question I want to answer is whether it would produce a better result to send HDR content vs SDR when I have both available and the device can render both. At least at the margins this is a matter of opinion. So then I think we should leave this to UAs, as agents of the user, who is the one with the opinion.

Looks like we are converging on the following, feel free to chime in:

2. verbose but functional: Add video* prefixed media queries media features for the video plane.

CSS guidance is to add a video attribute to screen, denoting the video rendering pathway as opposed to that of graphics, for the purpose of addressing the bi-plane problem among TVs. The video attribute will expose the following properties:

• width
• height
• resolution
• dynamic-range

Screen HDR capabilities are represented the dynamic-range enum for the following reasons:

• Color-gamut in conjunction with existing Screen properties are not sufficient for detecting HDR capabilities.
• Bucketized in order to alleviate fingerprinting concerns.
• Enum with values { standard, high } to leave room for future augmentation to dynamic range standards.

There is concern though that { standard, high } are qualitative/un-standardized. As @mwatson2 noted:

Actually, the dynamic range supported by the PQ transfer function is already "crazy high" and the 2020 color gamut "crazy wide".

Are we able to address this concern by standardizing recommended ranges for properties that comprise dynamic range? What are your thoughts/feedback?

I think you mean for width to be in "CSS pixels" and same for height (length is typo). For clarity, resolution is "the number of device pixels per css unit". All that to say: while the values may differ between video* prefixed vs unprefixed features, but the units/definitions should be common to both.

There is concern though that { standard, high } are qualitative/un-standardized. As @mwatson2 noted:

Actually, the dynamic range supported by the PQ transfer function is already "crazy high" and the 2020 color gamut "crazy wide".

I think he's just saying that some of the underlying pieces (eotf and color gamut) have lots of headroom to describe a category of devices that don't exist yet. Said another way, 5 years from now when a new generation of TVs may have a much higher contrast ratio, and we'll call it "crazy high" dynamic range, but PQ may still be a suitable transfer function.

Mark's later comment is squarely on the side of not trying to assign tight definitions to categories of dynamic range. I think this sounds practical. There are a number of competing HDR badge requirements (e.g. UHD vs Vesa) and its a bit of a minefield to walk in.

I think you mean for width to be in "CSS pixels" and same for height (length is typo). For clarity, resolution is "the number of device pixels per css unit". All that to say: while the values may differ between video* prefixed vs unprefixed features, but the units/definitions should be common to both.

You're right. I've made edits to avoid confusion.

@gregwhitworth there's been a lot of discussion since you added the agenda+ tag. Are we converging on option 2, as above? Let's continue the discussion here and possibly take it up on the call next week.

@astearns Yep, I looked at the agenda list when I filed this and didn't expect it to make the agenda until about the 20th. Can we plan on it for that week?

The media working group just resolved on this:

video-* properties of width, height, resolution, dynamic-range, color-gamut within CSS for media queries

I'd like to add this to the agenda to get resolution in CSSWG as well.

I think that the media wg made a good resolution, so urge css wg to resolve the same.

Do we have a link to the Media WG discussion & resolution?

Specifically, did the group make any statement about a preferred CSS OM API, or only about the media queries?

The minutes from that meeting are here, but we didn't really discuss your question.

I think the focus on media queries is mostly an artifact of the discussion having started with the (now abandoned) proposal number 3 above, which would add a new media queries media-type for the video plane. We also discussed how media queries will allow you to subscribe for events when things change - important in multi-display use cases.

Having the information be also exposed on Screen seems like a nice-to-have. Is it generally a best practice to expose things in both ways? If so, I think either Screen.video.dyanmicRange or Screen.videoDynamicRange (and similar for other properties) would work - whichever is more idiomatic.

The CSS Working Group just discussed [cssom-1][mediaqueries-5][css-color] Dealing with bi-plane (video/graphics) when reporting values, and agreed to the following:

• RESOLVED: Add the video prefix MQ and define how used in bi-plane and non-bi-plane environments

@frivoal @tabatkins I'm finally getting around to making this edit (sorry for the delay) but I had a quick editorial question. Since ALL of them should contain the same values as the non-video counterparts, how do we want to represent that? Do we want it all duplicated or something along the lines of same values as <property link to propdef within MQ>?

@gregwhitworth Interesting question, maybe worth a separate issue?

CSS Values defines a way to reference the value syntax for properties (<'background-size'> refers to any valid non-list value for the background-size property), but there's no equivalent for media query values. We can't reuse the same syntax because there would be name conflicts. (E.g., the color media feature has a very different value syntax than the color property!)

Maybe <media-feature 'color'> or something like that…

I'm fine with just repeating the values for now. We can add a new non-terminal syntax if we start doing this sort of thing more often.

Remember, WET (Write Everything Twice), not DRY!

So, although we all agree that the color-gamut keywords are badly designed, but need to stay as is because they are already shipping, we still copy them verbatim to video-color-gamut?

@Crissov Can you expound on the agreement of it being badly designed? I'm also going to tag in @svgeesus as he's the color editor and will have far more historical context than I will.

Sorry, I forgot to mention the issue: #4535

"We" don't regard them as badly designed. They might have been better as more generic keywords, but that would have run the risk of needing more specific examples.

Anyway, that doesn't need to hold up this issue.

@gregwhitworth are you still able to make the required edits to close this issue, or should we look for other volunteers? Not sure if this is still in scope for you.

Hi @svgeesus - is the outstanding work tracked in #5044, or is there more? New updates on that issue just now.

is the outstanding work tracked in #5044, or is there more?

These seem at least highly related, possibly duplicates. Maybe close this one and leave #5044 ?

Maybe close this one and leave #5044 ?

Fine with me (I don't have that permission though)