W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2020

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

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 20 May 2020 17:01:05 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-631602140-1589994064-sysbot+gh@w3.org>
The CSS Working Group just discussed `[mediaqueries] length units in video-* media features.`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [mediaqueries] length units in video-* media features.<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5044<br>
&lt;dael> florian: As we know length in CSS are interesting. All units fixed ratio to each other and either to phsyical measurements or pixel. For length in video what are we expecting?<br>
&lt;dael> florian: I think a third one. video width and video-height if this is 4k I'm expecting an answer in terms of pixels.<br>
&lt;rego> dholbert: still you get overflow there, in both directions (not very useful to me); and also you can have the very same case in flexbox https://jsfiddle.net/h8u53ows/ (that will work different only for row gaps)<br>
&lt;dael> florian: I don't think we discussed use case and usage in much detail. Do we expect video plane into angular css pixel? Maybe, but if that's the case do we need this? If it's the phsyical pixel we need to write that<br>
&lt;dael> nigel: For using video pixels I think something exists in TTML specs where you can define root container region and say how big it is in pixels. If you're not doing that you get pixel resolution of video. So you can spec location and size which defines where you want stuff<br>
&lt;dael> nigel: Similarly define font size in pixels. Very typicaly to use video pixels when authoring in that sense<br>
&lt;dael> nigel: Bit of a push away b/c makes mroe sense to use relative dimensions to the rendering area as a %. For font size calc became complicated using % fonts based on parent element.<br>
&lt;dael> nigel: We introduce rw and rh which is relative to rendering area, not overall page<br>
&lt;dael> florian: Another confusing thing is we're defining width and heigh of video plane but not saying what's in there. Assumption is that's only hardware generated so you wouldn't size fonts, but maybe 'm wrong?<br>
&lt;dael> chris n: I think you're right. In full screen we're interested in knowing device resolution so we can select appropriate media representation for streaming<br>
&lt;dholbert> rego, (right, there's overflow, but it's consistent/symmetric for grid there, and it doesn't have any percentages depending on content-measurement, which makes it a case that feels less terrible. *shrug*)<br>
&lt;dael> chris n: returning in device pixels is ideal<br>
&lt;dael> florian: But for images we're not doing that but asking API to describe the sources and let the UA pick the appropriate one. Are we not doing that here? I believe you can desc multiple sources, no?<br>
&lt;dael> chris n: If you're using video element you could. If your'e using media source extensions that becomes web app's responsibility not the UA's<br>
&lt;dael> Rossen_: We're at top of hour<br>
&lt;dael> florian: I think I have a direction, but we should explore on github<br>
&lt;dael> Rossen_: I would encourage chris and nigel to interact on that issue. You've got the people to solve this<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5044#issuecomment-631602140 using your GitHub account
Received on Wednesday, 20 May 2020 17:01:08 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:07 UTC