- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jun 2020 16:30:20 +0000
- To: public-css-archive@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>
<dael> Topic: [mediaqueries] length units in video-* media features.<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/5044<br>
<dael> florian: I can remind where we're at. Not sure how to solve.<br>
<dael> florian: We have a set of MQ which are specific to video. I'm going to focus on width but have height too<br>
<dael> florian: Just like normal webpages render to viewport, some players render video to a separate plane. We have video-width and like that<br>
<dael> florian: Proposed with same syntax as normal width and height. On devices where planes are different they accept same syntax. THat implies they take any kind of length and what do those units mean? Goal is the for a 4k device it would return 4k.<br>
<dael> florian: Should it be pixel with a different def and if so what do the others mean. SHould it be a unitless, separate unit. Underlying that is how are they expected to be used<br>
<dael> TabAtkins: For the use case people want to know phsyical density of screen. If it's a 4k screen they want 4k video no matter if it's full screen<br>
<dael> TabAtkins: Given that I agree with fantasai we should do an int<br>
<astearns> q?<br>
<hober> q+<br>
<astearns> ack hober<br>
<hober> q?<br>
<dael> hober: I think I would like there to be a princple for answering questions like this. Here on a device with only one plane in a UA that supports video prefix they should be same as if alias for eq.<br>
<dael> florian: That's where we started but introduces problems<br>
<dael> TabAtkins: Explain why useful principle?<br>
<dael> hober: Sure. I think...I worry this 2 plane model is a contingent fact of present limited hardware.<br>
<AmeliaBR> q+<br>
<florian> q+<br>
<dael> hober: I would like in the future if this hardware goes away I would like the maintence burden for browser to be minimized. Great if simple alias. Working backwards is how I get here.<br>
<astearns> ack AmeliaBR<br>
<dael> hober: Future is longer than past and I doubt devices with these characteristics are a thing in 100 year, but I hope CSS is a thing in 100 years and I hope we don't burden future impl<br>
<emilio> hober++<br>
<dael> AmeliaBR: Following up on hober comment, I do agree we shouldn't have similar but different things. Px with a different interpretation is dangerous.<br>
<dael> AmeliaBR: I don't know if that meanst hey have to be alias but we need to think question and purpose of this MQ. If we do the int value where it gives you raw dots on the screen we need to ask how is that interp by all UAs, even ones not doing special video rendering<br>
<dael> AmeliaBR: Does defining facotr become this isn't about sep plane but this is a way to get raw pixel resolution to render graphics and will that be expected in all UAs?<br>
<dael> AmeliaBR: If it isn't just an alias for existing width and height we have to talk about what does it means and what's the purpose<br>
<astearns> ack florian<br>
<dael> florian: A few things. Minimizing maintainence burden is good. If we define this as non or similar I think it's not heigh.<br>
<dael> florian: Mapping to an alias is odd. You want ot deliver 4k on a 4k screen you don't want to deliver 4k if there's one plane.<br>
<AmeliaBR> `<video><source media>`<br>
<emilio> What is the expected usage of this media query?<br>
<dael> florian: Starting to think is it useful as a MQ. It's not to select stylesheets, it's for API things that want to know screen and download assets. Wouldn't this be better as an API?<br>
<dael> AmeliaBR: MQ are used to select video sources in HTML attributes<br>
<dael> florian: For that purpose I think the best practice is not to select on device resolution but desc resolution of videos and let UA choose. This is for the cases you can't do that b/c managing it yourself in JS<br>
<dael> astearns: florian you're suggesting?<br>
<dael> florian: srcset is better for that. I'm thinking this isn't a MQ and this number is exposed in API<br>
<astearns> ack fantasai<br>
<dael> fantasai: Also a question of this is the device...viewport size not device.<br>
<dael> florian: It's device<br>
<plinss> q+<br>
<dael> fantasai: Desc number of pixels or length of viewport. Question if use case if for viewport size or device size. Need to be clear if we need one or both for the use case<br>
<dael> fantasai: We could make something only available in JS but still seems fund. a MQ. Doesn't make sense to create and API that's ntoa. MQ even if we think it's only useful in JS<br>
<faceless2_> q+<br>
<astearns> ack plinss<br>
<dael> florian: MQ don't give numbers, they answer a question. If people want a resolution they have to search the MQ. Seems not great<br>
<dael> plinss: Orthogonal, I want to object to 4k or 4000 because it's a marketing term not an exact specification. It is a hot mess so let's not use it in a technical context.<br>
<astearns> ack faceless2_<br>
<dael> faceless2_: florian people are biary searching MQ to get approx resolution already. Ultimately if you're prop a value to desc phsyical px I can think of multiple issues over the last 6 months that wanted that. IT's a useful problem to solve and not restricted to video<br>
<dael> florian: Then different q. Number of phsyical pixels across the screen on the video plane is different than one across viewport.<br>
<dael> faceless2_: Device with a single screen is it different?<br>
<dael> florian: Yeah, if browser not full screen it's different<br>
<dael> nigel: I got impression idea is combo of queries for that. if you have info about whole device video plane you can do other queries to realize actual viewport is a subsection of that<br>
<dael> astearns: We have video width return px on video plane nad other MQ gives you px width of browser window and we can't convert between I'm not sure how useful<br>
<dael> florian: resolution gives density and that's in MQs<br>
<florian> q?<br>
<florian> q+<br>
<dael> AmeliaBR: One thing to mention, I can't pull exact resolution but org discussion is MQ were part of solution but also going to be CSSOM API that exposed exact numbers. Screen API and screen.video<br>
<dael> AmeliaBR: That people want exact numbers doesn't mean MQ are inappropriate. Might be 2 parallel solutions. Can't remember what we resolved on<br>
<emilio> faceless2_: hmmm, why are people bin-searching media-queries instead of `window.devicePixelRatio` / `window.screen` / `window.{inner,outer}Width`?<br>
<faceless2_> A fair question, I didn't write the library that did it :-) Will dig it up and post here<br>
<dael> florian: Another comment, we used to have device-width and -height MQ in CSS px but we deprecated them for privacy reasons. If we intro this we're re-opening hte problem. It's a trade-off so I don't have a decision, but want to remind people<br>
<dael> smfr: Strong support florian. For srcset the UA picks the source and we should push in that direction so we don't have to expose all device information b/c fignerprinting<br>
<dael> chrisN: Like we discussed src requires knowing the device characteristics to know what media to pick<br>
<dael> florian: API to tell what resolutions are available and you can than tell which to load?<br>
<emilio> q+<br>
<dael> ChrisN: potentially<br>
<dael> florian: With an observer of some kind so if it moves from high to low density screen you get told<br>
<dael> ChrisN: Feels like need to take to media WG. Looking at history and we had 3 options, one of which was to add properties to screen object.<br>
<dael> AmeliaBR: I was reviewing that discussion and last comment was someone saying open a separate issue to discuss how API should look and I don't think that issue was ever filed<br>
<florian> q-<br>
<astearns> ack emilio<br>
<nigel> q+<br>
<dael> emilio: I feel like florian and smfr. It doens't feel to me like using a MQ is right. For video there's a lot UA would want to do. Seems sensible that even if high res screen you want to take low bandwidth into account. Leaving source decision to UA seems better to me and not clear how use MQ<br>
<Rossen_> strong +1<br>
<dael> florian: I suggest we leave this open, go back to media group to talk and with a suggestion to look at discussion for images and how srcset came to be because that was a similar item. People should look and have in back of mind. Doens't mean we have to do same but it's releated<br>
<astearns> ack nigel<br>
<dael> nigel: I want to observe there's an archetectural side. THere's a bunch of MQ about video and some make sense in API and others don't. Need to think about if we want consistent across all or if it makes sense to differ. Video size is an obvious thing to decide on resource. Another might be indicate if display can do a color gamut where you can choose a different version<br>
<dael> nigel: Might also want to select different colors for text in that case.<br>
<dael> nigel: It's complicated and would be neat if single approach to extend.<br>
<dael> florian: We do have color gamut and dynamic range for video. Width and height seem harder<br>
<fantasai> s/video/video. These seem fine to me./<br>
<dael> nigel: iF users have to go to different places for info about same device that makes their job harder<br>
<dael> florian: But it's different. Picking different color of text you would do in CSS so a MQ is appropriate. If math in JS to figure out resource not obvious MQ is convenient.<br>
<dael> nigel: Yeah, just different things to balance<br>
<dael> ChrisN: I think that's how we ended up with this propoal. We have color gamut, let's put these in same place. Can revisit<br>
<dael> astearns: On face it seems reasonable peolpe have shown issues with this MQ, esp with privacy. Appropriate to go back to media QG and see what is really required for MQ. Example usage is great<br>
<dael> hober: Joint call might make sense and be faster than going back and forth. Media WG telecon is monthly<br>
<dael> astearns: Excellent idea<br>
<dael> astearns: Possible to invite CSS people to media WG call? Or should we host?<br>
<dael> hober: Imagine either<br>
<dael> nigel: I don't think we have Media group on the call<br>
<dael> ChrisN: It could work either way and may depend on timing.<br>
<nigel> s/Media group/Media group [chairs]<br>
<dael> florian: Would be good in same discussion to have someone, maybe TAG who can represent responsive image discussion<br>
<dael> hober: With my TAG hat on I guess I'll have to be on<br>
<dael> TabAtkins: Same here since I'm also responsible for srcset<br>
<dael> astearns: I'll reach out to Media WG chairs to get a time for a joint call<br>
<dael> florian: Next issue is related but different<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-642122040 using your GitHub account
Received on Wednesday, 10 June 2020 16:30:23 UTC