Color Scheme Simualation

[janodvarko]

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:

• Bug 1550804 - Add color scheme simulation to the inspector Introduced 4 states toggle button (null, no-preference, light, dark)

Meta:

• Bug 1137699 - Media query emulation

Bug for updating the tooltip:

• Bug 1606486 - Color scheme simulation tooltip should say "Cycle", not "Toggle"

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:

• Chrome has 3 states (seems to be clearer UI)
• Safari has 2 states (picking the opposite, default no-emulation)

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

[janodvarko]

There might be some platform work required for this yet.

Bug 1591120 - nsIContentViewer::emulatePrefersColorScheme should be forward to children remote iframes

[fvsch]

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:

• no active button = no preference
• dark or light button active = light or dark preference
• each button should disable the other when it becomes enabled

Figma design: https://www.figma.com/file/9bQ5m4ETFQ3fs6dERCXs2V/Forced-Light-Dark-Mode-Buttons

Icon code, should be ready to use in mozilla-central: https://gist.github.com/fvsch/1eec545f9fc0c42d4050634f009cfbbf

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).

[fvsch]

Alternative design idea, if we want to have a single button to save some space:

1. Use a 3-state button, but make its state visible by changing the icon rather than just background and fill colors:

   • Default state: exact icon to be figured out, button has normal colors
   • Forced light mode: sun icon, button has highlighted colors (blue fill/background)
   • Forced dark mode: moon icon, button has highlighted colors (blue fill/background)

2. The implementation could stay the same: click to cycle between ["default", "light", "dark"]. Later on, if user feedback warrants it, implement a dropdown menu to make those choices more explicit for users:

   • Normal click: show dropdown menu (see Honza’s mockup)
   • Shift + click: cycle between states, without showing the dropdown menu

[SebastianZ]

To clarify the current status:

The UI got changed in bug 1678949 to use two buttons reflecting three states:

• Default state: no button clicked => feature disabled
• Forced light mode: sun icon button
• Forced dark mode: moon icon button

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

[SebastianZ]

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 :hov and .cls buttons. And it also allows to add more media feature simulations in the future like for prefers-reduced-motion or prefers-contrast.

Sebastian

[hamishwillee]

FWIW the current FF87 UI as per https://github.com/firefox-devtools/ux/issues/129#issuecomment-780819661 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.

[fvsch]

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). — @SebastianZ

Yep, this is considered in https://bugzilla.mozilla.org/show_bug.cgi?id=1692434

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. — @hamishwillee

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 prefers-color-scheme:

• no-preference
• dark
• light

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 prefers-color-scheme: no-preference emulation in DevTools, then the site may still show a dark theme, so as you said: “nothing happens”. Something did happen, but the site treated it the same way as before.

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 prefers-color-scheme media queries. Then changing the prefers-color-scheme value in DevTools will never change the page’s styles. Ironically, the DevTools UI has the same problem, since it stores the light/dark theme preference as a Firefox preference (see devtools.theme in about:config), and doesn't inherit the light/dark value from the Firefox theme or the OS (it used to, but at the time it proved too buggy way, so that was removed).

See also this post for some design considerations on dark/light mode toggles: https://kilianvalkhof.com/2020/design/your-dark-mode-toggle-is-broken/

[hamishwillee]

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.

[fvsch]

So is "no preference" equivalent to "not light" and "not dark", or "whichever or light or dark the operating system gives you"?

Depends on if by "no preference" you mean "not forcing a light/dark value in DevTools" or "the page will match the (prefers-color-scheme: no-preference) media query". Turns out they’re pretty different things, and a source of confusion for many I’m sure.

Here’s a quick page for testing: https://codepen.io/fvsch/pen/qBqxaVy

• If I activate the “Sun” button and reload the page, it matches light
• If I activate the “Moon” button and reload the page, it matches dark
• If I activate neither and reload the page, it matches light when my OS setting is on light, dark when my OS setting is on dark (Firefox Nightly on macOS 11.2)

It looks like Firefox does not support matching no-preference at this time? There is a layout.css.prefers-color-scheme-no-preference.enabled=false preference in about:config, but setting it to true does not seem to change things.

@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:

• Default (light*)
• no-preference
• light
• dark

* In parenthesis, show the current value inherited from the OS/Firefox (light, dark or no-preference)

[hamishwillee]

So why do we expect no-preference to be valid when, unlike for many other queries, it is not defined in the spec? In the cases where it is defined it means "web default" which in this case would be "light".

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 FWIW then why are we trying to support it in this tool?

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.

[fvsch]

@hamishwillee I wasn’t aware of that spec change.

FWIW then why are we trying to support it in this tool?

Define "we" and "trying" :)

I — a sometimes contributor to Firefox DevTools UX — was suggesting to add support for forcing (prefers-color-scheme: no-preference) to DevTools, but since that value is not in the spec anymore that's moot.

[hamishwillee]

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".

[fvsch]

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 prefers-color-scheme value and showing what that value is. So, in a way: it could be both an inspection tool and an emulation tool.

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 prefers-color-scheme value currently reported by the browser to this web page” sounds like something that is the responsibility of DevTools, and right now it’s not doing it explicitly enough (or at all, when not using emulation).

[SebastianZ]

Quoting the hint in the spec. here:

This feature, like the other prefers-* features, previously had a no-preference value to indicate an author not expressing an active preference. However, user agents converged on expressing the "default" behavior as a light preference, and never matching no-preference.

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

[SebastianZ]

Ok, here are quick mockups of the three mentioned UI variants:

Options button

Drop down list

Radio buttons

Please note that they are really just meant to illustrate what I meant with the three types. It still needs to be clarified

• whether the options should stay within the Rules view or be placed somewhere else.
• what icon should be used in the options button and radio buttons variant and whether it should change depending on the selected option.
• whether the icons should also be shown besides the options (probably just possible in the radio buttons solution).
• how an active emulation option is displayed.
• how the option labels should be called.
• how grouped emulation features will look like. (That's covered in #134.)

Sebastian

[hamishwillee]

Developers may still wonder why choosing “dark” or “light” doesn’t make the site dark or light

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.