@bramus I understand the dev concerns about toggling, but what makes you want website specific settings in the browsers? Who will micromanage that setting and why? Has this been researched?
@wolfr You, the user of the browser, will micromanage the setting. You can keep your OS in dark mode, and then choose to override a certain website to be in light mode (or vice versa).
Since writing that article in 2022, @Lukew has been working on the Web Preferences API.
It’s a way for sites to override the value for a given user preference (e.g. color-scheme preference) in a way that fully integrates with existing Web APIs.
The API is experimental and only available in Chrome Canary behind the “Experimental Web Platform Features” feature flag.
While the API works, Chrome itself doesn’t do anything with the changes yet. If you override a value on a site, the override is not persisted in Chrome.
Overrides get persisted in your Chrome profile. So if you re-open a website, or switch from your one Chrome to your other, the chosen override gets applied.
That way your OS can remain in Light Mode, while a certain website will always be in Dark Mode (or vice versa).
@bramus I prefer an OS toggle for dark mode. And the DarkReader browser extension to enforce my OS setting on all those websites that don't have dark mode styles. I don't want to set this site to dark and that one to light. Because my decision depends on ambient light in my room, not on any website.
@kolya This preference is not about forcing a site to Dark Mode if the site does not have a Dark Mode (like DarkReader does, often by injecting custom style sheets).
This preference allows you to have your OS in light mode while a website can be in dark mode (or vice versa) if you want.
@bramus Yeah, I read that. But I'm coming to different conclusions: Darkmode toggles on websites are a mistake to begin with. They mainly serve to advertise: "We have a darkmode!"
But the switch should still happen on OS level, for the reasons I mentioned (ambience light as a deciding factor). BTW you give no reason why the toggle should not be in the OS but in the browser instead. The only reason I see is that OS manufacturers currently don't give darkmode toggle the prominence it deserves.
@bramus So as I see it, you're trying to solve this in the browser, because you're only comparing to website toggles. Which are nonsense, I agree. And since you have some influence on the browser side but none on the OS side, you want to solve it in the browser. But it should be solved one level up imo by making the OS toggle more accessible.
> But the switch should still happen on OS level, for the reasons I mentioned (ambience light as a deciding factor).
That might apply to you specifically, but not to all. Other folks have indicated that while they do like their OS to be in Dark Mode, they like Light Mode when reading long pieces of text.
> BTW you give no reason why the toggle should not be in the OS but in the browser instead.
It’s not a mutually exclusive story. As detailed in my post the OS switch is your main switch for everything.
In addition to that, you can then use a browser-level override (for all sites) and even a site-level override. It’s the latter that I built something for, to serve as a POC.
The toggles in the browser only affect web content, not the OS nor the browser’s interface itself.
@bramus I like this - I'm not sure about it being per-site, because I feel like my preference for light and dark can depend on other things, like the time of day, rather than based on the specific site. But I can see how that would be useful.
That chrome devtools now has that neat little paintbrush button, but that the same functionality isn't surfaced within the normal browser settings or buttons feels like an oversight.
@bramus ah agreed. Yes, with the ability to choose a browser default, then upon switching the light/dark again when visiting a site, an option to "save this preference for this site" makes sense.
I'm all for baby steps though too - that little paintbrush should be accessible to people who otherwise don't know devtools are even there.
@bramus This looks promising. We already have light/dark mode per site using a class toggle. An API would hopefully open the door for using light and dark art directed sources for picture and video elements, in addition to the benefits of the light-dark() function.
@hi_mayank The extension should be considered as a POC for an eventual browser feature.
My personal wish is to be able to override prefers-color-scheme straight from within the browser.
If this becomes a browser feature, it would not have to use the Web Preferences API to override the value of prefers-color-scheme, as it can do so directly.
> it would really only be useful if it worked with existing sites that already use prefers-color-scheme
That’s how it works. Thanks to the API you can override the reported value for prefers-color-scheme so it works on any site that has a MQ for that.
Authors can use this API if they want to offer their own toggle button, so that they can override the media themselves (instead of toggling a class on :root and duplicating a bunch of CSS).
@bramus the in-browser toggle is the number one thing i care about. my worry is that this web preferences api will ship and we won't get the in-browser toggle, when really it should be the other way around.
deduplicating the CSS is a fair point, but imo that should be done using CSS features (e.g. style queries, mixins, light-dark), not JS.
@bramus I've been asking for a browser per-website colour scheme toggle ever since dark mode CSS was introduced.
The only real argument against I've heard is that it would be bad UX if there's a toggle that doesn't have an effect on many websites. So, ideally, your extension / future feature would include some way of detecting whether the current website would actually do anything differently, and disable the toggle button if not.
@bramus But given that there are now multiple ways to react to user preferences (CSS media query, CSS light-dark function, media query API, new preferences API...) it might be difficult for an extension to detect whether a preference change would have an impact!
@AmeliaBR The trigger for this button to become active/inactive could be the presence of a color-scheme meta tag in the document (as suggested by @Lukew on twttr).
Note that the Web Preferences API is there to override the preferences. Responding to a change set by that Web Preferences API would still be handled in CSS through a Media Query.
@jensimmons@bramus Browsers can always implement a “permissions” panel for things that might be finger-printable, giving the control back to the users to say whether they are ok with certain settings exposed or not.
Having a permissions panel like this standardized across browsers could unlock so many things! Like, things like :visited that are severely limited right now, could be then allowed if you trust a certain site with it. And so on.
@jensimmons The poll isn't if people want the Web Preferences API — an API which people from the WebKit team were very eager to shoot down from the start, discarding all spec author feedback along the way — but if people want a per-site Light/Dark Mode override.
I used the Web Preferences API in my POC extension because that's the tool that allowed me to make it work. One of the nice things I noticed about it, is that both site and browser can work together, instead of battling each other.
@bramus@jensimmons in addition to the privacy concerns, this seems like a booby trap for visitors. If your idea gets implemented, I now have at least 4 places where I need to check for color-scheme manipulation:
OS setting
Browser site-specific settings, with an afterthought interface no doubt
Devtools color-scheme overrides (see bottom of https://chromagen.io for links, they are all confusing and complicated except @FirefoxDevTools)
Having a way to override light/dark on a per-origin basis holds no privacy issue. That bit of data is already exposed today, as reported by your OS. Best case, being able to override this preference on a per-origin basis is adding some noise to the data.
@rdela@jensimmons And yes, I did use the Web Preferences API to build this POC extension, but that’s because it was the thing that allowed me to build it.
If browsers offered this as a built-in, they can do so without the Web Preferences API.
However, with the Web Preferences API, websites can integrate with that setting nicely, instead of having to roll their own implementation using localstorage and class-overrides.
That is not user exposed. Only (some) devs are aware of that.
Having this browser-level toggle can result in less browsers needing such a button, as now the browser can offer it. That way, users no longer need to search if a website has such a toggle and where it is.
@bramus@jensimmons I understood the things you mention in your response already, but disagree with your assertions. I do not see anything in this proposal that is a clear gain for people browsing, but see several places it could cause real trouble. Almost all of the benefits you describe would be equal if browsers made the devtools buttons you dismiss part of the normal interface. This would also avoid several of the pitfalls we mentioned, and not be confined to one site at a time, benefically.
I Iiterally say “Think of a button that is part of the browser's UI that you could click. Something like the button Chrome DevTools already sports, but then part of the browser UI, available for all users”
IIUC the thing you see different is that a click applies to all sites, something I also cover: “To not force users to set the value for every new site they visit, there would also be a setting at the browser level.”
@bramus@jensimmons yes and remembering sites is the problem there. I am with you until you want it to remember individual site settings, which opens up fingerprinting possibilities no matter how you implement it, especially for large companies like Facebook and Google who own many services across many domains. Also people typically would want that to apply across the sites they visit for a given range of time.
@bramus@jensimmons so on top of the interface challenges adding site specific color-scheme prefs would present, that I am near certain browser vendors would fail to rise to, it needlessly complicates the primary use case in service of the edge case who wants a different arbitrary color-scheme within short browsing sessions on different sites.
> I am with you until you want it to remember individual site settings, which opens up fingerprinting possibilities no matter how you implement it
If Service A from company X sees you as prefers-color-scheme: light from the UA, and Service B from that same company sees prefers-color-scheme: dark then that’s less tracking, no? One bit of identifying data got flipped.
(I am talking about the browser overriding the value directly here, not the Web Preferences API)
> Also people typically would want that to apply across the sites they visit for a given range of time.
You’re making a feature request here? :)
> interface challenges […], that I am near certain browser vendors would fail to rise to
I agree that this must be executed correctly and will be difficult to get right, but having these fears upfront doesn’t mean the proposal has no value.
@bramus@jensimmons I am not sure “the many dark mode toggle buttons in the wild” prove anything since many of them do not respond to prefers-color-scheme on load or value change. I do think that ultimately they are an anti-pattern for several reasons, so think anything that encourages adoption of accessible prefers-color-scheme awareness rather than toggle buttons brings tangible benefits.
@bramus@jensimmons regarding “short-lived,” yes, but that persistence might not be preferable. If I toggle one site during temporary environmental factors, the browser remembering that site preference when I return weeks later might be annoying rather than helpful.
> I am not sure “the many dark mode toggle buttons in the wild” prove anything since many of them do not respond to prefers-color-scheme on load or value change.
You are underlining why exactly we need this as a browser feature.
By putting the feature into the browser, we can get rid of all these (often incorrectly implemented) custom dark mode buttons.
> short-lived,” yes, but that persistence might not be preferable.
Seems like a preference to be set in the feature :)
@bramus@jensimmons haha no not a feature request ;)
Was trying to suggest that if I override my usual color-scheme preference that is usually because of a temporary environmental factor that would also make me want to override all other sites during that session. Or I am testing something, but both would benefit more from the color-scheme button applying to all sites, not just current tab. It would be convenient to have it in the browser toolbar though. I often open devtools to toggle these.
@rdela@jensimmons And that‘s exactly where this browser feature comes into play.
The existing button can’t be pulled out of DevTools and put into Chrome as DevTools is its own app that communicates with Chrome through the Chrome DevTools Protocol to manipulate the page’s appearance.
@bramus@jensimmons the examples I had in mind are more complicated than that, but even in this example you give, that makes this hypothetical person more identifiable, not less. Now Google or Facebook knows who it is with more precision. Many people make have dark mode set in OS, now Google or Facebook knows that and that this person overrides dark mode on service A. Greatly reduces possible profiles thereby improving fingerprinting accuracy.
@rdela@jensimmons This could be a problem for the Web Preferences API when implemented without the proper safeguards, but not for the browser itself.
The browser itself doesn’t leak whether you are overriding the value or not. It only reports “this is the value and it’s none of your business where that came from”
(And yes, I did use the Web Preferences API in my extension as that’s what was needed to create the POC. A browser can implement this natively, without needing the WP API).
@bramus@jensimmons the browser doesn't have to leak whether or not the value is overridden for Google or Facebook to know that, they only have to compare values across services and correlate with any other data point. If A is different from B, C, D, E, etc, it is overridden.
@rdela@jensimmons@mattburgess (can't read the article as it's paywalled)
In that case too "they" already have already identified you through some other means (be it by logging in, or some nasty way of fingerprinting as the quote suggests).
Using a different light/dark mode per site will not make you "more detectable" when that happens. On the contrary: it will add noise to the fingerprinting-data.
@bramus I have done my best to give you the benefit of the doubt here, but frankly am confounded by your last response. What you keep referring to as “noise” is the opposite, uniqueness that aids fingerprinting.
@rdela Say you are identifying people by their name. If on one occasion the person says their name is Jeff and on another they say their name is Samantha, then that's an ambiguous bit.
(Mutatis mutandis for light/dark mode)
When that one bit is part of more tracking bits, it adds noise to the whole set as the bit can't really be trusted to be correct. It can be 1 or 0, without the other bits changing.
@bramus Yep. TBH, I think in the future all the in-site dark mode switches will be obsolete, same way we don't usually see today toggles to change the font-size.
With the browsers providing a tool to control this, in the same way we can now adjust the font-size, supporting both themes will just become a thing you need to do as an author. And if not, I'm also all for browsers having built-in forced light/dark modes, even if not ideal.
Add comment