- From: chcunningham via GitHub <sysbot+gh@w3.org>
- Date: Tue, 09 Nov 2021 19:41:39 +0000
- To: public-css-archive@w3.org
> 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 operating separate feature detection, choosing whatever method is most idiomatic for their respective domains. -- GitHub Notification of comment by chcunningham Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6793#issuecomment-964476105 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 9 November 2021 19:41:41 UTC