Closed Bug 1525107 Opened 3 years ago Closed 7 months ago

Support the color-scheme meta tag

Categories

(Core :: Layout, enhancement, P3)

66 Branch
enhancement

Tracking

()

RESOLVED FIXED
95 Branch
Webcompat Priority ?
Tracking Status
firefox95 --- fixed

People

(Reporter: svoisen, Assigned: emilio)

References

(Blocks 1 open bug, )

Details

(Keywords: dev-doc-needed)

Attachments

(4 files, 2 obsolete files)

See the proposal: https://github.com/w3c/csswg-drafts/issues/3299

This meta tag allows sites to say they fully support a dark or light theme such that the browser can load an entirely different UA stylesheet (to style widgets, etc. that match a theme), thus avoiding "flashes" of content styled with the wrong theme. It is intended to be used in conjunction with the prefers-color-scheme media query.

This could also be used to allow Firefox to "apply automatic presentational transformations to web content (auto-darkening, or conversion into a high-contrast mode)" based on the user's preferred color scheme.

CSS Color Adjust Module Level 1
Section 2.3. The "color-scheme" meta value
https://drafts.csswg.org/css-color-adjust-1/#color-scheme-meta

As reflected in above, the initialially proposed meta name="supported-color-schemes"
has been renamed meta name="color-scheme" <-- note it is singular, not plural.

Updated the bug summary to match current spec

Summary: Support the supported-color-schemes meta tag → Support the color-scheme meta tag
Keywords: dev-doc-needed
See Also: → 1576289

Please note https://bugzilla.mozilla.org/show_bug.cgi?id=1626560 that we also just discovered in Chrome.

Chrome
WebKit
Firefox

Since this probably requires changes to the user agent stylesheets, it would be great to agree on a cross-browser set of dark scheme default link colors.

Depends on: 1576289

Tentatively taking this. I'm not starting on it right away, but I'll probably dive into this within a month or so.

Assignee: nobody → dholbert
Webcompat Priority: --- → ?

Stealing as per off-bugzilla discussion with Daniel :)

Assignee: dholbert → emilio

There are still tests failing because
https://bugzilla.mozilla.org/show_bug.cgi?id=1736034 hasn't been synced
yet.

Once that lands, they will still fail because we don't change
Canvas/CanvasText based on color-scheme, but that I'm attaching
patches for after this one.

This doesn't change behavior but will allow us to deduplicate some
logic given we compute the effective color-scheme in C++.

Depends on D129741

There are still tests failing because
https://bugzilla.mozilla.org/show_bug.cgi?id=1736034 hasn't been synced
yet.

Once that lands, they will still fail because we don't change
Canvas/CanvasText based on color-scheme, but that I'm attaching
patches for after this one.

This doesn't change behavior but will allow us to deduplicate some
logic given we compute the effective color-scheme in C++.

Depends on D129743

For that, add .dark version of the browser.display* prefs that control
the light version of these colors.

The default for background/foreground colors are taken from the
GenericDarkColors used in LookAndFeel.

The defaults for links are based on this discussion:

https://github.com/whatwg/html/issues/5426#issuecomment-904021675

(So they effectively match Chrome).

Whether the dark colors should be exposed in about:preferences like the
light colors are is TBD.

With this patch, we pass all the tests in:

https://wpt.live/html/semantics/document-metadata/the-meta-element/color-scheme/

However they're not properly synced yet per:

https://bugzilla.mozilla.org/show_bug.cgi?id=1736034

Use the colors to paint the default canvas background and the default
colors.

There are three "regressions", though they are really progressions: we
now render the reference as the test expects (before we rendered a light
canvas background even for the reference).

Apart of these iframe tests (which we should look into), there are three
remaining test failures.

Two of them are due to color: initial not changing based on the
color-scheme. Safari also fails these tests, and the thing they're
really testing is whether system colors are preserved at computed-value
time:

https://github.com/w3c/csswg-drafts/issues/3847

Regarding that change, I'm not so sure the trade-offs there are worth
it, as that not only complicates interpolation (we wouldn't be able to
use system colors in color-mix among others, see
https://github.com/w3c/csswg-drafts/issues/5780) plus it changes
inheritance behavior in sorta unexpected ways, see:

https://github.com/w3c/csswg-drafts/issues/6773

Which I just filed because apparently no browser implements this
correctly. So for now will punt on those (keep matching Safari).

There's an svg-as-image test:

https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html

Which isn't using the feature at all and I'm not sure why is it supposed
to pass (why prefers-color-scheme: dark is supposed to match that SVG
image). This test fails in all browsers apparently:

https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned

I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove
it and hopefully get it reviewed by some Chromium folks.

Depends on D129745

Attachment #9248136 - Attachment is obsolete: true
Attachment #9248137 - Attachment is obsolete: true
Blocks: 1738380
Blocks: 1738387
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6caecb555bdf
Implement <meta name=color-scheme>. r=dholbert
https://hg.mozilla.org/integration/autoland/rev/7a440f77a950
Move Canvas/Link color computation to C++-land. r=dholbert
https://hg.mozilla.org/integration/autoland/rev/b344eed54a03
Move mozilla::ColorScheme definition to its own header. r=dholbert
https://hg.mozilla.org/integration/autoland/rev/48bb39e937c5
Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert
Regressions: 1738584
Regressions: 1738586
Regressions: 1738587
Blocks: 1738616

Is there a bug to follow for this making it to release? A search didn't turn anything up.

That's bug 1576289, and emilio landed a patch there a few weeks back. So, if there aren't any issues, this will ship in Firefox 96.

You need to log in before you can comment on or make changes to this bug.