Define <meta name=supported-color-schemes> #4504

lilles · 2019-04-04T12:54:56Z

Split out from proposal in w3c/csswg-drafts#3299

Apply is shipping in Safari 12.1. Chrome wants to ship this. There is a proposal draft at:

https://lilles.github.io/specs/supported-color-schemes-meta.html

with a related css-ui property proposal draft at:

https://lilles.github.io/specs/supported-color-schemes.html

domenic · 2019-04-05T01:10:56Z

Multi-implementer interest, yay! I trust appropriate CSSWG folks are involved in vetting this design? Maybe @dbaron from Mozilla would be good to ping explicitly.

The draft makes sense to me, probably with a few more cross-links in the final version. Can you submit a pull request which we could iterate on?

I guess one issue is that <custom-ident> also matches only so steps 1-3 might not work so well. In general that processing model probably needs a bit of work, e.g. it should probably normalize to ASCII lowercase, deduplicate, etc. Or maybe that should be left up to the CSS processing, and the value should just pass through directly to the CSS property value?

domenic · 2019-04-05T01:14:40Z

I guess there is a basic question though, of why Safari shipped and Chrome desires to ship

<meta name="supported-color-schemes" content="...">

instead of

<html style="supported-color-schemes: ...">

What other CSS properties to we plan on duplicating in this way?

annevk · 2019-04-05T08:35:42Z

I suspect the CSS property came later here.

xeenon · 2019-04-05T16:25:11Z

Safari and WebKit support and ship both. The meta values are the base values for the document and CSS overrides.

The meta declaration is mostly needed and used by clients that need to know the color schemes before loading — macOS Mail uses it during its auto darkening decision.

domenic · 2019-04-05T16:28:46Z

I don't quite understand the use case there; both of my snippets seem workable "before loading".

Regardless, it's not clear that we want to propagate this requirement from macOS Mail onto the open web. Maybe @lilles could say more about use cases that are important to Chromium's customers?

Zirro · 2019-04-05T17:42:55Z

For sites using a CSP without unsafe-inline, relying on inline styles would add complexity or even be impossible in the case of static sites. Since the color scheme needs to be discovered early in order to be useful, it would not be feasible to wait for external CSS to load on these sites.

domenic · 2019-04-05T17:43:53Z

@Zirro that raises the question then, of how many other CSS properties are we going to turn into meta tags? If in general inline CSS is not usable for some people, should we just make it possible to specify any CSS property of the document via meta tags? I'm not sure this is the right level at which to address peoples' tooling difficulties.

Note that all CSS loads are render-blocking, so I don't know why color scheme would need to be discovered more-early than other things like background or text color.

tabatkins · 2019-04-05T19:52:51Z

The general CSS tracking issue for this is w3c/csswg-drafts#3807; @fantasai and I spent time yesterday reviewing the several color-adjusting proposals from the last year and synthesized them into a compatible set of proposals.

We suggest shortening the names of the color-scheme parts (to just color-scheme, for both the and the property), and adding some additional mechanics, but the overall grammar and functionality is unchanged from Rune's proposal. (Parsing does need some cleanup work, as you note.)

Note that all CSS loads are render-blocking, so I don't know why color scheme would need to be discovered more-early than other things like background or text color.

"Render-blocking" doesn't stop browsers from doing the initial "all white" render; avoiding that as much as possible is very important for dark mode.

If in general inline CSS is not usable for some people, should we just make it possible to specify any CSS property of the document via meta tags? I'm not sure this is the right level at which to address peoples' tooling difficulties.

That's not a bad idea. <meta name=initial-style>, with the value parsed as a style attribute and applied to the root element? (Cascade-wise, living at the author-stylesheet origin, ordered before any other stylesheets?.)

annevk · 2019-04-08T08:05:33Z

Circumventing CSP through <meta> kinda sounds like a security problem waiting to happen. Please make sure the CSP community (and maybe Trusted Types folks) buy into it.

sideshowbarker · 2019-04-08T19:59:51Z

heads-up to @whatwg/documentation

chrisdavidmills · 2019-04-09T10:19:59Z

MDN docs need recorded at https://trello.com/c/xMWeNiAh/156-html-meta-element

dbaron · 2019-04-17T16:35:48Z

Since I was pinged here -- I'd note I've already explained what I'm not particularly happy about with this design: w3c/csswg-drafts#3299 (comment)

https://bugs.webkit.org/show_bug.cgi?id=193931 Reviewed by Simon Fraser. Source/WebCore: Drop support for comma as a valid seperator in <meta name="color-scheme"> to match the proposal being tracked by: whatwg/html#4504 Tests: css-dark-mode/color-scheme-meta.html css-dark-mode/older-syntax/supported-color-schemes-meta.html * dom/Document.cpp: (WebCore::isColorSchemeSeparator): Drop support for comma. LayoutTests: * css-dark-mode/color-scheme-meta-expected.txt: * css-dark-mode/color-scheme-meta.html: * css-dark-mode/older-syntax/supported-color-scheme-meta-expected.txt: * css-dark-mode/older-syntax/supported-color-schemes-meta.html: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@244413 268f45cc-cd09-0410-ab3c-d52691b4dbfc

tabatkins · 2019-04-26T19:38:06Z

Note that the meta value is now defined in https://drafts.csswg.org/css-color-adjust/#color-scheme-meta. If HTML would like to adopt the definition instead, that's fine, just let me know. At @domenic's urging, I adopted the same updating text as some of the other meta values in HTML.

domenic · 2019-04-26T20:06:21Z

Awesome! Spec text looks pretty good at first glance. But yeah, we're trying to centralize all the UA-affecting meta values in HTML; if you'd be up for moving it over here that'd be lovely. (And sorry in advance for Wattsi.)

aaaxx · 2019-05-24T04:08:41Z

As a web designer who follows HTML and CSS working groups, I'm really baffled by this introduction of a new meta property to HTML for something that is entirely dependent on the available stylesheets. I'd appreciate if somebody could clarify a few things to me.

What is the advantage of the meta property compared to specifiying a color-scheme attribute that would be applied to stylesheets, e.g. <link rel="stylesheet" media="color-scheme:..." .../>? That would also prevent the color flashing issue.

meduzen · 2019-05-25T11:26:15Z

@aaaxx When the browser strictly relies on stylesheet, it can’t make safe assumption of the purpose of the stylesheet, and everything can happen: maybe the stylesheets won’t load, or maybe it’ll load and be broken, or some JavaScript will load other stylesheets that overwrite the main one, or the stylesheet only cover a small part of the layout (see example below)…

Your example (<link rel="stylesheet" media="color-scheme:..." .../>) is very specific and assume the CSS file contains the color scheme styles for the root layout (html { … }) at the very least, which is often not the case as CSS authors split stylesheets (when they do!) in a lot of different ways.

Imagine this use case: a developer’s blog where there’s only a light theme, loaded without media condition (light is default).

<!-- blog only having a light theme -->
<link rel="stylesheet" src="main.css" />

Now let’s say this developer’s blog is using a code highlighting plugin that supports light and dark color schemes, split in two dedicated CSS files:

<!-- code highlighting plugin -->
<link rel="stylesheet" src="code-light.css" media="prefers-color-scheme: light" />
<link rel="stylesheet" src="code-dark.css" media="prefers-color-scheme: dark" />

If the browser considers the page is having a dark color-scheme available juste because because of the media="prefers-color-scheme: dark" of the code highlighting plugin, this will be an incorrect assumption as the website only has a light theme. As a result, if a user browsing in dark mode lands on this blog coming from another page without dark mode, the background color will go from light (previous site) to dark (browser making false assumption) to light again (main.css loaded), in addition to other styles issues (for example: potentially unwanted colors for form controls of the blog comments).

The browser can’t make correct assumptions of the layout parts covered by a stylesheet, and the only way for the browser to make a correct assumption of the page color-scheme is to load all its HTML, CSS and JS files.

Hence the proposed <meta>: it avoids wrong assumptions by explicitly declaring as early as possible the supported color-schemes.

aaaxx · 2019-05-26T02:28:48Z

OK, that makes sense, especially the case of JavaScript-loaded stylesheets.

One more thing: how will this interact with user stylesheets and alternative style sheets? (There's still potential for color flashing if their color schemes differ from the meta.)

Added this value for the `name` property on the `<meta>` element. Currently supported only in Safari 12.1 for Mac and 12.2 for iOS. whatwg/html#4504

https://bugs.webkit.org/show_bug.cgi?id=193931 Reviewed by Simon Fraser. Source/WebCore: Drop support for comma as a valid seperator in <meta name="color-scheme"> to match the proposal being tracked by: whatwg/html#4504 Tests: css-dark-mode/color-scheme-meta.html css-dark-mode/older-syntax/supported-color-schemes-meta.html * dom/Document.cpp: (WebCore::isColorSchemeSeparator): Drop support for comma. LayoutTests: * css-dark-mode/color-scheme-meta-expected.txt: * css-dark-mode/color-scheme-meta.html: * css-dark-mode/older-syntax/supported-color-scheme-meta-expected.txt: * css-dark-mode/older-syntax/supported-color-schemes-meta.html: Canonical link: https://commits.webkit.org/211299@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@244413 268f45cc-cd09-0410-ab3c-d52691b4dbfc

yinonov · 2021-11-01T20:51:38Z

I'd like to point out what I believe is a gap in the concept
UA consider the color-scheme meta content but provide no run-time paired query.

authors may need to dynamically set content (different image for each scheme) according to current active scheme but the only available option is the prefers-color-scheme which may conflict with actual resolved scheme.

say my OS is set to dark,

<meta name="color-scheme" content="light">

will render the page as light theme

but

@media (prefers-color-scheme: dark) {
  fieldset {
    background-color: darkslategray;
  }
}

will still apply even though the UA is set to light

see reproduction sandbox

furthermore, as color-scheme css property can be applied on any element, it should also be possible to select it by pseudo class. :color-scheme(dark)

yinonov · 2021-11-01T20:53:23Z

btw can content be extended to contain more values? e.g. dark, light, halloween etc

lilles mentioned this issue Apr 4, 2019

[css-ui] Add a way for authors to indicate that they want dark-mode form controls etc w3c/csswg-drafts#3299

Closed

domenic added addition/proposal New features or enhancements topic: style labels Apr 5, 2019

sideshowbarker added the impacts documentation Used by documentation communities, such as MDN, to track changes that impact documentation label Apr 8, 2019

a2sheppy added a commit to a2sheppy/browser-compat-data that referenced this issue Jun 19, 2019

Add meta name="color-scheme"

c3b04e7

Added this value for the `name` property on the `<meta>` element. Currently supported only in Safari 12.1 for Mac and 12.2 for iOS. whatwg/html#4504

a2sheppy mentioned this issue Jun 19, 2019

Add meta name="color-scheme" mdn/browser-compat-data#4342

Merged

queengooborg pushed a commit to mdn/browser-compat-data that referenced this issue Jun 25, 2019

Add meta name="color-scheme" (#4342)

0cb75bd

Added this value for the `name` property on the `<meta>` element. Currently supported only in Safari 12.1 for Mac and 12.2 for iOS. whatwg/html#4504

jtraub mentioned this issue Aug 29, 2019

Is there a way to promote the use of <meta> element theme-color and color-scheme for both Dark Reader and some major websites? darkreader/darkreader#1536

Open

qguv mentioned this issue Sep 27, 2019

Web site meta data to disable dark by default darkreader/darkreader#1114

Closed

tomayac mentioned this issue Apr 1, 2020

Pages with color-scheme: dark have too low link color contrast #5426

Open

nico-bachner mentioned this issue Oct 20, 2023

sveltekit-theme-switch.mdx uses the deprecate __layout.svelte file nico-bachner/v5#1

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Define <meta name=supported-color-schemes> #4504

Define <meta name=supported-color-schemes> #4504

lilles commented Apr 4, 2019

domenic commented Apr 5, 2019

domenic commented Apr 5, 2019

annevk commented Apr 5, 2019

xeenon commented Apr 5, 2019

domenic commented Apr 5, 2019 •

edited

Loading

Zirro commented Apr 5, 2019

domenic commented Apr 5, 2019 •

edited

Loading

tabatkins commented Apr 5, 2019

annevk commented Apr 8, 2019

sideshowbarker commented Apr 8, 2019

chrisdavidmills commented Apr 9, 2019

dbaron commented Apr 17, 2019

tabatkins commented Apr 26, 2019

domenic commented Apr 26, 2019

aaaxx commented May 24, 2019

meduzen commented May 25, 2019

aaaxx commented May 26, 2019

yinonov commented Nov 1, 2021 •

edited

Loading

yinonov commented Nov 1, 2021

Define <meta name=supported-color-schemes> #4504

Define <meta name=supported-color-schemes> #4504

Comments

lilles commented Apr 4, 2019

domenic commented Apr 5, 2019

domenic commented Apr 5, 2019

annevk commented Apr 5, 2019

xeenon commented Apr 5, 2019

domenic commented Apr 5, 2019 • edited Loading

Zirro commented Apr 5, 2019

domenic commented Apr 5, 2019 • edited Loading

tabatkins commented Apr 5, 2019

annevk commented Apr 8, 2019

sideshowbarker commented Apr 8, 2019

chrisdavidmills commented Apr 9, 2019

dbaron commented Apr 17, 2019

tabatkins commented Apr 26, 2019

domenic commented Apr 26, 2019

aaaxx commented May 24, 2019

meduzen commented May 25, 2019

aaaxx commented May 26, 2019

yinonov commented Nov 1, 2021 • edited Loading

yinonov commented Nov 1, 2021

domenic commented Apr 5, 2019 •

edited

Loading

domenic commented Apr 5, 2019 •

edited

Loading

yinonov commented Nov 1, 2021 •

edited

Loading