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.

See also T273600: Migrate Entity Page Views from JQuery to Vue and T54136: [Epic] Redesign Item UI for Wikidata repo. To use Codex to rewrite Wikibase interface may require server-side rendering of Codex, which we currently do not have.

Untagging project per its project description.

Looks like https://gerrit.wikimedia.org/g/mediawiki/extensions/Wikibase/+/5e834e427bcea91c3e4867fad70c2f4968063a96/view/resources/jquery/wikibase/themes/default/jquery.wikibase.entitytermsforlanguagelistview.css#5 needs to be updated to use Codex design tokens to fix this problem.

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

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.

Enabling the Accessibility for reading beta feature should give the option in Vector 2022 if it has not been rolled out to everyone yet.

Here's a replication URL:
https://www.wikidata.org/wiki/Q36500248?vectornightmode=1&useskin=vector-2022

This is for Vector 2022, not Vector. Vector development is pretty much frozen at this point and won't be getting an official dark mode outside the existing gadget.

Can someone please share some actual reproduction steps for this issue that explain how a normal user might encounter it? The replication URL is a convenient shortcut, but IMHO it alone doesn’t demonstrate that this is actually an issue people run into; and the beta feature mentioned by @Sjoerddebruin doesn’t appear to exist on Wikidata as far as I can tell.

Replication:

• enable vector 2022 skin
• go to https://www.wikidata.org/wiki/Special:Preferences#mw-prefsection-betafeatures ans enable accessibility for reading
• go to any page and select dark mode from the very prominent right sidebar

You have 375 users according to https://www.wikidata.org/wiki/Special:Preferences#mw-prefsection-betafeatures and people are reporting this issue:
https://m.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading/Reporting/www.wikidata.org

Dark mode is currently enabled for all wikipedias. At some point we will need to enable it for all wikis.

I guess Wikidata is currently on legacy Vector which is no longer seeing new features but the feature is available on mobile:

• login
• go to settings
• click advanced mode
• after page refresh set dark theme

WTF, the beta feature is only shown when you’re in Vector 2022?! I guess that explains this confusion…

Anyway, this is definitely something for Product to prioritize, I just wanted to have some clarity about what the issue even is.

In T369385#9998740, @Lucas_Werkmeister_WMDE wrote:

WTF, the beta feature is only shown when you’re in Vector 2022?! I guess that explains this confusion…

Some beta features are skin specific. It wouldn't make sense to show a beta feature for a skin that it has no effect on. Note many preferences work this way:
https://codesearch.wmcloud.org/search/?q=hide-if&files=&excludeFiles=&repos=

Anyway, this is definitely something for Product to prioritize, I just wanted to have some clarity about what the issue even is.

In terms of the issue - anything using Codex design tokens will just work by default.
So for example here you can safely and quickly change the following to use a Codex design token (most extensions have been able to fix this with a single patch that does find/replace):
https://gerrit.wikimedia.org/g/mediawiki/extensions/Wikibase/+/d7368ffba4422b9ad3c53e2d3d0b6f410e38a49b/view/resources/jquery/wikibase/themes/default/jquery.wikibase.entitytermsforlanguagelistview.css#27

e.g.

background: #eaecf0;

becomes:

background: var( --background-color-neutral, #eaecf0 /* fallback defined for skins that do not support CSS variables e.g. Vector legacy */ );

If you can't use design tokens for whatever reason, you can define your own CSS variables or provide overrides as described in https://www.mediawiki.org/wiki/Recommendations_for_night_mode_compatibility_on_Wikimedia_wikis . Feel free to reach out to me directly and I can provide further guidance on these options if needed.

https://github.com/wikimedia/operations-mediawiki-config/blob/64b31d9/wmf-config/skin-Minerva.php#L56-L65 needs to be removed if this ever happens.

The issue can still be seen at https://test.wikidata.org/wiki/Q227407?useskin=vector-2022&vectornightmode=1

Change #1079986 had a related patch set uploaded (by Arthur taylor; author: Arthur taylor):

[mediawiki/extensions/Wikibase@master] Use CSS variables for colors in wikibase UI for darkmode support

https://gerrit.wikimedia.org/r/1079986

I pushed a patch with some changes that are probably improvements.

That said, there are simply a lot of places in Wikibase where we use custom colours that don't neatly / obviously map to codex equivalents. I would say this needs a more thorough review of our use of colors in the Wikibase UX. What are your thoughts @Arian_Bozorg ? Should we make some changes to make this a little bit better? Or should we do nothing until we've had a complete review?

Right now, Dark Mode is simply disabled for Wikibase, so no user is currently encountering the issues.

Another option is creating variables for the colors in Wikibase and using those in the code. They just need to have different values depending on dark mode being on or off.

@Agabi10 Yes - that would be an option. I think that would still require a UX review, because we need to catch all our uses of colour codes and make sure that they map to something sensible (readable, meaningful) in dark mode. But with the perspective that we are migrating more and more of our components to Codex, and for the long-term maintainability of the codebase, it makes more sense to me to pick colours from the codex palette that already have dark-mode mappings.

@ArthurTaylor

Should we make some changes to make this a little bit better? Or should we do nothing until we've had a complete review?

Let's move ahead with the changes to make it better and we can do an audit of the pages when a UX designer is onboarded

In T369385#10225568, @ArthurTaylor wrote:

Should we make some changes to make this a little bit better? Or should we do nothing until we've had a complete review?

I’d welcome if night mode was quickly made usable (and then enabled) on entity pages, without waiting for perfection: the current setup makes night mode pretty much unusable on Wikidata; if entity pages had some dark-on-light blocks, that would be much more pleasing for the eye in a dark environment than the current situation that everything is dark-on-light. So the longer it takes until the first usable version, the longer it strains people’s eyes.

I second what Tacsipacsi said, it's specially gives bad feeling when one enables the dark mode and it goes from dark to light in matter of navigation in single site. FWIW I've enabled the dark mode in Wikimedia's Phabricator, it has some shortcomings and bugs but I already can't use the Phabricator without it anymore and have the same feeling about Wikidata also. I for myself have fixed dark mode issues on different extensions (e.g. ProofreadPage) but Wikibase was a little hard to setup for me, otherwise, I liked to go for fixing it myself also.

Change #1081067 had a related patch set uploaded (by Arthur taylor; author: Arthur taylor):

[operations/mediawiki-config@master] Restore support for Dark Mode on Wikibase pages

https://gerrit.wikimedia.org/r/1081067

Okay. There's a change there for review. It is incomplete, but it's hopefully better than nothing.

Change #1081913 had a related patch set uploaded (by Arthur taylor; author: Arthur taylor):

[mediawiki/extensions/Wikibase@master] Update Wikibase CSS to LESS to support theme variables

https://gerrit.wikimedia.org/r/1081913

Change #1081913 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Update Wikibase CSS to LESS to support theme variables

https://gerrit.wikimedia.org/r/1081913

Some screenshots of the UI for the current patch:

As you can see, absent the missing colour values, some UI elements are basically unreadable.

I commented on Gerrit: the second screenshot is pretty easy to fix; the third one with the termbox isn’t easy to completely fix, but making it readable (returning to the current status quo of dark text on light background) isn’t difficult.

In T369385#10258169, @ArthurTaylor wrote:

Some screenshots of the UI for the current patch:

This one looks ok to me, is there an element that I am missing

For this one we can use the colours for the datatype section from here:

Box: #27292D
Text: #EAECF0

The termbox here can use the same colours from here:

Box: #27292D
Text: #EAECF0

And the datatype from here:

Box: #27292D
Text: #EAECF0

We may need to leave the popover warning as is for now

Hi @Arian_Bozorg ,

Thanks for the suggestions here. Per https://www.mediawiki.org/wiki/Recommendations_for_night_mode_compatibility_on_Wikimedia_wikis#Avoid_static_values_for_inline_background_and_text_colors , what we don't want to do is use static colour values. Where there are matching codex design tokens, we can use those.

For example, for emphasized black text in light mode we have @color-emphasized. If we use this token, it would be inverted in dark mode on my wiki to #f8f9fa. But @Lucas_Werkmeister_WMDE already rejected this approach in the code review, because it changes the light mode colour from #000000 to something lighter (#101418).

So I need you to choose between three different options here:

1. Introduce new CSS variables for the light and dark mode colours - you would need to specify what the foreground and background colours should be in both light and dark mode, and this would great a longer-term maintenance burden for us since we're not aligning with Codex
2. Pick and use similar / appropriate Codex Design tokens - this is ideal from a maintenance point of view, but it might / will cause people to see slightly different colours in light mode than they are used to.
3. Leave the UI / UX broken in places where we don't have a Codex Design token that matches the current light mode experience.

I don't see a real problem with the first option. If Codex doesn't have a design token for what you need then you create your own variable or you suggest the addition of new design tokens in Codex for your needs. Codex is supposed to be more generic, so it's normal that it doesn't cover all and every use case of every extension there is.

I think it would be worse using Codex design tokens for something different than what the variable name says just because they have the same color you need (like taking one random with a name like @color-dialog-shadow that has #000 because you need the color for the text)

I'm not sure I can really describe distinguishing between #000000 and #101418 as a use-case. The use case in both cases seems to be "dark text on a light background", and it's not clear to me that introducing a new variable makes for an improvement in the user experience that is worth the additional maintenance. When we introduce custom colours, they are colours which will not be updated as the look-and-feel of mediawiki is updated, and colours that will not be included in skins.

Here are the two colours side-by-side:

I think, although a little lighter the colour provides enough contrast and aligns with codex components. But if this is something that will make things not meet legibility contrast standards then we may have to go with option 1.

@Arian_Bozorg Are you saying that we should conditionally go with option 1 (with a condition that I am unable to evaluate)? Or is that a decision for option 1?

In T369385#10272283, @ArthurTaylor wrote:

For example, for emphasized black text in light mode we have @color-emphasized. If we use this token, it would be inverted in dark mode on my wiki to #f8f9fa. But @Lucas_Werkmeister_WMDE already rejected this approach in the code review, because it changes the light mode colour from #000000 to something lighter (#101418).

I don’t interpret that comment as a rejection, but merely as a question. Actually, Lucas hasn’t even commented on @color-emphasized, only on @color-base. And while it’s okay not to change that color in the first iteration, I think we should switch from color: #000 to either color: @color-emphasized or color: @color-base in the long term. (Although that particular piece of code is used by a tab bar, for which the (very) long-term solution should be migrating from jQuery tabs to <cdx-tabs>.)

So I need you to choose between three different options here:

1. Introduce new CSS variables for the light and dark mode colours - you would need to specify what the foreground and background colours should be in both light and dark mode, and this would great a longer-term maintenance burden for us since we're not aligning with Codex

I wouldn’t necessarily use CSS variables for these colors. As long as there are different light and dark versions, CSS variables don’t bring much value. (CSS variables are useful because they can be used by TemplateStyles, gadgets etc., but I don’t think Wikibase should introduce a stable interface in this regard.) Just use Less variables that expand directly to CSS color values.

I’d also note that while it indeed has a long-term maintenance burden, because of which it shouldn’t be used if other alternatives are viable, it doesn’t increase the long-term maintenance burden: static colors, which are used today, have the same maintenance burden.

On the other hand, it’s not only maintenance burden that custom colors increase, but also inconsistency (which, again, isn’t new): the exact colors of Codex design tokens not only depend on the light/dark mode of Vector 2022, but also on the skin (for example, @color-base is #202122 on Vector 2010 and 2022, but #222 on Timeless). If we introduce our own colors, Timeless won’t be able to override it (technically Vector is the one that overrides, but since we all develop on Vector 2010/2022, that’s the effective baseline).

For anyone who wants to see how entity pages currently look like on Wikidata, you can either go to https://test.wikidata.org/ (where night mode is not disabled on entity pages), or use the bookmarklet javascript:void(document.documentElement.classList.toggle('skin-theme-clientpref-night')) to toggle night mode – the latter works on https://www.wikidata.org/ as well, regardless of the general disablement of night mode on entity pages.

moved back to task breakdown as current status of the ticket/ acceptance criteria is unclear

I think the acceptance criterion for the task should be that all parts of entity pages (minus gadget/site style-defined things, of course) appear light-on-dark when in night mode.

An intermediate acceptance criterion for the open Gerrit changes can be that all parts of entity pages are readable, i.e. either light-on-dark or dark-on-light, and never light-on-light, when in night mode.