Adapt to the dark theme of modern browsers corresponding to the scroll bar under the dark theme

[SuperManito]

Context

add head meta

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

Description

The scroll bar can use the dark mode. If the scroll bar still displays the default light mode after switching to the dark mode it will be uncomfortable

Related links

• Requesting a change

Use Cases

Docusaurus2 Vuepress

Visuals

No response

Before submitting

• [X] I have read and followed the change request guidelines.
• [X] I have verified that my idea is a change request and not a bug report.
• [X] I have ensured that, to the best of my knowledge, my idea will benefit the entire community.
• [X] I have included relevant links to the documentation, related issues, and discussions to underline the need for my idea.

[squidfunk]

Thanks for suggesting! Fixed in fe0c966a4. We opted for the CSS color-scheme property, as it can be directly defined in the color schemes that we offer. Additionally, it's easier for authors to set those in their own custom color schemes.

As an addendum, here's a good read on color-scheme.

[SuperManito]

Thanks for suggesting! Fixed in fe0c966. We opted for the CSS color-scheme property, as it can be directly defined in the color schemes that we offer. Additionally, it's easier for authors to set those in their own custom color schemes.

As an addendum, here's a good read on color-scheme.

Your document website looks the same as it did before the fix commit

[SuperManito]

Thanks for suggesting! Fixed in fe0c966. We opted for the CSS color-scheme property, as it can be directly defined in the color schemes that we offer. Additionally, it's easier for authors to set those in their own custom color schemes.

As an addendum, here's a good read on color-scheme.

I have some other suggestions. I think the background color in dark mode should be more towards black. Preferably controlled by the user via css variables.

The problem now is that when the background color or theme color is changed, the background color of some button hover does not change accordingly. This often requires providing multiple tones of different depths at the same time.

So my suggestion has two solutions: one is that the user only defines one main color, and the auxiliary colors of other depths are automatically provided by dependencies, such as tinycolor of npm; the other is to define a whole set of variables in css instead. Docusaurus provides an online solution styling-your-site-with-infima

[squidfunk]

Your document website looks the same as it did before the fix commit

The changes haven't been merged in Insiders yet, and our site is built with Insiders. We'll do that before the next release.

The problem now is that when the background color or theme color is changed, the background color of some button hover does not change accordingly. This often requires providing multiple tones of different depths at the same time.

So my suggestion has two solutions: one is that the user only defines one main color, and the auxiliary colors of other depths are automatically provided by dependencies, such as tinycolor of npm; the other is to define a whole set of variables in css instead. Docusaurus provides an online solution styling-your-site-with-infima

Please create a discussion for your suggestion with some screenshots or a screencast, so we can better understand what you want to see ☺️ It's beyond the scope of this issue, and we shouldn't mix feature requests in issues. Please also note that Material for MkDocs does not have an author-facing build step that compiles the CSS – 99% of users do not have a Node.js environment in their build pipeline available. For this reason, we decided that CSS variables are the best solution for overrides. If you want to deduce tints, you can always fork the theme, or set up a Node.js environment yourself and compute CSS variables, adding that as extra CSS. It's actually not that hard. For the majority of users, the current solution is simpler.

[squidfunk]

Released as part of 9.1.15!

[SuperManito]

Released as part of 9.1.15!

Are you sure it works? I think this should be provided by default rather than user-defined.

[squidfunk]

Yes, color-scheme is definitely being defined as of 9.1.15. We provide it for the included color schemes (default and slate). For custom color schemes, you must just set it accordingly:

https://github.com/squidfunk/mkdocs-material/blob/fe0c966a4da16861e3fbe9064afcae3cc3d7c6fa/src/assets/stylesheets/palette/_scheme.scss#L30-L34

[SuperManito]

color-scheme: dark;

no effect

[squidfunk]

Works perfectly for me. If I visit our documentation site, and add an unstyled input field to the content, it will adapt to the OS color scheme:

If I uncheck color-scheme: dark, it doesn't adapt. Thus, it behaves as advertised:

[SuperManito]

Works perfectly for me. If I visit our documentation site, and add an unstyled input field to the content, it will adapt to the OS color scheme:

If I uncheck color-scheme: dark, it doesn't adapt. Thus, it behaves as advertised:

Your screenshot doesn't show scrollbars. I raise this question mainly to solve the display problem of the browser's default scrollbar under the dark theme.

After my tests, this may need to be defined on the head tag. Because I have tried to do this with css before raising this issue

[squidfunk]

Okay, so we might need to set the color-scheme meta tag for that. We can't set it in the template, we must set it via JavaScript, as pressing the toggle to change the scheme will also change the value of the meta tag. Re-opening.

[squidfunk]

Fixed in d2f403495. The color-scheme meta tag is now synchronized with the palette. Please check if this fixes you reported. Thank you.

[SuperManito]

Fixed in d2f4034. The color-scheme meta tag is now synchronized with the palette. Please check if this fixes you reported. Thank you.

It's worked

[squidfunk]

Released as part of 9.1.16.