@MSantos @vadim-kovalenko, I’m still very confused why it appears some of these articles are being fixed. But only as one offs and tons of other errored articles remain. Wouldn’t fixing the templates improve them in bulk? What makes them unique?

Examples of what I mean:

Template:Episode_table issues
Fixed: list of secret word of alex Mack episodes, list of celebrity death match episodes
Still broken: list of walker Texas ranger episodes

template:Infobox_baseball_biography
Fixesd: Andy Ashby
Still broken: Joel peralta

I’m providing these examples to universally improve the templates. I really don’t want to keep having to dig and find more examples as I’m providing them for bulk improvement, not one-off fixes. It’s very rare I revisit these specific random articles. But it’s extremely likely I’ll revisit pages that use them templates almost every day.

@Ijm8710 I didn't have time to take a deep look into it, but it could be just cache being refreshed slowly.

@MSantos just checked the wmflabs preview pages and perhaps you’re right (if so my apologies). Was just surprising as it always appears the examples I provide are fixed ahead of the other examples that are identical. But perhaps vadim or whomever is fixing it is fastracking those examples leading to me jumping the gun🤷‍♂️

Hi @Izno! As per discussion here and this thread (check 'Calculate text color automatically depending of the table header background color' there), could you assist with Template_talk:Episode_table issue?

Regarding infoboxes: Infoboxes 'natively' support TemplateStyles (well, besides the core styles) since a month or two ago on EN.WP, so the related inline styles can be moved over to TemplateStyles and then "you" (where you is the app authors?) can just override the related classes (which are also live e.g. now it's not just generic .infobox th that you can target [and shouldn't, for infobox won't be a table forever], it's .infobox-label) in the general in dark modes. (Usually it's just headings from what I've seen, but hey, you can be more particular if you want.) A bot may be able to do it faster if someone wanted to put one together and I've had it in mind to request one, but just haven't gotten around to it.

Regarding classes elsewhere: I work on them when I see them and fancy strikes. I don't know of any coordinating place to work on making pages mobile-friendly (which is tangential but does hit one of the points, "use a single root element"). Lots of legacy to go around and it Just Works for editors (predominantly on desktop, etc. etc.), so things don't change fast...

Regarding limiting the colors (cc @Gonnym):

Is it possible to add some logic for style calculation of the table header or restrict styling of these elements? For dark/black themes in iOS/Android might happen issue with colors overlap like in this example (check Episodes section) - https://en.wikipedia.org/api/rest_v1/page/mobile-html/The_West_Wing_(season_7)?theme=dark Additional details - https://phabricator.wikimedia.org/T284327 VadimKovalenkoSNF (talk) 08:23, 6 September 2021 (UTC)

Restricting styling isn't going to fly because now you've got contrast requirements for most people (using a light skin) on one side and contrast for a very few (using a dark skin in the apps [alone]) on the other, and that requirement sandwich is not a good one. (Ever moderated a Discord server? It's like trying to get user name colors happy for both light and dark skins, something I kvetch about regularly.) That's even ignoring user desire to set their own colors. (I think T37704 should be declined for that reason alone even if I would personally be happy to see inline colors removed.)

It's not obvious to me where the burden should be to support dark themes, especially as dark themes are not in core or even in a MediaWiki extension (e.g. T122924. It's a pity CommTech punted on T26070 or wherever their version of that was - y'all need to get your shit together given you have an app that needs to care about such things already! 😄). Accordingly, I disagree that "fix the template to do fewer colors" is the correct solution.

The solution probably ultimately requires inline colors to be inverted, prefers-color-schemed, or be inherited, I just don't know where, and whether it's in pure CSS or possibly also in JavaScript or even (since you are dealing with the app) in PHP/something app-side. Some you + me holding hands options (and there may be others):

1. There could be support in core or in the app for a class on body or html to hook on to indicate it's being viewed in a dark theme.
   1. Subsequently requires template authors to convert templates to use TemplateStyles and subsequently to know and style for that.
   2. Probably needs wide consensus because as a template author I want the name to be stable and that approach to be the preferred approach.
2. There could be a generic class like current nomobile to indicate a certain element has been marked up with background colors that should instead have its styles be inverted, prefers-color-schemed, or be inherited (obviously with a dose of !important).
   1. This requires template authors to convert templates to calculate colors issues. Maybe a similar mountain to deal with to 1.
   2. May need a similar consensus to 1.
3. Something like T200632 gets done.
   1. Same issues.

Separate to all those 3, you still have arbitrary uses of color in the wild you need to support that don't involve templates, so even if one of those gets picked, you need to figure out a way in the app to deal with the problem. (And once you've done that, there's no forcing function to implement any of those.) Hence my mention above that it could be app-side. There 0 reason that I can see that the app can't be the system responsible for inverting/stripping the colors of interest.

This issue is fundamentally one for MediaWiki-Core-Skin-Architecture or some other technical body to fix and/or provide direction on IMO. That direction may have already been provided somewhere among all of those linked tasks or maybe on MediaWiki wiki or Wikitech. I don't know. I do know the issue has continued to be kicked down the road, which is why you're stuck dealing with it. Maybe @Volker_E or @Jdlrobson knows something more or has feedback to give on some of those options.

Finally, regarding the episode table itself, it particularly has a class already today, though I hate the name (it's wikiepisodetable). That might get changed...

@MSantos, wanted to circle back just once more please on Infobox baseball biography vs Infobox NFL biography please.

nfl bio (see Aaron Rodgers):
both light and dark work great for top infobox👌

baseball bio (see Ronald acuna jr):
light works well, but dark doesn’t carry the themes the same way

I asked why for baseball bio in dark mode, his name box does get themed in a blue box, but the subboxes below that such as “mlb statistics (through 2021 season)” remain unthemed and vadim said this is because the templates are different

They are, but this makes little sense to me as those same subboxes theme fine for both light and dark theme for nba and nfl.

If the app can theme the subboxes in both light/dark themes for nfl/nba…
and if those subboxes are indeed themed fine in light mode for mlb…
why is it blocked out for being themed in dark mode for mlb?

It’s not as if the template itself doesn’t theme them at all and hence that’s why there’s no theming. It’s just only rendering in light while the other sports can have the render carry over

Unifying the styling of mlb templates to handle similary to nba/nfl would also have a secondary benefit so that Ronald acunas name remains readable in his top name box as well

A user reported an issue with dark/black themes on this article:
https://de.wikipedia.org/wiki/Deutschland?wprov=sfla1

Another place you can see this problem is on tennis scoreboards. For example on https://en.wikipedia.org/wiki/2021_Australian_Open_%E2%80%93_Men%27s_Singles, here is what the results tables look like on one of the light themes, vs one of the dark themes.

Another report from Android email, including this screenshot:

Another report from Android email -

If you use the dark theme in the Wikipedia Android App, the text in info boxes (such as "quick facts") is not readable. It looks like white text on white background is used. It is possible to mark the invisible text and it can be seen then. If you look at an article of a band for example the left column is readable (Singer, guitarist and so on). But the right column is invisible. If one of the members has his own wiki article, the name is readable because it's blue (link).If you use another theme in the app, the issue is not present.This is reproducible with different android phones, but not on every article. Take the article for the band sylosis for example. If you take a look at the English article, everything is fine: https://en.wikipedia.org/wiki/Sylosis?wprov=sfla1

The German article however has the described issue: https://de.wikipedia.org/wiki/Sylosis?wprov=sfla1

From the german article

Another report from an Android user

Mathematical text written with "<math display=block></math>" are rendered black regardless of the chosen theme, making them difficult to read in Dark mode and invisible in Black mode. Additionally, math written with "<math></math>", are rendered grey in Dark/Black mode when Image Dimming is enabled despite not (semantically) being images. I believe this is related to issues T268279 and T255038.

Another report
From Znuny: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12145096

Hello, I noticed an issue: if I use Wikipedia app in dark mode some images like this signature are not visible. They’re just black like the background. See this screenshot for details. https://de.wikipedia.org/wiki/Elton_John?wprov=sfti1

Realized this task is not connected to https://phabricator.wikimedia.org/T252904 which collects many related issues.

Report from Android user:

The first screenshot is of the white theme which allows you to see the text written in black. Whereas the second screenshot viewing the black theme makes it impossible to see the text within the third row table. Thank you for your time.

Android version: 12
Wikipedia version: 2.7.50399-r-2022-04-04

Report from an android user:

Latex renders are not themed causing them to be nearly unreadable in the dark theme and unreadable in the black theme. Other diagrams are also affected however the user has the option to expand the image which puts it againts a white background. Potential solutions include:

• Adding alternative variants with alternative foreground colors.
• Applying a filter on the client to change the foreground color.
• Rendering the latex or SVG diagram on user with the user selected foreground color.

@MSantos what is the status on all this? I have been completely mum on this for an entire year (though the issue has stretched closer to 2). And the issue is no better. At one point you guys hoped editors would take it into their hands to better style, but you can’t lelave it up to them, most don’t notice those things and I’d say it’s more often than not that headers are completely unreadable in dark mode. Is there any plan whatsoever to have any relief/hope for this ever to improve? If anything, it’s only gotten worse for most templates.

(I updated the description of this task to serve as more of a tracking task. There was recently a patch that resolved a subset of issues with table backgrounds (T264474) but there are still plenty of remaining cases, and I hope the explanation in the description helps going forward.)

@MSantos / @Jgiannelos: This task was moved to the "Sign off" column a year ago. Should this task be resolved instead? If so, please update the task status (via Add Action... → Change Status in the dropdown menu). Thanks.

@Seddon @Dbrant a sister task was filed on this in 2020. It’s 2023 and the issue is no better but the task has been marked resolved. I’ve said repeatedly it’s no better and just met with silence. Please, is there any chance to check in

Any issues with article content in dark mode, need to be fixed on wiki. A page https://www.mediawiki.org/wiki/Recommendations_for_dark_mode_compatibility_on_Wikimedia_wikis now exists to help guide editors on how to do this.

If there are specific problems with the dark mode version of pages in the app please feel free to report them on the talk page, and I'll help fix them and update the documentation where needed.

@Jdlrobson @Seddon can you please please elaborate upon this. This has been such a longstanding issue. I was filing tickets on this back in 2019 and put a ton of time on this working with @Art.tsymbar @MSantos @vadim-kovalenko @JMinor

Seddon this is very different from what you stated earlier.

Part of the issue is a ton ton of articles still have so many issues on this and have not even made incremental efforts to get better. Leaving this in the hands of editors will just stagnate the issue. They haven’t cared thus far.

I’ve pleaded for a way to have a high level logic to it. If the background is super dark, go white text and vice versa with black text. It’s not 100% foolproof but would lead us in a much better spot. Seems like you’re just ignoring it, passing the buck rather than dealing with the headache of trying to get it to a better place.

I’ve tried following up for months hopelessly only to be met with silence. Would love to connect by email or even better by a quick 15 minute zoom/teams but please at least provide a bit more info on this as this doesn’t seem right and the issue is still so prevalent.

@Ijm8710 this is an on-wiki issue. Per my invite please let's discuss specific issues on the talk page. Please be sure to provide links to specific pages which are not working. My team is looking at dark mode for web this year so we'll be taking a holistic approach that benefits the entire platform, not just apps.

@Jdlrobson to mention a talk page is ridiculous and so insincere. You’ll see ton of unresolved items relating to this on this and a few of the other open tickets which you are needlessly closing. Examples have already been aggravated. If you’re sincere about working with the editors then why are almost all of the major templates still in the same place they’ve been for 3-4 years.

Most apply to
The major sports templates for athletes, albums, TV shows and movies.

And this ticket was opened for articles not wiki so why close it then if it’s unresolved

Lastly you say it’s an effort now but that’s what they’ve kept saying for years as different pms take over. It’s never gotten better besides a few small changes by vadim

Essentially if you want examples on an article level simply look at the top of the very ticket you’re choosing to close. Many of the examples have already been aggregated for you!!!! @Jdlrobson

@MSantos already copied many of my examples up top that I compiled. And they already have specific examples for each type of issue (as of course an issue on one athlete affects all similar templates across the board). Everything you’re asking for has been there for years.

In T284327#9228985, @Jdlrobson wrote:

Any issues with article content in dark mode, need to be fixed on wiki. A page https://www.mediawiki.org/wiki/Recommendations_for_dark_mode_compatibility_on_Wikimedia_wikis now exists to help guide editors on how to do this.

Hmm, having two classes notheme and mw-no-invert doing similar things isn't great. Based on codesearch I think I get what they're doing, but when to use one versus the other should be somewhere on that page.

this is an on-wiki issue

As for this, I reject the assertion in the general (not the specific case of templates) per my pretty lengthy comment above, particularly the paragraph starting from

Separate to all those 3