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

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

Open
smfr opened this Issue Nov 7, 2018 · 6 comments

Comments

Projects
None yet
5 participants
@smfr
Copy link
Contributor

smfr commented Nov 7, 2018

Proposal

Authors should be able to style their content taking into account the users's preferred system-level color scheme (e.g. for dark mode on macOS Mojave, or Microsoft's high-contrast mode). This would allow, for example, a page to express the fact that it has a "dark mode", which would be displayed to users whose system preference is to use a dark-mode interface. Authors would use this new property in conjunction with the prefers-color-scheme media query.

Some UAs may also wish to apply automatic presentational transformations to web content (auto-darkening, or conversion into a high-contrast mode). The functionality described below allows a page to opt out of this UA-applied transformation.

Meta tag

We think adding a new meta tag is necessary so that UAs know early in parsing which color scheme is to be used, since this may impact the default appearance of the view containing the web content, and we wish to avoid flashes caused by delayed switches between color schemes.

The meta tag syntax is:

<meta name="supported-color-schemes" content="[light? || dark? || <ident>?]* || only?">

"" (empty string) (the default)—the UA may choose to transform the content to match the user's preference.
light dark—the UA will choose the light or dark theme to match the user's preference. If the user's preference does not match something in the list, the UA is allowed to apply transformations to the content (e.g. apply high-contrast).
only—synonym for light only; the UA will only ever render the content in the light color scheme, and never apply transformations[1].
light dark only—the UA will choose the first of the listed schemes that it supports taking user preference into account, and never apply transformations[1].
Custom scheme, like hi-contrast only—if the UA doesn't support hi-contrast it's allowed to fall back to its default rendering light, and will never apply transformations.

Note: is present for compatibility; some UAs may support color schemes in addition to light and dark, and the including of unrecognized schemes should not break parsing.
must not be “only”

Note: Maybe the meta tag should be specified outside of CSS.

[1] UAs are allowed to apply minimal transformations, for example making the root background transparent, but not change the overall appearance of the content.

CSS Property

supported-color-schemes: [light? || dark? || <ident>?]* || only?

Inherited: yes
Initial value: light

The CSS property has the same behavior as the meta tag, and allows authors to style sub-sections of content with a different color theme.

How the color scheme affects rendering

The UA may take the chosen color scheme into account when rendering the default page background, form controls, the default selection color, and other UA-controlled UI like misspelling underlines.

Interaction with the media query

The media query always matches the user preference. Authors should avoid styling content for the dark mode if they don't claim to support it in the meta tag.
Issue: Maybe in “non-only” mode the media query should reflect the scheme the UA is converting to?

@fantasai fantasai added the css-ui-4 label Nov 15, 2018

@fantasai

This comment has been minimized.

Copy link
Contributor

fantasai commented Nov 15, 2018

Have you considered just re-using the Alternate Style Sheets mechanism from HTML per http://www.idpf.org/epub/altss-tags/#app-night-version-style-set-tags ?

@rcabanier

This comment has been minimized.

Copy link
Contributor

rcabanier commented Dec 11, 2018

@fantasai that proposal will suffer from the problem that the style resolution happens after the document is already displayed.
This will result in a "flash" of the default styling which is not desirable.

@rcabanier

This comment has been minimized.

Copy link
Contributor

rcabanier commented Dec 11, 2018

I think dark mode will need a different default UA stylesheet. For instance, the default document color could be transparent or black and default text color white.

@tomhodgins

This comment has been minimized.

Copy link

tomhodgins commented Dec 11, 2018

I think dark mode will need a different default UA stylesheet.

I've thought a little bit about what would be required for a dark-mode.css, and it seems that since chromium, gecko, and webkit all have slightly different html.css user-agent stylesheets, to do a 'dark mode' base CSS stylesheet properly you'd probably need to create a new stylesheet that had light-on-dark default colors, and that included rules from all three user-agent stylesheets to make sure it was looking the same in all browsers. The resulting stylesheet would be big, and probably pretty ugly 😆

I'm not sure that just one browser alone could implement a 'dark-mode.css' stylesheet that would be helpful for CSS authors to develop on top of if it wasn't necessarily catching every default style that another browser's user-agent stylesheet was setting.

If anybody is interested in making some kind of dark-mode.css base stylesheet that CSS authors can build dark themes on top, please ping me. I'm interested in helping to assemble something like this, but haven't gotten around to starting that yet!

@xeenon

This comment has been minimized.

Copy link

xeenon commented Dec 11, 2018

Note that WebKit solves some of the complexity of dark and light mode colors by having special handling of CSS named colors. The named color can resolve to different values, depending on what mode you are in — like buttonText is dark in light mode, and white in dark mode. This proposal helps us know if the page (or DOM tree) expects those named colors and form controls to have different rendering, and not break the web by changing them on unsuspecting content.

So our html.css is actually pretty much the same as it was before dark mode, with just some tweaks to use more named colors instead of hardcoded color values.

@rcabanier

This comment has been minimized.

Copy link
Contributor

rcabanier commented Dec 12, 2018

Is this something that can be put in a spec? Does CSS use named colors for default styles?

For the magic leap use case, we'd also like to have the color of the root element to be transparent by default instead of white (or black in dark mode)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment