This isn't a bug per se, and I already know what the issue is, so hopefully it's alright to submit this as a blank issue.
I use dark theme for everything, but because the editor UI will not register that dark theme is being used until it gets to a certain point, it will initially be a light theme during load, causing a "white flash".
This is due to this part of options.html:
<style>
body {
height: 100%;
overflow: hidden;
background-color: var(--color-bg-2);
color: var(--color-text-1);
}
</style>Here's an easy fix, it has a higher specificity and shouldn't lead to any flashes (including "dark flashes" in light theme):
@media (prefers-color-scheme: dark) {
body:not([arco-theme]):has(#root:empty) {
background-color: #232324;
}
}(#232324; corresponds to the default value of var(--color-bg-2) when [arco-theme="dark"])
This fix mainly relies on :has(#root:empty). Both pseudo-selectors here are now widely compatible:
https://caniuse.com/css-has
https://caniuse.com/wf-empty
By the time #root is populated (and :empty no longer applies), body should already have an arco-theme attribute defined, but just in case, I added :not([arco-theme]) to the selector to account for any possible inconsistencies in how the page loads in with other browsers (which will only match if body does not yet have an arco-theme attribute).
Note that even if you moved some of the JavaScript responsible for loading the theme into options.html directly, I think there would still be cases where the JavaScript engine hasn't yet affected the page and you'd still sometimes experience a white flash, so unfortunately we do have to depend on using the browser's preferred color scheme with @media (prefers-color-scheme: dark), though I've noticed that this has become common practice in the last few years.
Also, I've already tested it using my browser's custom.css (which is persistent and applies to all pages).
This isn't a bug per se, and I already know what the issue is, so hopefully it's alright to submit this as a blank issue.
I use dark theme for everything, but because the editor UI will not register that dark theme is being used until it gets to a certain point, it will initially be a light theme during load, causing a "white flash".
This is due to this part of
options.html:Here's an easy fix, it has a higher specificity and shouldn't lead to any flashes (including "dark flashes" in light theme):
(
#232324;corresponds to the default value ofvar(--color-bg-2)when[arco-theme="dark"])This fix mainly relies on
:has(#root:empty). Both pseudo-selectors here are now widely compatible:https://caniuse.com/css-has
https://caniuse.com/wf-empty
By the time
#rootis populated (and:emptyno longer applies),bodyshould already have anarco-themeattribute defined, but just in case, I added:not([arco-theme])to the selector to account for any possible inconsistencies in how the page loads in with other browsers (which will only match ifbodydoes not yet have anarco-themeattribute).Note that even if you moved some of the JavaScript responsible for loading the theme into
options.htmldirectly, I think there would still be cases where the JavaScript engine hasn't yet affected the page and you'd still sometimes experience a white flash, so unfortunately we do have to depend on using the browser's preferred color scheme with@media (prefers-color-scheme: dark), though I've noticed that this has become common practice in the last few years.Also, I've already tested it using my browser's
custom.css(which is persistent and applies to all pages).