Either that or the same screenshots as above in the task would help, yes! I was under the impression this was the final state.

The contrast in dark mode, especially with links, has now become significantly less. I have normal eyesight and have huge issues to read the links when they have either the yellow or orange backgrounds.

I don't think these changes are actually an improvement in light mode. I've heard and read from several people of the Dutch Wikipedia they find the new background color of unpatrolled new pages too light.

Did you do a full refresh, emptying your cache? I also had the issue on my work computer but it went away after that.

Due to the lack of a response so far I've already prepared the patch, I don't think there are other viable options and I rather have this fixed than waiting for a formality approval.

In T372702#10103189, @tanbiruzzaman wrote:

Just discovered something about this. On Wikimedia Commons, I was in desktop mode, and everything looks fine. Then I visited to Wikipedia (bnwiki), showing logout here. Then visited Commons again, still logged in until I changed it to mobile view. Commons and Meta shows logged in on the desktop view, logged out on the mobile view, while the rest of other wikis shows fully (mobile/desktop) logged out.

The first two things only happen on windows smaller than 1120 pixels wide and is needed to keep the content readable.

Closest option at the moment would be @background-color-progressive-subtle I would assume?

How can a wiki opt-out of this for their local banners (MediaWiki:Sitenotice) if they have the local (interface) moderators that are aware of these display issues and are able to mitigate these?

In T365311#10043176, @MusikAnimal wrote:

Proper dark mode styles are now ready for review: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CodeMirror/+/1059166

This includes reworking the search panel to use Codex CSS components (T371436), which in turn gives us dark mode styles for free.

In T365311#10042667, @hgzh wrote:

The temporary color inversion doesn't work with os clientpref by the way.

Works on https://test.wikidata.org/w/index.php?title=Wikidata:A_random_test_page&action=edit&useskin=vector-2022&vectornightmode=1

Fixed on my side.

Classes are inserted on the correct element with the above patch:

Sorry, wrong task ID!

With dark mode being more rolled out now could we please add the CSS classes for the time being?

In T369391#9958455, @Tacsipacsi wrote:

In T369391#9957534, @Jdlrobson wrote:

• Visit https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%9D%D0%BE%D0%B2%D1%8B%D0%B5_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D1%8B

I see no colors and thus no problems in safe mode. FlaggedRevs certainly does have a number of night mode incompatibilities, but this particular page is the fault of on-wiki scripts/styles.

In T369391#9957546, @Jdlrobson wrote:

https://gerrit.wikimedia.org/g/mediawiki/core/+/c86466f5dcf24c9ce51c482f1b7796bf511ad1d8/resources/src/mediawiki.special/newpages.less#13 likely also needs updating but I couldn't replicate how locally!

On a new pages patrolled ($wgUseNPPatrol) wiki, create a page with a user whose edits are not patrolled (e.g. an anon, but Translate’s FuzzyBot also works for me), and then look at Special:NewPages with a user who is User::useNPPatrol() (e.g. an admin).

However, I don’t think this style is in scope for this ticket – other than both having something to do with patrolling, there’s no connection between FlaggedRevs and core’s new pages patrol. I think the two should have their own tickets (and since FlaggedRevs was the first here, probably T369391 should be about FlaggedRevs).

In T369385#9994519, @Lucas_Werkmeister_WMDE wrote:

Using the “dark mode toggle” gadget, this looks totally fine to me to be honest:

I haven’t been able to find any other dark mode – even in Vector 2022 (which is not our default skin)., the toggle I know from English Wikipedia isn’t shown.

^ @Jdlrobson Dark mode works as expected, it's the font size that is the issue.

This would also be nice for class=skin-invert-image.

Also, when opening on of the popups that feature a new item it briefly flashes very light blue in dark mode.

This just shows the technical debt the Wikidata interface has had for more than 10 years. A rewrite to Codex is probably easier at this point.

For the latter, probably needs T360494 for colors that are close to the existing ones.

The existing token, background-color-backdrop-light, has 0.65 opacity instead of 0.8. Would that make things still readable in both modes?

In T366371#9957531, @Jdlrobson wrote:

@Sjoerddebruin how do I get that highlighting? Is it a gadget or part of FlaggedRevisions? I can't seem to find the associated CSS but would like to create a new phabricator ticket!

It's readable for me but not sure if it checks all the contrast stuff, also some colours looks a bit too same to each other.

In T365311#9957461, @Jdlrobson wrote:

@MusikAnimal could we add skin-theme and noinvert along with cm-mw-colorblind-colors in the mean time?

@Sjoerddebruin perhaps try this in your user CSS as a workaround - does that help?:

.cm-mw-colorblind-colors { filter: invert(1); }

So, the edit page is now enabled for dark mode. I'm unable to do edits without syntax highlighting and I can't keep switching modes all the time...

Seems like unpatrolled edits lack Codex-tokens for background styling.

Note that portals have a very low amount of visitors and maintainers, at least on nlwiki. Personally I don't see the effort of fixing 20 years of unmaintained styling myself, it's too much work for minimum impact.

Any idea when this regression would be fixed? I keep hearing people complaining about this issue on other platforms.

I agree, this seems essential for the further roll-out of the dark mode.

The app would respect "skin-invert-image" at some point I guess?

The "background-color:transparent;" in the headers of the infobox don't help much and are discouraged.

In T252904#9910551, @putnik wrote:

Hide/show button in the desktop collapsible block is not adapted for the dark mode:

.mw-collapsible-toggle-default .mw-collapsible-text {
    color: #0645ad;
}

I agree with the above, these colors (at least in light mode) are way too intense and saturated., distracting from the actual content itself.

In T360386#9890799, @Jdlrobson wrote:

In T360386#9890771, @Sjoerddebruin wrote:

This change should have been communicated.

Hey @Sjoerddebruin this was communicated in tech news in May (T363932) I'm sorry you didn't get the message.

Currently I had to disable the infobox part of this change which is not good for our mobile readers, as there is no way to only opt out on desktop.

Rather than disable the infobox changes, I would recommend following the guidelines in T363932 and moving them to MediaWiki:Minerva.css to avoid breaking mobile. Let me know if you need help with that.

This change should have been communicated. I was very surprised to see such drastic changes to primarily the display of infoboxes on desktop.

This is hugely disrupting my workflow. What could the alternatives be, do an API call on (X) new items created by the user?

In T47224#9818024, @Jonesey95 wrote:

Why is this bug report from 2013 still open? I just had to remove a link from a Wikidata page that was a copyright violation, but without an explanation, my edit might look like vandalism. We need to be able to add a short explanation like "copyright violation" to our Wikidata edits. This should be a no-brainer.

@hoo Have you find time yet to process the new run completely? For others: I've asked during the Hackathon for another run as the data is more than two years old at this point and there is no sign of progress on the other task.

I tried that, think the lack of sleep didn't help. ;) Fix is applied, thanks for your help.

Testing too.

Should we apply the fix in T356467 to just all buttons?

This is how the same fix would look on the recent changes, which doesn't make it much better imo. Is there a relevant task for the horrible icon spacing btw?

@Tacsipacsi Could you provide the full adjusted script? I'm losing the overview based on the above.

Thank you for the adjustments, I will apply these fixes!

We could apply some margin or gaps at some point in a different task, but this is a lot better already:

Could you name the gadgets where you would like to move the popup around? And for what kind of actions?

This has ben fixed in the meantime.

This is fixed for the moment by doing the above.