Dark Theme for Stackoverflow

[therenca]

Just a humble request, could we have a dark theme, for stackoverflow, some of us are afraid of the white, thanks

[aaronshekey]

A dark theme isn't out of the question, but we're not ready to consider it seriously.

I think it can be solved in a way that allows us to swap all our color variables on the fly based on 1) user preference 2) OS-setting. But, organizationally, Stacks doesn't have the code coverage to enable this. Huge swathes of the product would be bright white even if dark mode is enabled.

It also introduces another another axis to design against:

1. Desktop
2. Responsive
3. Dark mode

I can very easily see us painting certain layouts into a corner by forgetting to test dark mode, especially when considering that we have 200 some themes to style appropriately.

[bnickel]

A huge pre-requisite for this would probably be getting Stack Overflow completely onto Stacks for color, or at least to a point where the custom colors we do use are in a single less file. Right now, there are thousands of matches for color: # in our codebase, not just in .css and .less files but also in .cshtml and .cs files. 😬

I would love to see Stacks support a dark theme just largely as an exercise to see what it takes and I also prefers-color-scheme: dark, but that its probably low on their priorities considering the high cost of auditing and transforming the whole Stack Overflow codebase.

[samliew]

@aaronshekey This has been brought up again on Meta Stack Overflow, and I have quoted your comment there.

[aaronshekey]

I've got some thoughts about how we'd design this.

We could possibly flip the colors by default when a user requests dark mode, getting us 60% there, and then offer dark mode-specific overrides when the default gets it wrong. Every color should have a best guess dark mode equivalent that is enabled by prefers-color-scheme: dark and a class on the body / html that's toggled by user preference or some combination of both.

Let's say you've got fc-light on bg-white. By default it could probably switch to bg-black-900 and fc-black-050. Ultimately your markup might end up looking like fc-light bg-white dark:bg-black-600 dark:fc-black-200 to accommodate situational overrides.

This would allow us to account for situations like what's illustrated in Steve Schoger's really great tweet.

[gbjbaanb]

I'm not afraid fo the white, but when I'm coding in the dark, with all other sites in dark modes... I open SO and it hurts.

If stack has a huge number of color: styles all through their CSS, then its about time they got refactored into css variables, and from there, its easy to change them on the fly to a different set. Obviously its more work to choose the right colours for the site, but I imagine you'd get a ton of help from interested users if only you had the ability to change css colours.

So how about it: get those colour codes search-replaced into a separate css file with css variables, rationalise some that are so similar to each other, and then release into the wild so we can all contibute new themes, best ones get added to a new user theme selection preference. Pink glitter unicorn theme will (no doubt) also be added too.

Technically its easy once you have a css file full of variables, you change the stylesheet reference at the top of the page to a different one according to user preferences. It is that simple.

[aaronshekey]

Technically its easy once you have a css file full of variables, you change the stylesheet reference at the top of the page to a different one according to user preferences. It is that simple.

Conceptually, yep! Simple.

In practice, anything but. You have no context for our toolchain, legacy code, feature roadmaps, or the headcount and makeup of our organization.

A tiny slice of context: In our primary.css, the legacy stylesheet responsible for questions and answers, we have 9,920 declarations and 179 unique colors. We're not talking a few hours of work. This is a sustained effort of months.

For each hour we spend shipping a dark mode our users approve of, an hour is taken from shipping features that more directly affect our bottom line, enabling us to ship more features in a sustained, maintainable manner.

I agree that native CSS variables are a great approach. There are a few problems with that.

1. Our entire CSS toolchain is based on Less, which has its own compiled variables.
2. We support IE11, which doesn't natively support CSS variables. At our scale, which, is millions of page views, a polyfill doesn't seem like a great solution.
3. Each of our hundreds of network themes will also need to consider dark mode.

...

But, let's take a step back from the solution you're proposing and look at the context that hurts your eyes. You're in your code editor. You're blocked by something and have to go to our website. Your dark mode solution assumes that a visit to the website is necessary.

In a small exercise of reframing the problem, we might realize in our product roadmap that we may better serve users of Stack Overflow by building extensions / plugins that understand the context of their editor and allows browsing Stack Overflow without leaving their properly-themed editing experience.

[gbjbaanb]

1. 179 unique colours is wrong. I bet most of them are slight variations on the same colour that should be consolidated.
2. you allow those colours to be modified by users, who can submit their themes to you. No work required other than a bit of admin.

You can still submit the colours used in your less filles for customisation in much the same way, only now you have to change themes by changign the entire post-compiled css, its technically exactly the same. Much like bootswatch can produce different bootstrap themes.

But you say making themes is too much hard work... but building extensions for every common editor is not?!

[Mottie]

In the mean time, if you have the Stylus browser extension installed, you can use the Stack Overflow Dark userstyle which actually applies to almost all Stack Exchange sites.

[aaronshekey]

A loose list of tasks required to support dark mode from a conversation had today:

1. Refactor Stacks to be light / dark aware
2. Refactor our product to rely on 100% Stacks colors
3. Figure out how dark mode interacts across our 200+ themes
4. Drop support for IE11
5. Re-color all our illustrations
6. Refactor away from sprites and instead use our icon set for on-the-fly coloring
7. Continue to support everyday Stacks while doing all this

[Luc45]

@aaronshekey totally worth it 🚀

Curious: Does Stylus does all that to achieve the Dark Theme? Because it's already working, it's just not built-in to the platform yet. 🤔

[Mottie]

Stylus only injects a stylesheet into the StackExchange websites. The userstyle is set up to target almost all SE domains except for Area 51, which has a unique style.

[the-j0k3r]

Re: #356

May I ask why is it necessary to apply !important to all these rules?

As far as exploring goes, its not an issue of course.

I mention this because Im a maintainer for the Stack Overflow Dark userstyle and trying to override default stylesheet rules with !important requires dirty hacks.

[aaronshekey]

May I ask why is it necessary to apply !important to all these rules?

Stack Overflow has a lot of legacy CSS. A good portion of these rules are very specific. We do as much refactor as we can, but the idea of Stacks' atomic styles is that they are immutable. Adding something like mb12 needs to mean margin-bottom: 12px in as many contexts as possible.

We will be able to drop our dependency on !important in a theoretical future once enough refactoring has happened, but we're a long way out from that.

[the-j0k3r]

We will be able to drop our dependency on !important in a theoretical future once enough refactoring has happened, but we're a long way out from that.

At least its a possibility, even if it is a theoretical future =)

Stack Overflow has a lot of legacy CSS

Its a mammoth task to get towards the theoretical future you mentioned in any case. Thanks for helping to keeping things ticking =)

[bnickel]

As always, whenever the idea of dropping !important comes up, I need to point out that we'll never be able to drop !important from atomic classes given that atomic classes have such a low selection priority.

Take for example, the following code:

<button class="s-btn s-btn--badge">
    Active <span class="s-btn--badge">198</span>
</button>

Imagining I want to change the color of the badge, I can easily do <span class="s-btn--badge bg-green-400 fc-white"> to get a green badge today.

That's because while .s-btn .s-btn--badge { ... } has a priority of 0020 (20 for having two classes), .bg-green-400 { ... !important } has a priority of 1010 (10 for having one class, 1000 for having important). Removing !important would drop all atomic classes to 0010 and break the ability to apply custom styles to elements with multi-class rules.

Unless, of course, Stacks components become truly perfect and we never need to customize them.

[aaronshekey]

Ok, Stacks now supports dark mode. A ton of work has to be done in our production codebase, but this issue can be closed since this is the Stacks repo. ✌️

[aaronshekey]

https://stackoverflow.blog/2020/03/30/introducing-dark-mode-for-stack-overflow/ 😎

[the-j0k3r]

Congrats.

[mingyEx]

Are you guys considering adding dark theme support for cs.stackexchange.com ？

[b-kelly]

@KargathEx You'll need to ask that question on either Meta Stack Exchange or Meta CS. This repo is for the Stacks design system only - we generally don't have much public insight we can offer on the product teams' roadmaps.

[jtheletter]

How do I enable dark mode, please?

[aaronshekey]

https://www.youtube.com/watch?v=HjQsVdqf_mg