Re: [csswg-drafts] [mediaqueries] length units in video-* media features. (#5044)

Hey Gang, I want to follow up from the CSS : Media WG call.

The call helped me to understand some issues with specifying that video- queries use device pixels: 1) fixing resolution to 1 dppx is unusual 2) what do we do with 'em' 3) what do we do for fullscreen vs not

I have a few ideas. I'm not an expert in CSS units... hopefully this isn't too naive. 

What if we spec that video-* uses css pixels just like non-video, and just leave implementers with the _option_ to setup their video plane w/ resolution = 1dppx such that this is effectively device pixels where desired. IIUC, this isn't really novel. Implementers of existing media queries already enjoy this flexibility. 1dppx is valid and even common. The question of 'what do for em/fullscreen' is then answered: same thing we do already under these conditions elsewhere. 

I think this is also more correct for non-TV implementers. When you don't have a separate video plane, the simplest design is that video-* answers match that of non-video. 

I do see a potential wart (but I think its manageable). The earlier idea to spec that its actually device pixels makes media queries straightforward for callers. Folks like Netflix have a fixed number of resolutions available for a given title, so they only need a handful min-video-height queries). But if resolution is allowed to vary, it seems you have to binary search that value first to know what scale factor to apply. Is there some MQ syntax sugar that makes this easy? Even a true binary search seems pretty doable. 

Alternatively, we could take all of the above arguments about using CSS pixels and flexible resolution, and carry those to a proposal for Screen attributes. No binary search. On the call, I think a rep from Apple (was it @smfr ?) indicated this raised fingerprinting concerns. The binary search for this info is pretty trivial, so MQ seems not meaningfully more privacy protecting? 

GitHub Notification of comment by chcunningham
Please view or discuss this issue at using your GitHub account

Received on Friday, 17 July 2020 20:28:46 UTC