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

The CSS Working Group just discussed `MediaQueries length units in video-*`, and agreed to the following:

* `RESOLVED: Drop video-width/height/resolution media queries`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: MediaQueries length units in video-*<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/5044<br>
&lt;fantasai> florian: Issue has evolved since opened<br>
&lt;fantasai> florian: reminder, we specified video-width/height/resolution<br>
&lt;fantasai> florian: video prefix is about video playing that some devices like TVs have, where they superimpose a special canvas with different characteristics for playing video<br>
&lt;fantasai> florian: About a year ago we were talking about this and thinking that actually, maybe MQ isn't what's wanted<br>
&lt;fantasai> florian: The typical query of width is about whether bigger or smaller than some value<br>
&lt;fantasai> florian: but not used for that<br>
&lt;fantasai> florian: use cases were that ppl wanted to ask "what is the size of the screen, in physical pixels"<br>
&lt;fantasai> florian: The only way to do via MQ is via binary search in MQ, which is not great<br>
&lt;fantasai> florian: So conclusion of discussion is not to have an MQ, and instead have some extension to CSSOM where you can query for the pixel ratio of the video playing of the device<br>
&lt;fantasai> florian: since can already know size of viewport, can get the size of the whole screen<br>
&lt;fantasai> florian: or if interested in size of an element, can go from the size of that element<br>
&lt;fantasai> florian: So the suggested resolution for MQ is to remove video-width/height/resolution MQ<br>
&lt;Rossen_> q?<br>
&lt;fantasai> florian: and another resolution would be for CSSOM to add window.deviceVideoPixelRatio<br>
&lt;fantasai> Rossen_: Opinions on this?<br>
&lt;fantasai> smfr: I'm a little concerned about multi-screen systems<br>
&lt;fantasai> smfr: window is associated with a single screen<br>
&lt;fantasai> smfr: if showing video, is it on the same screen/window?<br>
&lt;fantasai> smfr: idk how to know that<br>
&lt;fantasai> smfr: imagine you have two screens, right hand is dedicated to video presentation<br>
&lt;fantasai> smfr: somehow magically when you present video, it shows up on the right<br>
&lt;fantasai> smfr: but window object is associated with the left hand screen<br>
&lt;fantasai> smfr: so would be weird if it reported characteristics of right hand screen<br>
&lt;fantasai> ???: Is this possible today?<br>
&lt;fantasai> smfr: UA thing, UA could decide to send fullscreen video to a particular screen<br>
&lt;astearns> s/???/chrisneedham/<br>
&lt;fantasai> florian: I think as far as TVs are concerned, and things with this multiplane rendering, it doesn't behave the way you described<br>
&lt;fantasai> florian: more general browsers/setups, could be other setups<br>
&lt;fantasai> florian: the window object is probably not designed for that, but this is a more generic problem than video specifically<br>
&lt;fantasai> florian: 2nd Screen effort is trying to deal with that<br>
&lt;fantasai> florian: but for the TV use case, I don't believe that's how they work<br>
&lt;astearns> s/chrisneedham/cpn/<br>
&lt;fantasai> Rossen_: to go one step further, in conjunction with some of the newer foldables and dual-screen efforts<br>
&lt;fantasai> Rossen_: I know of at least one effort that is work happeneing on ??? that have to do with dividing up the window into multiple segments<br>
&lt;fantasai> Rossen_: multiple screen divided by segments or hinge<br>
&lt;fantasai> Rossen_: here we have one window spanning two surfaces<br>
&lt;fantasai> Rossen_: video having controls on one different screen is very typical<br>
&lt;fantasai> florian: Does this device have a multiplane rendering thing?<br>
&lt;fantasai> florian: typically TVs do this, typical screens don't have two planes that can be queried separately<br>
&lt;fantasai> Rossen_: we have one window object that will be present on both physical screens<br>
&lt;fantasai> Rossen_: is expectation that devicePixelRatio returns ...<br>
&lt;fantasai> florian: I think the question is legit, if you have this multiplane thing with two resolutions on one screen, we have this problem for the window object in general<br>
&lt;fantasai> florian: this is a good problem to address if such devices exist, but there's nothing specific to video about it<br>
&lt;fantasai> Rossen_: there are some laptops that have a pane over the keyboard, so you can present into those<br>
&lt;fantasai> Rossen_: but might be represented by two different screen objects<br>
&lt;florian> fantasai: don't smfr 's concern apply to the regular to the regular device pixel ratio as well?<br>
&lt;florian> fantasai: if so, we need to address it there as well<br>
&lt;fantasai> smfr: devicePixelRatio doesn't have this same issue<br>
&lt;fantasai> smfr: if I drag window over, devicePixelRatio will change<br>
&lt;Rossen_> fantasai: I understand the concern. We need to address the multi-resolutions for devicePR and other API. Adding a parallel API for these is what makes most sense.<br>
&lt;fantasai> smfr: issue with video one is that video presentation is special, and UA chooses that it will be displayed in magic extra plane with different properties<br>
&lt;fantasai> florian: We're not talking about picture in picture or displaying window in other places<br>
&lt;fantasai> florian: but for TVs, they have two framebuffers layered over each other in the same spot<br>
&lt;fantasai> florian: They have the normal layer transparent, punch video through to underlying layer<br>
&lt;fantasai> florian: which has different resolution<br>
&lt;fantasai> florian: in current devices, this would be on the same scree<br>
&lt;Rossen_> ack fantasai<br>
&lt;fantasai> florian: a browser could have two different videos on different screens, but that's a very different setup than here<br>
&lt;fantasai> smfr: I understand, I just don't want us to design a problem for foldables<br>
&lt;fantasai> florian: Let's just resolve to remove the MQ for now<br>
&lt;fantasai> florian: and maybe we can open an issue for the deviceVideoPixelRatio<br>
&lt;fantasai> florian: I don't quite see the problem, because whatever problem you're describing seems to apply equally to devicePixelRatio<br>
&lt;fantasai> Rossen_: Anyone from the video group want both resolutions?<br>
&lt;fantasai> fantasai: smfr, why does your concern apply to deviceVideoPixelRatio and not devicePixelRatio?<br>
&lt;fantasai> smfr: Because it applies to fullscreen, which is more likely to be on a different screen<br>
&lt;fantasai> florian: This isn't necessarily about fullscreen video.<br>
&lt;Rossen_> ack fantasai<br>
&lt;fantasai> florian: if you have youtube playing in the middle of your web page, you would apply this ratio within the video<br>
&lt;fantasai> smfr: No, I don't think so, I think it only applies to fullscreen<br>
&lt;fantasai> Rossen_: If presentation spans multiple screens, e.g. projector, very different characteristics than PC, wouldn't problem apply to that as well?<br>
&lt;fantasai> florian: And doesn't necessarily apply to fullscreen only, that's up to the author<br>
&lt;fantasai> florian: Yes, youtube or hulu or whatever video service can be played fullscreen sometimes<br>
&lt;fantasai> florian: but might also want to query in normal rendering mode<br>
&lt;fantasai> florian: and since hardware accelerated, would still go into special plane<br>
&lt;fantasai> smfr: wouldn't be the case in Apple devices<br>
&lt;fantasai> smfr: I think we should ask experts for feedback<br>
&lt;fantasai> smfr: I think it would be very confusing for author<br>
&lt;fantasai> Rossen_: Let's go with resolving to drop the MQ<br>
&lt;fantasai> Rossen_: it's clear we need to work more on the rest of the API<br>
&lt;fantasai> Rossen_: Any objections to dropping MQ?<br>
&lt;fantasai> smfr: I support that<br>
&lt;fantasai> RESOLVED: Drop video-width/height/resolution media queries<br>
&lt;fantasai> Rossen_: send rest of conversation back to the issue<br>
&lt;fantasai> florian: Should I retitle the issue, or file a new one?<br>
&lt;fantasai> Rossen_: new issue might be helpful to have clear slate, but history etc. might be useful<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5044#issuecomment-995006227 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 15 December 2021 17:26:54 UTC