Intent to Ship: HDR CSS Media Queries

289 views
Skip to first unread message

Will Cassella

unread,
Oct 20, 2021, 11:41:15 AM10/20/21
to blin...@chromium.org

Contact emails

cas...@chromium.org, chcunn...@chromium.org, videost...@chromium.org

Explainer

Adds MediaQueries for detecting HDR vs HDR displays
https://www.w3.org/TR/mediaqueries-5/#dynamic-range
https://www.w3.org/TR/mediaqueries-5/#video-dynamic-range

Specification

https://www.w3.org/TR/mediaqueries-5/#dynamic-range

Summary

Adds media queries to CSS which allow a page to detect the current display device’s support for HDR. This feature adds two new CSS media queries: 'dynamic-range' and 'video-dynamic-range', both of which may be one of 'standard' or 'high'. Chrome will resolve these queries according to the capabilities of the display device the browser window is currently positioned on, allowing pages to toggle CSS rules accordingly or respond in Javascript via 'window.matchMedia()'.



Blink component

Blink>CSS

Motivation

As HDR-supported displays become more common, web developers need ways to enable HDR content on their web pages without compromising the experience for users of non-HDR displays, or mixed-HDR multi-display setups. CSS already provides the 'media query' concept for toggling rules based on display device characteristics, and this feature extends that set of queries to enable detecting HDR support on the current display device.



Initial public proposal



TAG review

Not Filed. This is an incremental change to CSS Media Queries, already adopted by CSS WG.

TAG review status

Not applicable

Risks



Interoperability and Compatibility



Gecko: Worth prototyping (https://github.com/mozilla/standards-positions/issues/584)

WebKit: Shipped/Shipping (https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1/) Partially implemented - `video-dynamic-range` not yet supported

Web developers: Positive (https://github.com/w3c/csswg-drafts/issues/4471#issuecomment-548085935) Feature designed with the help of Netflix.


Debuggability

No specific DevTools support



Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/css/mediaqueries/dynamic-range.html


Flag name

CSSDynamicRangeMediaQueries

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1224711

Estimated milestones

97


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5680926106320896

This intent message was generated by Chrome Platform Status.

Will Cassella

unread,
Oct 20, 2021, 11:44:15 AM10/20/21
to blink-dev

Mathias Bynens

unread,
Oct 20, 2021, 12:10:36 PM10/20/21
to Will Cassella, blink-dev
Please follow https://goo.gle/devtools-checklist and elaborate on this a little bit. Per the guide, we need to ensure DevTools supports basic editing of this new media query. It looks like this works out of the box in Canary.
 

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/css/mediaqueries/dynamic-range.html


Flag name

CSSDynamicRangeMediaQueries

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1224711

Estimated milestones

97


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5680926106320896

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BF%3DP4hQtag7Ja_7HF4jRHbuC8h5-_0TzjoJvVEMHmrUeZYW9g%40mail.gmail.com.

Will Cassella

unread,
Oct 21, 2021, 1:01:34 AM10/21/21
to blink-dev, Mathias Bynens, blink-dev, Will Cassella
Thanks for the feedback! I've updated that section:

Debuggability

Styles with these media queries can be viewed and edited in the devtools frontend, albeit without proper highlighting. I've created pull requests on the relevant libraries used in the devtools frontend to enable this. https://github.com/stylelint/stylelint/pull/5613 https://github.com/codemirror/CodeMirror/pull/6803


On Wednesday, October 20, 2021 at 9:10:36 AM UTC-7 Mathias Bynens wrote:
On Wed, Oct 20, 2021 at 5:44 PM Will Cassella <cas...@chromium.org> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Yoav Weiss

unread,
Oct 21, 2021, 2:27:20 AM10/21/21
to Will Cassella, blink-dev, Mathias Bynens
On Thu, Oct 21, 2021 at 7:01 AM Will Cassella <cas...@chromium.org> wrote:
Thanks for the feedback! I've updated that section:

Debuggability

Styles with these media queries can be viewed and edited in the devtools frontend, albeit without proper highlighting. I've created pull requests on the relevant libraries used in the devtools frontend to enable this. https://github.com/stylelint/stylelint/pull/5613 https://github.com/codemirror/CodeMirror/pull/6803


On Wednesday, October 20, 2021 at 9:10:36 AM UTC-7 Mathias Bynens wrote:
On Wed, Oct 20, 2021 at 5:44 PM Will Cassella <cas...@chromium.org> wrote:


Explainer

Adds MediaQueries for detecting HDR vs HDR displays
https://www.w3.org/TR/mediaqueries-5/#dynamic-range
https://www.w3.org/TR/mediaqueries-5/#video-dynamic-range

Specification

https://www.w3.org/TR/mediaqueries-5/#dynamic-range

Summary

Adds media queries to CSS which allow a page to detect the current display device’s support for HDR. This feature adds two new CSS media queries: 'dynamic-range' and 'video-dynamic-range', both of which may be one of 'standard' or 'high'. Chrome will resolve these queries according to the capabilities of the display device the browser window is currently positioned on, allowing pages to toggle CSS rules accordingly or respond in Javascript via 'window.matchMedia()'.



Blink component

Blink>CSS

Motivation

As HDR-supported displays become more common, web developers need ways to enable HDR content on their web pages without compromising the experience for users of non-HDR displays, or mixed-HDR multi-display setups. CSS already provides the 'media query' concept for toggling rules based on display device characteristics, and this feature extends that set of queries to enable detecting HDR support on the current display device.



Initial public proposal



TAG review

Not Filed. This is an incremental change to CSS Media Queries, already adopted by CSS WG.

I agree a TAG review is not needed for the `dynamic-range` MQ, as it's shipped in Safari and adopted by the CSSWG.
The video variant however doesn't meet that criteria. Was the concept of `video-*` MQs discussed with the TAG? Are there other `video-*` MQs that are already shipped?
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6655cbcd-90a1-4b34-a332-5adeada4b53fn%40chromium.org.

Fernando Serboncini

unread,
Oct 21, 2021, 12:38:33 PM10/21/21
to Will Cassella, blin...@chromium.org
Is there any signal from WebKit about video-* specifically?

Also, are we assuming that the current issue on CSSWG (and the implementation warning) about video-* numerical properties will have no impact on this?
I.e., Is it just about the units or is there a chance that the whole video-* approach may be completely changed?

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKj4DkD1-oS5OSZye8DwcGhdrYVwKYv3omYOwE0p-WCm3L77iw%40mail.gmail.com.

Will Cassella

unread,
Oct 21, 2021, 1:55:59 PM10/21/21
to Fernando Serboncini, blink-dev
I created a thread in the webkit-dev mailing list asking for clarification on their status on video-dynamic-range.
Reading the discussion on that GitHub thread, I don't think that should have any effect on this MQ since it's unitless, and the primary concern there is just inconsistencies with units.

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/OpUsOWnnN6c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADp2-T87%3DwjHw-M1TUHQTiPN26WyXijkxzcrO2XXezCHH8sY4g%40mail.gmail.com.

David Baron

unread,
Oct 21, 2021, 1:59:46 PM10/21/21
to Will Cassella, blink-dev
The spec requires that "The combination of the User Agent and the output device fulfill all of the following criteria" when describing what it means to be high dynamic-range.  Since Chromium doesn't support wide-gamut colors in CSS, HTML, or Canvas, I think it's probably incorrect to report that (dynamic-range: high) is true based only on the device, which is what it looks to me like the current code does.  Admittedly, the spec could probably use some clarification as to what it means for the User Agent to fulfill the criteria for both the dynamic-range and video-dynamic-range queries, but my understanding of what the spec is trying to say is that Chrome probably shouldn't say that (dynamic-range: high) is true until it supports wide-gamut colors in at least some and maybe all of those contexts.

-David

On Wed, Oct 20, 2021 at 11:41 AM 'Will Cassella' via blink-dev <blin...@chromium.org> wrote:
--

Will Cassella

unread,
Oct 21, 2021, 7:03:19 PM10/21/21
to David Baron, Will Cassella, blink-dev
I accidentally posted this topic twice (once from my @google.com account, and again from my @chromium.org account), so I'll re-post your question in the thread originating from my @chromium.org account and respond there, sorry for the confusion!

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/OpUsOWnnN6c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3gHMxyCBxWphPTg4mP8RNbsJQC30pAaB4-P4%3D-FLA4B0w%40mail.gmail.com.

Will Cassella

unread,
Oct 21, 2021, 7:03:29 PM10/21/21
to Yoav Weiss, blink-dev, Mathias Bynens, David Baron
Copying over from the other thread (trying to continue the discussion here):

The spec requires that "The combination of the User Agent and the output device fulfill all of the following criteria" when describing what it means to be high dynamic-range.  Since Chromium doesn't support wide-gamut colors in CSS, HTML, or Canvas, I think it's probably incorrect to report that (dynamic-range: high) is true based only on the device, which is what it looks to me like the current code does.  Admittedly, the spec could probably use some clarification as to what it means for the User Agent to fulfill the criteria for both the dynamic-range and video-dynamic-range queries, but my understanding of what the spec is trying to say is that Chrome probably shouldn't say that (dynamic-range: high) is true until it supports wide-gamut colors in at least some and maybe all of those contexts.

I think you're right that the spec needs some clarification, since we're trying to incrementally enable adoption of HDR on the web the intent isn't to signal that HDR is supported by all APIs. We do already support HDR in some scenarios, such as the <video> element, so having these queries exist to let developers detect display capabilities is already useful.

David Baron

unread,
Oct 22, 2021, 10:04:08 AM10/22/21
to Will Cassella, Yoav Weiss, blink-dev, Mathias Bynens
This sounds like exactly the sort of case where an implementation should report (dynamic-range: standard) and (video-dynamic-range: high).  It would be great to see the spec clarified to make it clearer what UA support is expected for each, though.

-David

Fernando Serboncini

unread,
Oct 22, 2021, 4:19:44 PM10/22/21
to David Baron, Will Cassella, Yoav Weiss, blink-dev, Mathias Bynens
[coming from the other thread... :) ]

+1 to what David said. It doesn't seem that returning dynamic-range: high right now would be useful.

The spec could use some clarification:
- clarify if those criterias need to be supported on different conditions: CSS, images, canvas, ...
- clarify if the criterias need to be supported for both with/without alpha (afaik there may be implementation differences there, but I may be wrong here).
- I wonder if the definitions of high contrast/peak brightness should match the industry definitions for HDR displays? I'm not an expert, but I know those exist. 
I think it's potentially okay to ignore those definitions, but I'd ask for a rationale here.

I think it's a great thing to summarize hdr into a single media query, but the risk here would be to release a semantic that guarantees very little, and therefore is not useful in the long run.


To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3gbBzJUttDWuWDRFWnP-w7%3DP4G7TrBPJiU%3DyizEH2%2Bz_Q%40mail.gmail.com.

Yoav Weiss

unread,
Oct 28, 2021, 2:38:36 PM10/28/21
to blink-dev, Fernando Serboncini, Will Cassella, Yoav Weiss, blink-dev, Mathias Bynens, David Baron
On Friday, October 22, 2021 at 10:19:44 PM UTC+2 Fernando Serboncini wrote:
[coming from the other thread... :) ]

+1 to what David said. It doesn't seem that returning dynamic-range: high right now would be useful.

The spec could use some clarification:
- clarify if those criterias need to be supported on different conditions: CSS, images, canvas, ...
- clarify if the criterias need to be supported for both with/without alpha (afaik there may be implementation differences there, but I may be wrong here).
- I wonder if the definitions of high contrast/peak brightness should match the industry definitions for HDR displays? I'm not an expert, but I know those exist. 
I think it's potentially okay to ignore those definitions, but I'd ask for a rationale here.

I think it's a great thing to summarize hdr into a single media query, but the risk here would be to release a semantic that guarantees very little, and therefore is not useful in the long run.


On Fri, Oct 22, 2021 at 10:04 AM David Baron <dba...@chromium.org> wrote:
This sounds like exactly the sort of case where an implementation should report (dynamic-range: standard) and (video-dynamic-range: high).  It would be great to see the spec clarified to make it clearer what UA support is expected for each, though.

-David

On Thu, Oct 21, 2021 at 7:03 PM Will Cassella <cas...@chromium.org> wrote:
Copying over from the other thread (trying to continue the discussion here):

The spec requires that "The combination of the User Agent and the output device fulfill all of the following criteria" when describing what it means to be high dynamic-range.  Since Chromium doesn't support wide-gamut colors in CSS, HTML, or Canvas

David - I'm likely missing something here, but I thought (based on this thread) that we do have wide-gamut support in CSS, HTML and Canvas.
Are you saying we don't support this due to lack of color level 4 support? Or something else?

I also didn't interpret the spec as saying anything about gamut (but rather about color depth), although it may be possible that wide gamuts and high color depth correlate 1:1. Can you clarify if that's what you meant?
 
, I think it's probably incorrect to report that (dynamic-range: high) is true based only on the device, which is what it looks to me like the current code does.  Admittedly, the spec could probably use some clarification as to what it means for the User Agent to fulfill the criteria for both the dynamic-range and video-dynamic-range queries, but my understanding of what the spec is trying to say is that Chrome probably shouldn't say that (dynamic-range: high) is true until it supports wide-gamut colors in at least some and maybe all of those contexts.

I think you're right that the spec needs some clarification, since we're trying to incrementally enable adoption of HDR on the web the intent isn't to signal that HDR is supported by all APIs. We do already support HDR in some scenarios, such as the <video> element, so having these queries exist to let developers detect display capabilities is already useful.

On Wed, Oct 20, 2021 at 11:27 PM Yoav Weiss <yoav...@chromium.org> wrote:
On Thu, Oct 21, 2021 at 7:01 AM Will Cassella <cas...@chromium.org> wrote:
Thanks for the feedback! I've updated that section:

Debuggability

Styles with these media queries can be viewed and edited in the devtools frontend, albeit without proper highlighting. I've created pull requests on the relevant libraries used in the devtools frontend to enable this. https://github.com/stylelint/stylelint/pull/5613 https://github.com/codemirror/CodeMirror/pull/6803


On Wednesday, October 20, 2021 at 9:10:36 AM UTC-7 Mathias Bynens wrote:
On Wed, Oct 20, 2021 at 5:44 PM Will Cassella <cas...@chromium.org> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

David Baron

unread,
Oct 28, 2021, 3:04:54 PM10/28/21
to Yoav Weiss, blink-dev, Fernando Serboncini, Will Cassella, Mathias Bynens
On Thu, Oct 28, 2021 at 2:38 PM Yoav Weiss <yoav...@chromium.org> wrote:


On Friday, October 22, 2021 at 10:19:44 PM UTC+2 Fernando Serboncini wrote:
[coming from the other thread... :) ]

+1 to what David said. It doesn't seem that returning dynamic-range: high right now would be useful.

The spec could use some clarification:
- clarify if those criterias need to be supported on different conditions: CSS, images, canvas, ...
- clarify if the criterias need to be supported for both with/without alpha (afaik there may be implementation differences there, but I may be wrong here).
- I wonder if the definitions of high contrast/peak brightness should match the industry definitions for HDR displays? I'm not an expert, but I know those exist. 
I think it's potentially okay to ignore those definitions, but I'd ask for a rationale here.

I think it's a great thing to summarize hdr into a single media query, but the risk here would be to release a semantic that guarantees very little, and therefore is not useful in the long run.


On Fri, Oct 22, 2021 at 10:04 AM David Baron <dba...@chromium.org> wrote:
This sounds like exactly the sort of case where an implementation should report (dynamic-range: standard) and (video-dynamic-range: high).  It would be great to see the spec clarified to make it clearer what UA support is expected for each, though.

-David

On Thu, Oct 21, 2021 at 7:03 PM Will Cassella <cas...@chromium.org> wrote:
Copying over from the other thread (trying to continue the discussion here):

The spec requires that "The combination of the User Agent and the output device fulfill all of the following criteria" when describing what it means to be high dynamic-range.  Since Chromium doesn't support wide-gamut colors in CSS, HTML, or Canvas

David - I'm likely missing something here, but I thought (based on this thread) that we do have wide-gamut support in CSS, HTML and Canvas.
Are you saying we don't support this due to lack of color level 4 support? Or something else?

That intent makes it sound like we have wide-gamut support for canvas (though others would be able to speak more authoritatively about it) but I don't think we do in HTML or CSS.  (I also should have included images in my list, though I think if we have support with canvas then we probably do for images as well.).)
 
I also didn't interpret the spec as saying anything about gamut (but rather about color depth), although it may be possible that wide gamuts and high color depth correlate 1:1. Can you clarify if that's what you meant?

I should have been more precise about meeting the spec's requirements rather than just using the term "wide-gamut".  You're correct that it's not 1:1, though I think that in practice an implementation is unlikely to meet the spec's requirements on color depth and contrast ratio without supporting colors beyond sRGB's gamut.

(I also suspect we may not meet the color depth requirement in the spec, perhaps not for canvas or images as well.)

-David
 
 
, I think it's probably incorrect to report that (dynamic-range: high) is true based only on the device, which is what it looks to me like the current code does.  Admittedly, the spec could probably use some clarification as to what it means for the User Agent to fulfill the criteria for both the dynamic-range and video-dynamic-range queries, but my understanding of what the spec is trying to say is that Chrome probably shouldn't say that (dynamic-range: high) is true until it supports wide-gamut colors in at least some and maybe all of those contexts.

I think you're right that the spec needs some clarification, since we're trying to incrementally enable adoption of HDR on the web the intent isn't to signal that HDR is supported by all APIs. We do already support HDR in some scenarios, such as the <video> element, so having these queries exist to let developers detect display capabilities is already useful.

On Wed, Oct 20, 2021 at 11:27 PM Yoav Weiss <yoav...@chromium.org> wrote:
On Thu, Oct 21, 2021 at 7:01 AM Will Cassella <cas...@chromium.org> wrote:
Thanks for the feedback! I've updated that section:

Debuggability

Styles with these media queries can be viewed and edited in the devtools frontend, albeit without proper highlighting. I've created pull requests on the relevant libraries used in the devtools frontend to enable this. https://github.com/stylelint/stylelint/pull/5613 https://github.com/codemirror/CodeMirror/pull/6803


On Wednesday, October 20, 2021 at 9:10:36 AM UTC-7 Mathias Bynens wrote:
On Wed, Oct 20, 2021 at 5:44 PM Will Cassella <cas...@chromium.org> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Chris Harrelson

unread,
Nov 4, 2021, 3:30:41 PM11/4/21
to David Baron, Yoav Weiss, blink-dev, Fernando Serboncini, Will Cassella, Mathias Bynens
Hi, there were some discussions of the spec, and other questions, so far in the thread. Will, could you summarize the current status? Thanks.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3iqUMAHBvXyqNQ8p2QPdSOTc7u4o8waE5GZ80_Aehnw%3DQ%40mail.gmail.com.

Will Cassella

unread,
Nov 5, 2021, 6:45:57 PM11/5/21
to Chris Harrelson, David Baron, Yoav Weiss, blink-dev, Fernando Serboncini, Mathias Bynens, Chrome Cunningham
Hey Chris,

I’ve filed an issue on the csswg-drafts repo asking for the wording to be adjusted in the spec. In the original discussion surrounding this media query, the intent was for this to be reflective of the display device and not an overall representation of the user agent's capabilities. I did some research into Safari's implementation of this query, and while they similarly implement dynamic-range: high with respect to the display device, their treatment of dynamic-range: standard isn't in line with the spec (it always returns true, even on HDR displays). After some discussion with +chcunningham, we think this may be the correct path forward for Chrome as well as sites are already using this query on Safari, and it makes sense from a backwards compatibility standpoint (how should dynamic-range: high react if an ultra-high enum is ever added?). I'm still waiting to get feedback on the Github issue I filed at the moment.

Thanks,
Will

Chris Harrelson

unread,
Nov 18, 2021, 3:05:01 PM11/18/21
to Will Cassella, David Baron, Yoav Weiss, blink-dev, Fernando Serboncini, Mathias Bynens, Chrome Cunningham
Ok thanks. It looks like the CSSWG discussed the issue and there still needs to be more discussion before a resolution is achieved, so we'll wait for that.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BF%3DP4jQTkmPvDLBM_t_0S%3D6k70UVdcszQ01hQELmE%3Dfp81JPA%40mail.gmail.com.

Will Cassella

unread,
Nov 24, 2021, 3:33:08 PM11/24/21
to Chris Harrelson, David Baron, Yoav Weiss, blink-dev, Fernando Serboncini, Mathias Bynens, Chrome Cunningham
There's been movement on the Github issue regarding the spec, and the consensus is that the way Safari has done things (having dynamic-range: standard always return true, and dynamic-range: high be evaluated against the capabilities of the display) is what we should be doing, and the wording of the spec should be adjusted as well. I've updated our implementation to reflect that.

Yoav Weiss

unread,
Nov 25, 2021, 3:51:35 AM11/25/21
to Will Cassella, Chris Harrelson, David Baron, blink-dev, Fernando Serboncini, Mathias Bynens, Chrome Cunningham
Thanks for the update!

Repeating my question from above, that probably got lost along the way: Was the concept of `video-*` MQs discussed with the TAG? Are there other `video-*` MQs that are already shipped?

Will Cassella

unread,
Nov 29, 2021, 7:38:13 PM11/29/21
to Yoav Weiss, Chris Harrelson, David Baron, blink-dev, Fernando Serboncini, Mathias Bynens, Chrome Cunningham
Sorry for missing that! There's a section in the spec for 'video-*' MQ's, and while this is the first to be implemented in Chrome there are others detailed there (most notably video-color-gamut). The 'video-*' MQ concept has not been discussed with TAG, but it was discussed at great length between the media and CSS WGs. You can see the start of that discussion in the media WG here, and its jump to the CSS WG here. In both places we had representation from different user agents and domain experts.

Yoav Weiss

unread,
Dec 1, 2021, 5:47:06 AM12/1/21
to blink-dev, Will Cassella, Chris Harrelson, David Baron, blink-dev, Fernando Serboncini, Mathias Bynens, Chrome Cunningham, Yoav Weiss
Since we're talking about adding a full new class of MQs, that seems worthy of a TAG discussion.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscr