W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2019

Re: [csswg-drafts] [cssom-1][mediaqueries-5][css-color] Dealing with bi-plane (video/graphics) when reporting values (#4471)

From: Vi Nguyen via GitHub <sysbot+gh@w3.org>
Date: Sun, 03 Nov 2019 21:09:21 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-549178832-1572815360-sysbot+gh@w3.org>
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`  // measured in device pixels
*    `length`  // measured in device pixels
*    `resolution`  // measured in device pixels
*    `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?

GitHub Notification of comment by vi-dot-cpp
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4471#issuecomment-549178832 using your GitHub account
Received on Sunday, 3 November 2019 21:09:23 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:56 UTC