Support light and dark color scheme #1898
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Converting this to a draft because it doesn't seem to be working as expected. |
|
Seems to be working now with latest commit, but I think it should be tested on other platforms/configs before merging. |
|
Just tested the change. It works on Safari/MacOS, but does not on Safari/iPhone. On iPhone we got a black page.
|
stepnem
added a commit
to stepnem/surfingkeys-conf
that referenced
this pull request
Jan 28, 2023
Cf. brookhong/Surfingkeys#1898 (Support light and dark color scheme)
stepnem
added a commit
to stepnem/surfingkeys-conf
that referenced
this pull request
Feb 1, 2023
Cf. brookhong/Surfingkeys#1898 (Support light and dark color scheme)
stepnem
added a commit
to stepnem/surfingkeys-conf
that referenced
this pull request
Feb 2, 2023
Cf. brookhong/Surfingkeys#1898 (Support light and dark color scheme)
stepnem
added a commit
to stepnem/surfingkeys-conf
that referenced
this pull request
Feb 11, 2023
Cf. brookhong/Surfingkeys#1898 (Support light and dark color scheme)
stepnem
added a commit
to stepnem/surfingkeys-conf
that referenced
this pull request
Feb 14, 2023
Cf. brookhong/Surfingkeys#1898 (Support light and dark color scheme)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
Months ago, issue #1719 was opened, reporting that Surfingkeys was causing the page to become blank in Safari when dark mode was active. This was resolved in ccedde8 by setting
color-scheme: lighton the Surfingkeys container div.ccedde8 fixed the original issue, but by forcing the Surfingkeys iframe to always use
color-scheme: light, it created a new issue that the user couldn't use@media(prefers-color-scheme: dark)in their custom themes (at least in Firefox).The interaction between color-scheme and transparent iframes
The way browsers handle color-scheme in combination with transparent iframes is nuanced. The CSSWG decided that "if the color scheme of an iframe differs from embedding document, the iframe gets an opaque canvas bg appropriate to its color scheme". I believe this behavior is what was causing #1719 in the first place. I found a good blog post explaining these behaviors.
This PR
Instead of setting
color-scheme: lighton the Surfingkeys container div, this PR adds ametatag to the Surfingkeys iframe, declaring that it supports bothlightanddarkmode. In my testing in Firefox, this solves both problems: no white blank page, and the user can useprefers-color-schememedia queries.I tried testing this in Safari 14.1.2 on macOS 11.6.8 - I was not able to reproduce the original bug, but it seems this change works fine. (Note: I tested this manually in the devtools in Safari, I didn't build the extension with this change for Safari). I'd appreciate if you could test this in Safari on macOS and also iPadOS, to ensure that it works properly in those places before merging.