Skip to content
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

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

Open
lilles opened this issue Apr 4, 2019 · 17 comments

Comments

@lilles
Copy link

commented Apr 4, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 5, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 5, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 5, 2019

I suspect the CSS property came later here.

@xeenon

This comment has been minimized.

Copy link

commented Apr 5, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 5, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 5, 2019

@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

This comment has been minimized.

Copy link
Collaborator

commented Apr 5, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 8, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 8, 2019

heads-up to @whatwg/documentation

@chrisdavidmills

This comment has been minimized.

Copy link

commented Apr 9, 2019

@dbaron

This comment has been minimized.

Copy link
Member

commented Apr 17, 2019

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)

annulen pushed a commit to qtwebkit/qtwebkit that referenced this issue Apr 18, 2019

timothy@apple.com
Standardize the `<meta name="color-scheme">` separator.
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

This comment has been minimized.

Copy link
Collaborator

commented Apr 26, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 26, 2019

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

This comment has been minimized.

Copy link

commented May 24, 2019

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

This comment has been minimized.

Copy link

commented May 25, 2019

@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

This comment has been minimized.

Copy link

commented May 26, 2019

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

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

Add meta name="color-scheme"
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

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

Add meta name="color-scheme" (#4342)
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.