Re: [csswg-drafts] [css-mediaqueries] Precisely define which media features an undisplayed page has. (#3800)

The CSS Working Group just discussed `[css-mediaqueries] Precisely define which media features an undisplayed page has.`, and agreed to the following:

* `RESOLVED: Do testing in this area and specify values for this case`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-mediaqueries] Precisely define which media features an undisplayed page has.<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3800<br>
&lt;dael> florian: Display:none iframes can run scripts. If you run script you can run MQs. Spec doesn't say what to do in that case<br>
&lt;dael> florian: There are sites that depend on this and try to run it. Gecko is trying to find answers that don't make web crash<br>
&lt;dael> florian: Do we want to define this? Yes if web depends on it. What's best way to find answer? Is it in L4 or L5?<br>
&lt;dael> florian: Is emilio on?<br>
&lt;fantasai> Put it in L5, if it stabilizes and we want to pull it down to L4 later we can do that<br>
&lt;dael> florian: emilio suggested dummy values that don't depend on anything. That way you can answer something<br>
&lt;dael> florian: Appears Chrome answers non-dummy for some MQ. Resolution for example they answer for the doc hosting the iframe<br>
&lt;dael> florian: Proper is write tests<br>
&lt;dael> astearns: Is that bad? SHould iframes have access to that when they're display:none?<br>
&lt;dael> TabAtkins: I suspect there might be issues or data structures not created. Other than that I agree pulling information from same screen as document is fine. If iframe is displayed it's on the same screen and gets answers<br>
&lt;dael> florian: But if it isn't displayed it doesn't need to know. o maybe privacy leak. If you display it sure you get it.<br>
&lt;dael> TabAtkins: I don't think we shoudl conclude display:none is info boundary<br>
&lt;dael> florian: If there's a use to expose the parent sure. If it's just because why not we could also not expose why not.<br>
&lt;dael> rune: We're not exposing from parent document. I think we get it from frame structure. We're getting it for frame that's display:none b/c we have objects for the frame. It's not exactly parent document but directly via the frame<br>
&lt;dael> florian: Asking in a different way, is there a valid use for a display:none iframe to know screen resolution?<br>
&lt;dael> rune: no<br>
&lt;dael> TabAtkins: Really? I'd think it running scripts in preparing t odsipaly might want information<br>
&lt;dael> rune: true<br>
&lt;dael> TabAtkins: If it's primarily display:none sure, but you can't tell<br>
&lt;dael> Rossen: Is there a use case here or jsut about givign correct defaults<br>
&lt;dael> florian: Mozilla had crash bugs. They were responding with wrong thing where frames caused crash<br>
&lt;dael> Rossen: For me similar to how we resolved to answer gCS values for docs in that category. Seems we should stick to whatever defaults hsould be there and make them stable<br>
&lt;dael> florian: Dummy value like emilio suggested?<br>
&lt;emilio> gCS is defined to return an empty declaration, with length = 0<br>
&lt;bkardell_> q+<br>
&lt;dael> Rossen: Yeah. Exactly way did it for gCS. Return a bunch of default intiial values. Should match that. If we don't we're opening inconsistency between<br>
&lt;dael> smfr: Some compat risk. Prefer we test existing browsers and than decide if we want to change from current impl. Will be hard b/c we don't know what a display:none iframe is doing now<br>
&lt;astearns> ack bkardell_<br>
&lt;dael> TabAtkins: I thought some compat against 0 by 0 but it's against only false devices. 0x0 fixes one of emilio bugs<br>
&lt;emilio> Right, 0x0 is alright. Its "never match" what breaks sites<br>
&lt;dael> bkardell_: smfr said my point. I'm surprised by this. Seems unfortunate that it's surprising and I'd like to know why it is and if necessary to be surprising. BUt we can't break anything so understanding today is good first step<br>
&lt;astearns> ack fantasai<br>
&lt;florian> q+<br>
&lt;dael> fantasai: emilio said 0x0 is alright and never matches breaking site<br>
&lt;dael> astearns: For this case that we know of. So we do need a fix for that.<br>
&lt;dael> astearns: Good to have interop.<br>
&lt;TabAtkins> my proposed resolution: Attempt to fix MQs in non-displayed iframes to specific values, to be determined by testing.<br>
&lt;dael> astearns: I think we need testing before we decide what's possible in terms of interop values here<br>
&lt;dael> florian: I suggest for MQ specified but not impl I just pick ad efualt so that when they're implemented we don't get complicated interop. For those that exist we have to test<br>
&lt;dael> florian: That's tricky b/c I don't have a display:P3 device<br>
&lt;dael> TabAtkins: Someone does<br>
&lt;dael> TabAtkins: I suggest we add default value to MQ blocks and make that required in bikeshed<br>
&lt;dael> florian: Yep<br>
&lt;Rossen__> +1 to mq default values<br>
&lt;dael> astearns: Obj to do testing in this area and specify values for this case<br>
&lt;dael> RESOLVED: Do testing in this area and specify values for this case<br>
</details>


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

Received on Wednesday, 24 June 2020 16:39:37 UTC