-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Color Scheme Simualation #129
Comments
There might be some platform work required for this yet. Bug 1591120 - nsIContentViewer::emulatePrefersColorScheme should be forward to children remote iframes |
This was implemented with a button that cycles between 3 states (no-preference, forced-light, forced-dark), and there’s a bit of feedback on Twitter showing it can be puzzling. Here was my analysis: https://twitter.com/fvsch/status/1359911299409412096 I proposed an alternative design with two buttons, which can handle the 3 states:
Figma design: Icon code, should be ready to use in mozilla-central: The icons are designed to be rendered at 16px, but if you need to make them smaller, both 15px and 14px seems to render correctly as well on 1x displays (since it’s a circular design no straight strokes, it doesn’t have as much of a bluriness problem as other icons when scaled down). |
Alternative design idea, if we want to have a single button to save some space:
|
To clarify the current status: The UI got changed in bug 1678949 to use two buttons reflecting three states:
This feature was enabled for all channels in bug 1692272 and will ship with Firefox 87. Here's a screenshot of how it looks like now: Sebastian |
An enhancement to the shipping two-button UI could be a button that opens a panel for all types of simulations (currently color scheme simulation and print media simulation). That is more consistent with the other features like the Sebastian |
FWIW the current FF87 UI as per #129 (comment) is confusing. It is fine if I toggle between the two buttons, but if toggle the dark button in dark mode (say) nothing happens and it felt like it was broken. Perhaps hide the dark button in dark mode (and light in light mode) so that the transition is between light mode on and off (in dark mode), or dark mode on and off (in light mode). If there is a state where you might not get either mode from the OS and the browser has no default it might make sense to display both buttons - but I don't know if that is possible. |
Yep, this is considered in https://bugzilla.mozilla.org/show_bug.cgi?id=1692434
I’m not sure this is something that can be fixed by changing the UI. This emulation UI needs to be able to force each one of those three values for
The emulation feature cannot control how the site will react to each of those values. For instance, if a site uses a dark theme by default, and your OS is using a dark theme, the site may show up with a dark theme. When you enable the There are more tricky implementations where the theme preference was saved in localStorage by the site, and it's now using that localStorage value as its source of truth instead of See also this post for some design considerations on dark/light mode toggles: |
So is "no preference" equivalent to "not light" and "not dark", or "whichever or light or dark the operating system gives you"? It sounds like I either see dark mode or light mode whatever buttons I press or whatever the setting of the mode is on the OS, so not sure what the point is of the third state. |
Depends on if by "no preference" you mean "not forcing a light/dark value in DevTools" or "the page will match the Here’s a quick page for testing:
It looks like Firefox does not support matching @nchevobbe Can you help clarify what Firefox + DevTools can do at the moment? I wonder if ultimately DevTools should show 4 options in a menu:
* In parenthesis, show the current value inherited from the OS/Firefox ( |
So why do we expect EDITED - Ah, it is shown as not supported in BCD and experimental: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme#browser_compatibility This kind of implies that the best UI currently is one with a single button to toggle dark and light being explicitly set. When inactivated it would show the OS mode (default). When activated it would change icon to the mode that is set. Of course that is not future proof against the mode supporting new states in future. However it does remove any ambiguity now. |
@hamishwillee I wasn’t aware of that spec change.
Define "we" and "trying" :) I — a sometimes contributor to Firefox DevTools UX — was suggesting to add support for forcing |
Phew, that should make things very much easier :-). Though as above there is this idea in the spec that more complicated colour modes like "sepia" should be supported, which would make this hard again. Thanks for your patience with me; I'm not so good at explaining things that I don't "get". |
No worries. Both the spec and web developers’ understanding have been a moving target, so it’s hard to get a design that’s quite right. IMO the current design could be made clearer, e.g. by showing in some way that the “off” state means that the browser is using a default That won’t solve all comprehension problems. Developers may still wonder why choosing “dark” or “light” doesn’t make the site dark or light (possible reasons: site doesn’t support it, or site caches a value in JavaScript memory and/or in localStorage and uses that, not reacting to further changes from the browser). I don’t think these issues can be solved without forcing sites to support all color preferences and to respond to color preference changes (which won’t happen). But telling developers “Hey, this is the |
Quoting the hint in the spec. here:
Note that this is actually not totally correct. As you already correctly recognized, default behavior of user agents is to take the preference from the OS. So "light" is not the default. The main confusion obviously comes from not making it clear what the default is. So I agree with @fvsch that this info should be explosed somehow. I think the DevTools should always provide the user with all options - for now that means no emulation (use default), dark preference emulation, light preference emulation. Otherwise authors would wonder why there is only one emulation mode shown. So for an unambiguous UI I see three options: An options button, a drop down list, or radio buttons. An options button means a toolbar button that opens a menu that allows to choose between the options. This could be used as long as the emulation features are not grouped (see #134). That allows the button to be placed individually and at the same time have a consistent UI with the other toolbar buttons. A drop down list is similar to the button but displays text instead of an icon (see the network throttling list as an example). That makes it obvious whether emulation is enabled and which one. The radio buttons variant is best when the different emulation options are grouped and using some kind of panel as the radio buttons take some space. I'll try to come up with some mockups as for how I imagine those three UI variants. Sebastian |
Ok, here are quick mockups of the three mentioned UI variants: Options buttonDrop down listRadio buttonsPlease note that they are really just meant to illustrate what I meant with the three types. It still needs to be clarified
Sebastian |
True. So you might hide the tools if there is no media query of this type on the page. I still don't see the need for more than two states though - no emulation is never going to show you anything different, so why bother. |
UX discussion for "Color Scheme Simulation" feature in DevTools
Summary:
Adds an option to simulate different color schemes allowing to test @prefers-color-scheme media queries. Using this media query lets your style sheet specify whether it prefers a light or dark user interface. This feature lets you test your code without having to change settings in your browser (or operating system, if the browser follows a system-wide color scheme setting).
Mini-PRD: https://docs.google.com/document/d/1M1YMw83k2wmW7FAnqnIC3DdkPElccxypsCLuWyoIZJY/edit#heading=h.ra7dtg5dt199
Original bug:
Introduced 4 states toggle button (null, no-preference, light, dark)
Meta:
Bug for updating the tooltip:
Hidden behind a pref:
devtools.inspector.color-scheme-simulation.enabled
MDN: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features#Color_scheme_simulation
Others:
Screenshot:
The goal should be to polish/simplify the UI (e.g. no-preference doesn't exist anymore)
@violasong @digitarald @martinbalfanz
We could also introduce a popup offering the state options
Honza
The text was updated successfully, but these errors were encountered: