Issue: https://github.com/w3c/media-capabilities/issues/133
gregwhitworth: chcunningham says the width and height should be returning the CSS pixels not the device pixels. Mark things it should rather be the device pixels.
chcunningham: Wondering how devices that have 2 panes do the layout. I have a little bit of clarity on that now.
… I just added a comment to the issue.
… There are existing patterns in the CSS and the DOM to detect screen resolution. If we can leverage those, that's important to do so.
… Feedback I got from Cast: the graphics are always rasterized to 1080p, irrespective of the TV the device is connected to.
… Obviously, that's not enough for a Cast device that supports 4K.
… 4K is for video. When the video is sent to the device, it is not sent through the same 1080p raster.
… It's sent separately.
… It seems similar to the way we handled high density displays in the past.
… Upscaling is effectively turning a pixel to multiple pixels.
… When an image is sent with 2x resolution, the device usually doesn't upscale but takes the image as it is.
… For video on cast, basically the same concept applies.
… There's no benefit for sending a 4K image in that case, because it would be downscaled to 1080p then upscaled again.
… But I don't think that warrants an exception for video.
… That seems like a reasonable price to pay.
GregFreedman: The one thing we want to do is to send the right resolution to the display based on physical pixels.
… As long as we get the answer that gives us physical pixels, the solution does not really matter.
… I would agree with Chris' statement that I don't know how prevalent this graphics pane vs. video pane is.
… If it's a common thing, we should address it. If it's a one off, we can probably address this differently, e.g. by identifying the device.
gregwhitworth: Have you been doing the maths and seen irregularities?
GregFreedman: Right now, we're only serving 4K content on Edge with a specific API.
… I noticed that when I commented and zoomed in, I noticed 3 different behaviors on different browsers. I don't actually know what the correct behavior is.
gregwhitworth: I kind of agree with Chris. I've done responsive images in the past.
… I don't know if we've solved this for videos.
… I agree that we should not keep this in there.
… I can follow up with folks such as Tab Atkins in CSS.
Action: gregwhitworth : do interop testing of devicePixelRatio + screen.width & height on FF/Edge/Chrome/Safari with/without zoom
chcunningham: I have a separate action, which is. As Luke posted, Cast reports 720 and devicePixelRatio at 1.5.
… I want to make sure that reporting the right size is feasible.
… What I hope not to learn is that there could be some new way that could break the web.
GregFreedman: It may be that 1.5 is the correct answer for the graphics pane, and maybe not the right answer for the video pane. Are we stuck there?
chcunningham: Perhaps. The graphics are technically being scaled up to the higher density, so that's not so bad.
vi: For DevicePixelRatio, is there disagreement on the way to get physical resolution?
chcunningham: I think we have agreement. But there may be subtelties I'm not aware of.
gregwhitworth: With regards to specific items in the PR, do we want to remove this information? Since now we're saying that a separate API should solve the problem.
chcunningham: We could remove it from the PR to land the PR. Not clear what the solution will be in the end. It's not that we're not trying to solve the problem, it's we're trying to solve it in a way that does not break the rest.
… I'm leaning towards not landing something that does not have consensus, and then working on it separately.
gregwhitworth: Is it OK if I take a resolution?
jernoble: I just wanted to comment on what a CSS pixel means on iOS. Pinch and zoom is different there. We're not going to change pixelDeviceRatio when the user pinches and zooms.
… It encompasses canvases, images, etc.
… I think that the CSS WG knows that it needs to look into it.
… We just need to make sure that they know we add media playback to the list of problems.
Resolved: Remove the screen width & height from VideoDisplayConfiguration PR until action is done and we can make an informed direction
Issue: https://github.com/w3c/media-capabilities/issues/134
gregwhitworth: Ironically, the other issue is whether to completely remove VideoDisplayConfiguration.
gregwhitworth: And hang that out of window.screen.video.
… We wanted a methods to implement possible mitigation, needed for fingerprinting. We're fine if that can be done through an attribute.
Vi: This comes from fingerprinting best practices.
chcunningham: I'm all for following best practices. I was unable to identify a mitigation that could not be done with an attribute.
jernoble: [explaining difference between active and passive fingerprinting]
… I don't think that the fact that it's an attribute vs. a method changes much, it's possible to catch "get" on an attribute in particular.
… The idea of a Privacy Budget was presented at TPAC.
… Once a threshold is reached, a browser could decide to return different answers for an API in order to reduce the number of leaked bits.
… I don't think that the asynchronous vs. synchronous nature is of importance. It's the fact that we have a query mechanism, that naturally only returns what is requested.
GregFreedman: With a method, you'd have to have JS to call the exact method.
jernoble: Right, but people interested in fingerprinting would do that in any case.
chcunningham: Thinking about Privacy Budget. I can think of 2 ways: 1. you call the attribute prior to hitting the privacy budget, then it would make sense to continue returning the same response after you hit the budget.
… 2. you call the attribute after hitting the privacy budget, then we could signal a default screen, e.g. an HD screen no matter what.
… I don't know if that matches the idea behind Privacy Budget, but that seems reasonable.
Vi: That sounds good.
gregwhitworth: So convert to static accessor hdrSupported?
Resolved: Convert hdrSupported to static accessor
gregwhitworth: Has there been some TAG review?
chcunningham: Media Capabilities had some TAG review on part of the spec.
… Not on the HDR features.
<chcunningham> tag review: https://github.com/w3ctag/design-reviews/issues/218
gregwhitworth: If we're following the same pattern as before, then that seems good. I just want to make sure we don't miss that.