@Volker_E thanks so much for taking a close look at this. Here is what the page looks like with your changes:

Apologies for the delay here, not sure if this is still needed but everything looks good on both iOS and Android.

@jmatazzoni @Mooeypoo "dark mode toggle - B.pdf" is a mockup of what we discussed in the meeting yesterday. My initial concern is that it is a new, non-standard interaction for turning a setting on/off in a very visible part of the interface. It doesn't follow the standards we as a design team are trying to champion, nor is it generally a familiar/common pattern (cc @Volker_E). I am of course happy to discuss further, and to show it to the design team to see what others think.

The alignment of the references looks good on mobile, and it seems like there is no longer any clipping of li numbers.

Looking sweet. Here are screenshots of what I'm seeing:

	normal	admin
iOS
Android

Initial sketch below. I'm happy to put this in Invision/freehand to allow for more direct comments if that's helpful.

@Jdlrobson I think we've discussed potential issues with such broad QA asks like this in the past. Is there any way to provide some clues as to what might be off as a result of this change?

@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.

@MusikAnimal I put the css in a code block on https://en.wikipedia.org/wiki/User:AHollender_(WMF)/night_mode_css. Feel free to modify the formatting (plain text, etc.) as needed. For future changes I will make sure to keep the formatting consistent to whatever I find it to be.

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.

@JTannerWMF @marcella can you verify if this describes the same issue as T208827?

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.

@cmadeo if you have time to work on this that'd be awesome, no worries if not.

@nray Version 74.0.3729.108 (Official Build) (64-bit)

@Jdlrobson nice catch, I don't believe that was intentional.

@Jdrewniak here's what I'm seeing currently on iPhone and Android:

@ovasileva it looks like this task might be able to skip directly to code review — it's a small change and the patch is already there.

@Esanders nice catch

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?

@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)

@Volker_E sorry for misunderstanding. Though I see no difference in the spacing above the h3 either? As I mentioned I am fine with signing this off, just trying to clarify if the patch is having the desired effect.

@Niedzielski I've only been able to find one bug thus far. Sometimes when navigating to the Permanent link page from the overflow menu I see a flash of the menu on the Permanent link page. I can't reproduce this consistently, and I have not yet seen it on iPhone/Safari (only desktop & Android/Chrome).

video of menu flash	screenshot from 0:03 seconds
menu flash.mov1 MBDownload

@Capankajsmilyo does the mockup in T208827#5127816 look good to you? If so I would like to move this out of the design column.

@Jdlrobson thank you

@Jdlrobson thanks for clarifying. Can you give an example or two of a page that this issue occurs on for logged-in users? I was unable to find any.

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

@Jdlrobson I think the need is still relevant though I don't know when we'll get around to it. I think we'd benefit from having a template for non-article pages.

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:

@Volker_E apologies for the delay. I've just checked on beta. It looks fine, though I don't see any difference from production. Is this expected?

@Volker_E maybe you have suggestions of how to do this properly?

To clarify: is this only the case for logged-out users? When logged in I am able to view the source of (and edit) https://en.m.wikipedia.org/wiki/Barack_Obama. When logged out I get the toast message "This page is protected to prevent vandalism." If this is only an issue for logged-out users we should update the task title and description.

Looks great

@TheDJ thanks for your thoughts. Mainly out of curiosity - do you know why there isn't a link to Logs in the Tools menu in Vector when viewing an article? There is one when viewing a user page.

@pmiazga thanks for the feedback. I think it makes sense for @Niedzielski to respond to the first few points because I don't know which of those cases are unique to the staging environment, and which might actually occur in production.

@nray well that height was set based on the assumption of the minimum number of items that would appear in that menu. Do you know if the case in the screenshot you posted above is a real one, or something that would only occur on staging. I also notice that there is no history icon in that screenshot, which seems peculiar.

+1

@Jdlrobson:

• yes, let's make the change for all modes.
• good point about userpages vs. article pages. I think it's fine to include it.
• desktop vs. mobile version of empty state... sounds like we should aim to eventually resolve this

@ovasileva @pmiazga @Jdlrobson after looking at @Tbayer's research again, and consulting with @CKoerner_WMF, I think we should consider including Logs (Special:Logs) and Articles for deletion (Wikipedia:AfD) in the main menu for AMC users.

@Jdlrobson

For consistency, possibly. Would you want to show the page actions for all modes (doing for all modes would be relatively simple).

Can you clarify what you mean by all modes?

@Jdlrobson back to you. I didn't make many changes. I think it looks decent though. Here is my css in case it's helpful to you:

div.mw-history-compareselectedversions {
	position: sticky;
	position: -webkit-sticky;
	top: 0;
	background: #ffffff;
	z-index: 10;
}

Following up on the remaining open topics:

@Pigsonthewing can you clarify what you mean here?

In T213778#5096826, @Pigsonthewing wrote:

Solving T213778 will not solve T219707.

+1

Updated sketches based on a review with @Nirzar.

@Jdlrobson I don't know of a newer epic. I believe our latest thinking here is to abandon the current jump-to-top feature and replace it with sticky section headers (T197718), which we've determined is a better solution for the general goal of improving in-article navigation. This makes T196641 and T187804 invalid/not worth addressing. It also means we should rename this epic (perhaps Improve in-article navigation).

@Jdlrobson for both IP and non-IP redlink userpages would it be preferable to show the toolbar? We discussed a similar case in T211775 recently. If so, happy to create a separate task for this.

	redlink userpage	redlink IP userpage
without toolbar
with toolbar

@jmatazzoni @Nirzar I've sketched out the logged-in experience, and refined the logged-out experience a bit. Please review when you have a moment.

Spoke with @Jdrewniak offline. We've decided to live with the ~¾ of a pixel discrepancy 😊

@CKoerner_WMF thanks for pointing that out.

@Jdlrobson sorry for the lack of clarity. The non-IP redlink userpage experience looks good to me. Regarding the IP redlink userpage experience, here is a separate task for that: T220114.

@ovasileva would it make sense to merge this into the relevant AMC task (once it exists)? I believe it's asking for what we plan to do

In T192313#4154191, @Jdlrobson wrote:

1. Move rotation onto the pseudo before element like we do for mf-mw-ui-icon-rotate-anti-clockwise

@Niharika thanks for the notes. I'm realizing that I should work on a sketch for the logged-in experience, which I will do shortly.