1840906 - Use design tokens in aboutwelcome.scss

Status: NEW

(Firefox :: Messaging System, enhancement, P3)

Description

[Hanna Jones [:hjones]]

When working on Bug 1826829 to add tokens for link styles it became clear that there are some complexities to using token values in aboutwelcome.(s)css. In addition to being used in about:welcome these styles are also loaded by the feature callout code. Feature callouts get loaded in the browser chrome and will soon be shown in about:newtab as well. In these cases we don't have access to the design token variables loaded via in-content/common-shared.css, which means we can't currently rely on those variables in aboutwelcome.css.

Ideally we could find a way to load design-tokens-brand.css in abotuwelcome.scss (maybe design-tokens-system.css too in cases where feature callouts are loaded in the chrome).

Comment 1

[Hanna Jones [:hjones]]

To be clear, we should be able to @import CSS files into our SCSS files - something along the lines of:

@import '../../../../../toolkit/themes/shared/design-tokens-brand';

We will likely have to work around a few issues that come up with the Sass parser though (for starters it won't know how to handle this style of import in design-tokens-brand.css).

Comment 2

[Shane Hughes [:aminomancer]]

We might be able to integrate an automated conversion into our SCSS build system. It could be feasible to generate SCSS files from design-tokens-brand.

Another issue I just identified was how the light/dark tokens are applied. The design-tokens-brand sheet uses the media query prefers-color-scheme: dark, which works great for content, but doesn't work so well for Feature Callout in certain contexts.

Something we do with Feature Callout is to load and show the callout in the chrome, but apply a content theme to it. This will be used for showing callouts on the new tab page, for example. Instead of the callout appearing inside the content, it appears on top of the browser, but it's styled to look like the new tab page. So from the user's point of view, it appears like part of the page. But it doesn't actually inherit styles from the page.

In such cases, we use these media queries to make the callout appearance match the content appearance (namely the light/dark color scheme). But these -moz-content-prefers-color-scheme media queries can (and often do) have different values than prefers-color-scheme. That's their purpose — to query the color scheme of content pages, rather than the color scheme of the chrome.

But that means there's a mismatch if we import design-tokens-brand, which uses prefers-color-scheme to determine the values of the design tokens. So let's say the chrome color scheme is dark, but the content color scheme is light. It's pretty easy to make this happen, as there is an option in about:preferences to override the content color scheme. In that case, feature-callout's stylesheet will perceive the content color scheme as light, so it will use its light colors.

But where it uses the design tokens, it will use the same design token variables whether in light or dark mode. Since their values are variable, there is no --button-background-color-dark, for example. Just --button-background-color, which changes values depending on prefers-color-scheme. But because the chrome color scheme is dark, its value will be the dark value, not the light value. So even though content color scheme is light, and we're trying to mimic that, we'll end up showing a dark feature callout.

So, I think what we actually need to do with this automated build process is to generate a SCSS file from design-tokens-brand, and change this

@media not (prefers-contrast) {
  :root {

to this:

@mixin light-design-tokens {

(and the same for the dark tokens)