- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Feb 2020 17:45:54 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `` `color-scheme` should affect embedded iframes``, and agreed to the following: * `RESOLVED: If the color scheme of an iframe differs from embedding document iframe gets an opaque canvas bg appropriate to its color scheme` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: `color-scheme` should affect embedded iframes<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4772<br> <astearns> ack chris<br> <dael> Rossen_: This was added by Chrome folks<br> <dael> chrishtr: Problem with dark backplate behind iframe is it's not dev controllable. Prop is there be a white or black backplate of an iframe if the owner lemenet has a different color-scheme<br> <dael> chrishtr: A frame with an iframe have both dark you get that. One like and one dark backplate you get this.<br> <dael> chrishtr: backplate is the canvas behind the root element<br> <fremy> +1 to chrishtr's proposal<br> <dbaron> Is this specifically black/white background, or is it dark/light background? (i.e., are we requiring exactly black/white?)<br> <dbaron> (seems like it should match what's required for the root document)<br> <dael> jensimmons: Document canvas. We have legacy issue that iframes don't have document canvas but we also have expectation that if child document says it supports darkmode it assumes pat of that package is borwser painting dark canvas. One doc embadded in the other and one does darkmode switch things can get unreadbale. Proposal is iframe canavs is by default transparent unless mismatch between embedding element and root element. With mismatch you draw opaque canvas on<br> <dael> emilio: With used color scheme of iframe?<br> <dael> jensimmons: Yes. canavs system color of root element of iframe<br> <dael> emilio: Makes sense<br> <dbaron> s/jensimmons/AmeliaBR/<br> <dbaron> s/jensimmons/AmeliaBR/<br> <dael> AmeliaBR: Might not always be great for svg. Might need an issue that this may only apply to iframes or something. Not sure which is worse, color mismatch or chance at a transparent bakground. Specifically for webpage and iframe this should handle most cases. Open issue on svg<br> <dael> Rossen_: Detectable from within frame?<br> <dael> AmeliaBR: SHouldnt be. No way within doc to tell what the canvas color is b/c it's before root background so not accessible to cssom<br> <dael> emilio: Work for cross origin iframes?<br> <dael> Rossen_: That's why I asked. If there's additional information provided through mech to cross origin that's not today<br> <dael> AmeliaBR: Shouldn't be a way from embedded to tell if opaque drawn or not. Might be a user tricking way for paent doc to figure out if content is transparent based on if user can read content. I don't think there's a direct dom way outer document could tell<br> <dael> TabAtkins: Other than tricking user the information isn't exposed to embedding or embedder<br> <dael> emilio: Timing attacks from masking iframes and I'm assuming drawing opaque background is cheaper you could get creative<br> <dael> bkardell_: Is'tn that potential risk anyway?<br> <astearns> s/bkardell_ /chrishtr/<br> <dael> emilio: Would allow you to detect if there's a difference assuming you can detect painting of background<br> <dael> AmeliaBR: Maybe add a warning to avoid the timing attacks<br> <dino> s/the timing attacks/the timing attacks by taking care when optimising rendering into opaque iframes/<br> <dael> Rossen_: Besides the note sounds like consensus around how it should work. Any additional comments or objects to making the canvas of embedded documents match canvas of embedding document by either matching internal color scheme or applying opque cnavas in a case of mismatch<br> <dino> s/Is'tn/Isn't/<br> <dael> emilio: Assuming designing a doc designed to be embeddable can you design to match? I guess not and this does not slve. Mostly curious<br> <dael> AmeliaBR: That was my other proposal. The support color scheme option on child doc interp based on parent and that was poss cors issue b/c then child doc would be able to tell<br> <dael> emilio: Yeah<br> <dael> emilio: Okay. No concern.<br> <dael> Rossen_: I didn't hear objections<br> <dino> q+<br> <dael> TabAtkins: If the color scheme of an iframe differs from embedding document iframe gets an opaque canvas bg appropriate to its color scheme<br> <dael> ??: If owning doesn't provide color?<br> <dael> AmeliaBR: Legacy color scheme is still considered<br> <dael> RESOLVED: If the color scheme of an iframe differs from embedding document iframe gets an opaque canvas bg appropriate to its color scheme<br> <dino> s/??/dino/<br> <emilio> s/??/dino (I think?)<br> <emilio> heh :)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4772#issuecomment-591553929 using your GitHub account
Received on Wednesday, 26 February 2020 17:45:57 UTC