This is very similar to recently fixed T264474 but https://en.wikipedia.org/api/rest_v1/page/mobile-html/The_Idolmaster_Movie%3A_Beyond_the_Brilliant_Future!?theme=dark is still problematic.

That is because https://en.wikipedia.org/wiki/Template:Won and https://en.wikipedia.org/wiki/Template:Nom hardcode (!) the text color to black. I really don't think there's much that can be fixed on the software side if the content on English Wikipedia is that... "restrictive" when it comes to one text color to show for everyone.

Change 868722 had a related patch set uploaded (by KarlBeecken; author: KarlBeecken):

[mediawiki/services/mobileapps@master] more in-depth fix to dark mode table backgrounds

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

I looked around a bit and have a question: Why does this code exist? @Dbrant do you know why?

/**
 * Do not allow TD elements to receive notheme unless parent node is already marked as notheme
 *
 * @param {Element} element
 * @return {boolean}
 */
tdNotEligibleForThemeExclusion(element) {
	const parentClasses = element.parentNode.getAttribute && element.parentNode.getAttribute('class');
	return (
		element.localName === 'td' &&
					!this.stringHasNoThemeClass(parentClasses)
	);
}

If I disable this check (and remove some obsolete css), tables are working okay-ish in numerous known-to-me circumstances:

It is not a perfect solutions, as there are sometimes unreasonably large amounts of white/light backgrounds in the dark theme (which might blind some users), but as far as I'm concerned, everything is readable!

I pushed my changes here, maybe it is helpful: https://gerrit.wikimedia.org/r/c/mediawiki/services/mobileapps/+/868722

@KarlBeecken I'm not exactly sure of the original reasoning for that exclusion. I do wish that these functions were documented a bit better (e.g. with links to a Phab task) like others are.

there are sometimes unreasonably large amounts of white/light backgrounds in the dark theme (which might blind some users)

That would be my best guess for the reason for the exclusion you mentioned -- numerous users complained that the table cells are too bright, so we remove the background a little more aggressively, even though it can sometimes break the appearance intended by the editors.

I believe the real, proper solution would be to communicate with the editors of those templates/tables/articles, and encourage them to remove the hard-coded backgrounds where they aren't necessary. And if the colors really are necessary, the editors can put a notheme class into those elements, so that our theme transforms won't touch them.

@Dbrant That sounds reasonable.

Until we get all editors to adopt that new behaviour though, we need to decide how we want to handle custom-colored table cells. I see two options: either we leave it like it is (including the changes for T264474, so forcing dark background everywhere +maybe something to fix the auto increment prefix bug) or we take a less strict approach and leave hardcoded backgrounds as they are (though you mentioned that this idea was decided against in the past). I'm really not sure what is the best solution here – from a user perspective I detest those unnecessary large bright blobs, while still wanting to see colored highlights in certain tables (it makes some things easier to understand, like in ex. two above).

Ultimately, I would imagine a color system where for each "normal" color there exists a darker, but still beautiful variant (I tried to just darken it via css, it looks bad) to use in this circumstances, at least for often used standard colors like red, green...

But for now there is the decision to be made between features (as in more color) and usability (as in uniformly dark appearance).

In T325296#8474389, @Dbrant wrote:

numerous users complained that the table cells are too bright, so we remove the background a little more aggressively, even though it can sometimes break the appearance intended by the editors.

That change, from my understanding, is what not only sometimes broke the intended appearance intended by authors, but also introduced the major problem with white text on white background. So either way, this should be improved (I don't know how) or scrapped entirely.

I looked around a bit and have a question: Why does this code exist? @Dbrant do you know why?

The reason for this has been described in this ticket: https://phabricator.wikimedia.org/T282295 and the related patch. The problem was that some infobox table elements inherited the default white font color from the infobox when using black/dark mode.