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

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

From: Greg Whitworth via GitHub <sysbot+gh@w3.org>
Date: Wed, 30 Oct 2019 00:04:05 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-514307321-1572393844-sysbot+gh@w3.org>
gregwhitworth has just created a new issue for https://github.com/w3c/csswg-drafts:

== [cssom-1][mediaqueries-5][css-color] Dealing with bi-plane (video/graphics) when reporting values ==
Hey folks,

Over in the Media WG we're trying to help web developers serving media content provide the best end user experience and we've encountered an interesting scenario that we'd like to get the CSSWG's feedback on. @chcunningham did a great job summarizing the *very long* discussion down to the various options we feel are available [here](https://github.com/w3c/media-capabilities/issues/135#issuecomment-547673815).

> New summary:
> For most UA implementations, video is like any other element in terms of its participation in the CSS and Document object model. But TVs (and cast dongles) have distinct code/hw paths ("planes") for rendering video vs other elements ("graphics"). Generally, video can be rendered at the devices native resolution (e.g. 4K) and can take full advantage of the devices HDR/WCG capabilities, while graphics are likely rasterized at a much lower resolution (720p or 1080p) with ~sRGB 8 bit color. Many TVs have this problem. TVs are an very important media consumer. This problem is not predicted to work itself out with time.
>With this in mind, we aim to design an API that works for TV and non-TV UAs to signal when a Screen supports HDR and/or 4K resolution. We've discussed 3 approaches.
>**1. clean but half-broken:** Add Screen.hdrSupported alongside existing Screen.width and height properties
>Like width and height, hdrSupported is assumed to describe hdr support for video and graphics alike. This is a natural extension of the current Screen object, but it offers TVs no way to signal their distinct video vs graphics capabilities.
>TVs can pick one plane to describe and lie about the other. Lying is obviously unpleasant, and it has various trade-offs / breaks depending on which plane is reported and specific use cases (covered earlier in this thread).
>**2. verbose but functional:** Add video* prefixed media queries media features for the video plane. The running list of features to prefix includes: color, color-gamut, color-index, device-aspect-ratio, resolution, height, width and (new) hdrSupported
>TVs will use the video* prefixed versions to surface the hdr and 4k support for video, while signalling sdr and 720p-1080p for graphics via the existing (unprefixed) properties. For non-TVs, the video* prefixed values will all be the same as their unprefixed counterparts.
>This is equivalent (and could accompany) an earlier proposal to add a new "video" property bag to Screen for video plane properties.
>This completely solves the problem. It also standardizes this TV quirk into the web platform in a highly visible manner.

>**3. clean and functional, but requires new semantics media types:** Add a new media-type (e.g. 'Video') where TV's could report the features of their video plane while continuing to use 'Screen' for graphics. Add a new hdrSupported media feature alongside existing width and height features, all of which would be accessible from both the Screen and Video media-types.
>This still standardizes the two-plane quirk, but hopefully with less of a footprint (if you're not writing a TV app, you might not even notice).

>New semantics required because we need Screen and Video to both be match-able by a given UA (where types historically are mutually exclusive). Media types are somewhat deprecated/discouraged - unclear whether this might breath some life back into them.

We'd love to get your feedback on the proposals. Thanks.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4471 using your GitHub account
Received on Wednesday, 30 October 2019 00:04:06 UTC

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