@alexhollender, the Goals in the Description reference the iOS design. Here is some info about that which may be helpful:

• Ticket that lays out their color palette
• Blog post explaining their design goals and process

@cmadeo if you have any other info you think Alex should see, please include or send. Thanks.

I think the mobile apps have their own rendering engine, meaning layout and colours and such are fully within their control. Unfortunately on desktop, there is an infinite possibility of what colours the community may have chosen for their templates, etc. Attempting to override these individually will be a nightmare, and will never be foolproof. So basically I doubt we can borrow much from the mobile apps. We'll likely need to use CSS inversion techniques, but with that we can also tweak the contrast, hues, etc., and we can easily exclude imagery and other media. I don't think we can safely choose any exact colours, though :(

Project Requirements
Wikipedia only

I don't think it matters in this case. The same principles apply regardless of the project -- communities can format things however they wish, so we have the same level of unpredictability.

Desktop only

If we use CSS inversion, it would apply similarly to Minerva. I'd argue mobile support is important, given mobile web is the most popular access method.

In T221425#5125971, @MusikAnimal wrote:

...Unfortunately on desktop, there is an infinite possibility of what colours the community may have chosen for their templates, etc. Attempting to override these individually will be a nightmare, and will never be foolproof.

Would it be feasible to just exempt templates from the color change (in addition to images, maps, graphs...)?

In T221425#5125977, @jmatazzoni wrote:

Would it be feasible to just exempt templates from the color change (in addition to images, maps, graphs...)?

Doubtfully, but regardless templates make up much of the visible content (infoboxes, for example), so we'd want to apply the same colour changes to those too, I think.

The original implementation for the Nightpedia user script attempted to override colours. I never got it to work right; there was always some inline CSS somewhere that still looked like "day mode". Using inversion, like the current version (see T221403#5123935 for how to install), seemed to be the only real solution.

A better model for us would be to look to browser extensions, since they are designed to work on any website. I think we essentially are faced with the same problem.

If a fully tailored solution proves unworkable, we'll have to find a different way. The goal is to get to something that is imperfect but pleasing and effective, without heroic efforts.

Perhaps a mixed solution of sorts is possible? It looks like there are other ways to adjust the colors overall besides simply inverting them. E.g., the extension Dark Theme for Chrome provides a grayscale scheme that exempts images.

I notice it also turns the links bold. However, I see it blacks out many menu items.

Would it be possible to use an overall solution—grayscale, invert, etc.—but then to tailor the colors of a short list of important elements, like links, certain menu items, the Publish button...?

Would it be possible to use an overall solution—grayscale, invert, etc.—but then to tailor the colors of a short list of important elements, like links, certain menu items, the Publish button...?

I played around with this idea a bit and it seems to be possible. I started with the inversion and then for colors we want to be more specific about (links, buttons, panel backgrounds, etc.) I've set them to the opposite color we want them to be. I also made a small number of random fixes (e.g. the tabs up top weirdly use background images for their borders, so that needs to be unset by hand). Here are a few sample pages:

• as @MusikAnimal mentioned there are going to be a seemingly endless number of one-off modifications we'll want to make from a design perspective, so we'd need to scope that somehow
• there will be a bunch of image assets we need to re-create specifically for dark mode

Regarding mobile

In T221425#5125971, @MusikAnimal wrote:

If we use CSS inversion, it would apply similarly to Minerva. I'd argue mobile support is important, given mobile web is the most popular access method.

I agree with this. Mobile seems to represent a larger opportunity than desktop. I tried applying the same CSS to Minerva and it seems to work well. Some additional tweaks would be needed, but I think it would mainly just be adding some classes to the various existing rules.

Code

/* ===== INVERSIONS ===== */
body {
	filter: invert(1);
}

img, #p-logo a, .vectorTabs #ca-watch.icon a {
	filter: invert(1);
}

/* ===== BACKGROUNDS AND BORDERS ===== */

html {
	background-color: #000000;
}

/* primary backgrounds */
#mw-head, #mw-panel, #content.mw-body, .vectorTabs span {
	background-color: #FFFFFF;
}

/* secondary backgrounds */
.infobox, .toc, div.thumbinner, #simpleSearch, #simpleSearch #searchInput, #simpleSearch #searchButton, table, .wikitable, table.ambox-content, table.toccolours, .mw-notification {
	background-color: #DDDDDD;
}

/* borders */
body, #mw-head, #mw-panel, #content.mw-body, h1, h2, h3, h4, h5, h6, .infobox, .toc, div.thumbinner, #simpleSearch, #simpleSearch #searchInput, table.ambox-content, table.toccolours, .mw-notification {
	border-color: #CDCBC8;
}

/* ===== LINKS & BUTTONS ===== */

/* normal links */
a, #mw-panel .portal .body li a, .vectorTabs li a, .toctogglelabel, .mw-parser-output a.external {
	color: #996600;
}

/* visited links */
a:visited, #mw-panel .portal .body li a:visited {
	color: #839900;
}

/* red links */
a.new {
	color: #009191;
}

/* primary buttons */
.oo-ui-buttonElement-framed.oo-ui-widget-enabled.oo-ui-flaggedElement-primary.oo-ui-flaggedElement-progressive > .oo-ui-buttonElement-button, .oo-ui-buttonElement-framed.oo-ui-widget-enabled.oo-ui-buttonElement-active > .oo-ui-buttonElement-button, input[type='submit'] {
	background-color: #996600;
	border-color: #996600;
}

/* primary buttons:hover */
.oo-ui-buttonElement-framed.oo-ui-widget-enabled.oo-ui-flaggedElement-primary.oo-ui-flaggedElement-progressive > .oo-ui-buttonElement-button:hover {
	background-color: #BB800A;
	border-color: #BB800A;
}

/* ===== RANDOM FIXES ===== */
#content.mw-body {
	margin-top: 1px;
}

.vectorTabs span, .vectorTabs, #mw-head .vectorMenu h3 {
	background-image: none;
}

.vectorTabs span, #mw-head .vectorMenu h3 {;
	border-left: 1px solid #CDCBC8;
}

#mw-head .vectorMenu h3 {;
	border-right: 1px solid #CDCBC8;
}

Referencing T206094, perhaps this is possible with far less CSS. Screenshots:

CSS

html {
	background-color: #000000;
}

body {
	filter: invert(1) hue-rotate(186deg);
}

img, #p-logo a {
	filter: invert(1);
}

Thanks for the CSS! Indeed I don't think T221425#5129052 will work in all cases. Infoboxes for instance are not uniform cross-wiki; French Wikipedia uses .infobox_v2 while English uses .infobox. We've also only fine-tuned the Vector skin. Users may have their own CSS overrides too, and they will get applied after ours.

html {
	background-color: #000000;
}

body {
	filter: invert(1) hue-rotate(186deg);
}

img, #p-logo a {
	filter: invert(1);
}

This is the same implementation as the gadget we were talking about in T221403#5123935, except you've got 186deg instead of 180deg (barely noticeable). This will work everywhere and always, I believe, unless someone explicitly overwrote the filter property for the body in their user CSS (not likely, and not our problem).

I also had the logo inverted, because it's otherwise quite bright to me, and I think it looks really cool inverted! I'm not sure what the legal implications are here, if any. Without inverting it, you can't make out the "Wikipedia" text.

In T221425#5130793, @MusikAnimal wrote:

... Indeed I don't think T221425#5129052 will work in all cases. Infoboxes for instance are not uniform cross-wiki...

We're not, of course, trying to track down "all cases;" just the most common and important ones. How bad do info boxes get in this scenario? Is there an easy way to test this (and other solutions as they come up) out on wiki, so we can see how the variations and elements play themselves out in practice on Wikipedias?

I'm reasonably certain T221425#5129085 is our only feasible approach, and it will work in all cases. If we're okay with the way it looks (sounds like @alexhollender was endorsing it), then we should move forward with it. I don't think it's safe to try to override anything that comes from wikitext.

In T221425#5131733, @MusikAnimal wrote:

I'm reasonably certain T221425#5129085 is our only feasible approach, and it will work in all cases. If we're okay with the way it looks (sounds like @alexhollender was endorsing it), then we should move forward with it. I don't think it's safe to try to override anything that comes from wikitext.

I showed Danny the simple inversion scheme and he rejected it as too crude. His direction was to look at what was done for iOS, since the team there did a lot of careful research. So Alex was exploring whether we can find some middle ground between a quick fix and total control.

Users will be interested in this project. Josh says he got more comments on dark mode for iOS than for just about anything they did. We originally budgeted 50 points for this on the roadmap. So one way to look at this is to say what can we do that will fit comfortably within that budget but still look good? If inversion really is the only feasible alternative, I'm sure Danny will want to know that and will be very open to revisiting that decision. But are we positive that's the case?

What we need to know now is, what options are available (technically) and what pushes things too far? How much can reasonably be done to tailor an overall scheme? What elements can be controlled easily and what can't? (Also, as mentioned above, it would be great if I could get a way to quickly check out different solutions on wiki.

@jmatazzoni Did @Niharika show you how to apply the custom CSS to any wiki and/or page? That might be helpful for you.

Did you review the T221403#5123935 solution? It is not a complete "invert", per se. Obviously there is no solution everyone will agree on. This one I think Alex is in favour of (him to confirm), and at the off-site in San Diego, @Prtksxna gave the okay as well.

iOS/Android again have their own rendering engine. I don't think we can truly go off of their design.

It doesn't have to look exactly like T221425#5129085, though. There are still a number of other CSS filters we can take advantage of. @Jdlrobson touched on this at T221403#5129071. The thing we can't do is attempt to override styles that aren't part of mediawiki, like infoboxes. You will get inconsistent results across our own wikis, and lots of complaints. With a basic CSS inversion and filtering (no overrides of existing CSS classes), it will be virtually consistent everywhere, even 3rd party wikis.

Danny has directed us to do desktop only and Moriel agrees that doing mobile would be challenging. So let's please focus on desktop only and leave mobile web solutions out of this from here on. Thanks.

In T221425#5132021, @jmatazzoni wrote:

Danny has directed us to do desktop only and Moriel agrees that doing mobile would be challenging. So let's please focus on desktop only and leave mobile web solutions out of this from here on. Thanks.

Okay, but I think mobile is actually considerably easier because the layout is more uniform. Would this fact, and that mobile web is the most popular access method, not sway any opinions?

I would not think of mobile/desktop as a matter of difficulty, if that's the concern. If this is done correctly, it will "just work" on mobile without any extra effort.

@MusikAnimal I understand your concerns. Aside from consistency issues do you see other drawbacks to adding some additional code that enhances certain elements for at least part of the audience? The things I'd like to enhance are:

• infoboxes (background & borders)
• table of contents (background & borders)
• links (normal & visited)
• borders (heading underline, general content frame, search field)

I played around with the other filters and contrast was the only one that helped achieve the desired color, though it introduces new issues so I'm not sure if it's worth it. If we decided on 5-6 target wikis, and kept our list of elements to improve scoped tightly, I wonder if it'd be reasonable to do the inversion with limited enhancements, with the understanding that there would be inconsistencies within wikis, and for sure among wikis?

html {
	background-color: #000000;
}

body, img, video, svg, .mw-no-invert {
	filter: invert(1) hue-rotate(180deg);
}

/* backgrounds */
.infobox, .toc, div.thumbinner, #simpleSearch, #simpleSearch #searchInput, #simpleSearch #searchButton, table, .wikitable, table.ambox-content, table.toccolours, .mw-notification {
	background-color: #DDDDDD;
}

/* borders */
body, #mw-head, #mw-panel, #content.mw-body, h1, h2, h3, h4, h5, h6, .infobox, .toc, div.thumbinner, #simpleSearch, #simpleSearch #searchInput, table.ambox-content, table.toccolours, .mw-notification {
	border-color: #CDCBC8;
}

/* normal links */
a, #mw-panel .portal .body li a, .vectorTabs li a, .toctogglelabel, .mw-parser-output a.external {
	color: #6699FF;
}

/* visited links */
a:visited, #mw-panel .portal .body li a:visited {
	color: #6C66FF;
}

Notice how the TOC and infobox are differentiated from the article background, and how the borders are less intense all around.

Also, as I mentioned, I do believe we'd have to generate and use some image assets specifically for night mode. At the very least the logo, and possibly the watchstar as well.

In T221425#5132561, @alexhollender wrote:

... If we decided on 5-6 target wikis, and kept our list of elements to improve scoped tightly, I wonder if it'd be reasonable to do the inversion with limited enhancements...

As it says in the Description above, we're focusing on Wikipedia only. So by target wikis then, I assume you mean target language variants?

In T221425#5132627, @jmatazzoni wrote:

In T221425#5132561, @alexhollender wrote:

... If we decided on 5-6 target wikis, and kept our list of elements to improve scoped tightly, I wonder if it'd be reasonable to do the inversion with limited enhancements...

As it says in the Description above, we're focusing on Wikipedia only. So by target wikis then, I assume you mean target language variants?

Correct, e.g. the 5-6 largest instances of Wikipedia

In T221425#5132561, @alexhollender wrote:

Aside from consistency issues do you see other drawbacks to adding some additional code that enhances certain elements for at least part of the audience?

No enhances seem fine. It sounds like Night Mode is better fit as an extension, and there I think we're at liberty to override whatever we want. In general, if you've got body { filter: invert(1) hue-rotate(180deg); } in there (which you do), then we should be fine... the rest are just refinements, as you say. It shouldn't be a deal-breaker if those refinements don't work on a given wiki, since you'll still get a night mode, only a few things won't look quite as amazing :)

From your CSS, the only ones that stand out as possibly not cross-wiki to me are .infobox and .ambox-content. I have only checked a handful of Wikipedias but adding .infobox_v2 will at least cover French and Portuguese. For English Wikipedia, you probably want to account for the other ambox styles too (or maybe just .ambox will work), see https://en.wikipedia.org/wiki/Template:Ambox#type. I'm unsure how much these vary across other wikis.

I do believe we'd have to generate and use some image assets specifically for night mode. At the very least the logo, and possibly the watchstar as well.

The watchstar should be no problem, but the logos as you know are different on every wiki. If we've got the stomach for it, we can create all those assets, otherwise I'd try to think up at least a "fallback" for wikis for which we didn't create a dedicated night logo.

As it says in the Description above, we're focusing on Wikipedia only. So by target wikis then, I assume you mean target language variants?

I think it's fine to focus on our biggest product, but I sure hope what we deploy will be available across the farm. What Alex has produced in T221425#5132561 seems well-suited as a cross-wiki solution. On our focused wikis and skins, there are additional enhancements. Just remember many Wikipedians regularly go to Commons, Wikidata and Meta (our voters were on Meta for the survey, after all). It offers a poor experience to go back and forth between night/day mode uncontrollably.

I noticed on en.wikivoyage this use of colour in a legend.

Using the CSS in T221425#5132561, some of the colours are slightly changed (as seen below, which contrasts nightmode with original). To the extent that some of the colours in the legend don't necessarily correspond exactly to what is on the map. For example, the colour for "Far West Side" is quite different.

Some other potential issues:

• Maths images don't appear against black background.
• Certain images don't play nicely with the inversion (e.g. https://en.wikipedia.org/wiki/Samsung_Galaxy_SL, LilyPond/Score images)
• Multimedia viewer background is still white.

In T221425#5133190, @MusikAnimal wrote:

The watchstar should be no problem, but the logos as you know are different on every wiki. If we've got the stomach for it, we can create all those assets, otherwise I'd try to think up at least a "fallback" for wikis for which we didn't create a dedicated night logo.

May also need to do so for images like https://commons.wikimedia.org/wiki/MediaWiki_visual_identity and creative commons images in license info.

In T221425#5135177, @dom_walden wrote:

I noticed on en.wikivoyage this use of colour in a legend...

Thanks for the observation Dom, but let's remember that the scope of this project, as per the Description above, is Wikipedia only.

Project Requirements

• Wikipedia only
• Desktop only
• Night mode only (don't design for other reading modes, like Sepia, high-contrast, etc.)
• Don't invert images, logo, maps, graphs.
• Works for logged-in and logged-out users

@alexhollender, I think we need to add redlinks to the list of items we control. On my screen, they're currently a salmon color (see screenshot). Since redlinks have a particular meaning, they should probably be some darkish shade of red, I'd think.

Just out of curiosity, recent MacOS versions have added dark-mode as an OS level feature, and a new CSS media query has been devised to response to that setting: prefers-color-scheme. The spec is only a draft at this point, but it's already been implemented in Safari and Firefox on MacOS. It would be pretty cool if our solution responded to that OS-level setting, so I'm just wondering if that's been considered.

In T221425#5135759, @jmatazzoni wrote:

@alexhollender, I think we need to add redlinks to the list of items we control. On my screen, they're currently a salmon color (see screenshot). Since redlinks have a particular meaning, they should probably be some darkish shade of red, I'd think.

I've just created T221918.

In T221425#5136668, @Jdrewniak wrote:

Just out of curiosity, recent MacOS versions have added dark-mode as an OS level feature, and a new CSS media query has been devised to response to that setting: prefers-color-scheme. The spec is only a draft at this point, but it's already been implemented in Safari and Firefox on MacOS. It would be pretty cool if our solution responded to that OS-level setting, so I'm just wondering if that's been considered.

On a related note, @MusikAnimal @jmatazzoni have we thought at all about introducing some kind of hook/media-query that template editors could use in order to define dark-mode versions for their templates via template styles? I'm not sure how this would work technically, but I imagine it would be a worthwhile investment in that it would allow editors the ability to improve all of the individual elements that we are intentionally not going to touch. @Jdlrobson for any additional opinions.

In T221425#5148966, @alexhollender wrote:

In T221425#5136668, @Jdrewniak wrote:

Just out of curiosity, recent MacOS versions have added dark-mode as an OS level feature, and a new CSS media query has been devised to response to that setting: prefers-color-scheme. The spec is only a draft at this point, but it's already been implemented in Safari and Firefox on MacOS. It would be pretty cool if our solution responded to that OS-level setting, so I'm just wondering if that's been considered.

On a related note, @MusikAnimal @jmatazzoni have we thought at all about introducing some kind of hook/media-query that template editors could use in order to define dark-mode versions for their templates via template styles? I'm not sure how this would work technically, but I imagine it would be a worthwhile investment in that it would allow editors the ability to improve all of the individual elements that we are intentionally not going to touch. @Jdlrobson for any additional opinions.

I know @Mooeypoo is absolutely thinking along exactly those lines—to have a hook so that users could customize templates for night mode specifically. Moriel, care to elaborate?

I need to formulate an official stand on which skins we are going to support (I've put it on the Agenda for standup). I know there's interest in Timeless, so I had a look at that with the new CSS. The colors all seem to work fine in Timeless. But I do spot one layout issue: on page the main page title gets cut off at the top by the Timeless header. See screenshot. @alexhollender is there an easy fix for this?

@jmatazzoni given that the large majority of users use Vector I wonder if our time would be better spent making the dark mode experience for Vector better, rather than supporting other skins? Any additional skin we support means additional QA, bug fixes, etc.

In T221425#5151593, @alexhollender wrote:

@jmatazzoni given that the large majority of users use Vector I wonder if our time would be better spent making the dark mode experience for Vector better, rather than supporting other skins? Any additional skin we support means additional QA, bug fixes, etc.

I tend to agree. I'll get a definitive answer about that.

I imagine that the DarkMode extension will just include the generic styling, and introduce a darkmode class on the body element that skins can use as they see fit. i.e. we'll add fixes for each skin as we see fit, but skin authors can do those that we don't.

In T221425#5150771, jmatazzoni wrote:

I know there's interest in Timeless, so I had a look at that with the new CSS. The colors all seem to work fine in Timeless. But I do spot one layout issue: on page the main page title gets cut off at the top by the Timeless header

Turns out the filter property should be on <html> and not <body>. More info for the curious: https://bugs.chromium.org/p/chromium/issues/detail?id=877015 and https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context. I have updated Alex's CSS accordingly, everything looks fine now.

We would have had the same issue with Vector for pages that have fixed positioning in them.

I need to formulate an official stand on which skins we are going to support (I've put it on the Agenda for standup).

Dark Mode should be available to all skins, but we can certainly put our focus on Vector. It is my belief that if you spend all your time testing Vector, it is still going to look quite good in other skins. Right now there are a but a few Vector-specific overrides, and those elements don't exist in the other skins anyway.

In T221425#5151832, Samwilson wrote:

I imagine that the DarkMode extension will just include the generic styling, and introduce a darkmode class on the body element that skins can use as they see fit. i.e. we'll add fixes for each skin as we see fit, but skin authors can do those that we don't.

👍

@alexhollender I just spotted yet another type of link style that we should go ahead and control. External (off-wiki) links are now showing up as a light pink color. In the default mode, it looks like they are a slightly different blue from the normal link blue, but it's so subtle I imagine it's not on purpose. So I would imagine they should just be styled in our normal link color. (They are differentiated, of course, but the off-wiki arrow icon when appropriate.)

In T221425#5156658, @jmatazzoni wrote:

it's so subtle I imagine it's not on purpose.

I'm not sure about that.

See:

• rSVN95830: Give Vector a lighter external/interwiki color since monobook->vector changed…
• rSVN95950: Revert r95830's change to external and interwiki link colors.
• T63557: Color of Interwikilinks / external links should be changed to be more distinguishable from Wikilinks

I prefer a color distinction between internal and external links (including interwiki), especially since the external link icon can be removed (e.g. plainlinks class) or changed, but others disagree. (Yes, I know I can change it in my personal CSS.)

See also:

• T178862: Revisit different color of links for internal (inner-domain) and interwiki/external links
• mw:Design/Link colors

For folks arriving at the bottom of this page.
In 2020 an updated and further evolved implementation as user script can be found here: https://en.wikipedia.org/wiki/User:Volker_E._(WMF)/dark-mode. With help by @MusikAnimal this has been turned into a gadget which is enabled on English Wikipedia, interest of other Wikipedia communities pending.

@Volker_E,
Look at the dark mode implementation at Google or DuckDuckGo for example, and see this article: https://uxmovement.com/content/why-you-should-never-use-pure-black-for-text-or-backgrounds/
Consider changing the perfect black background to one that is dark but not perfect black.

DuckDuckGo uses #1c1c1c, Google uses #202124.

@Frap Please also the note in linked article

High Contrast for Accessibility
Pure black isn’t harmful to all users. Low vision users, who are sight impaired but not blind, tend to read text better with pure black text or white text on a black background. When designing for them, you may need to use black for an accessibility mode. For normal-sighted users, stick with dark gray over black to prevent eye strain.

In the best outcome we would have a pitch black and a dark mode, I just don't have enough capacity to drive any further changes to the user script/gadget at this very moment due to the important work on Vue.js and Deprecated-Design-Systems-team-board. Maybe next quarter.