Theme issues appears because of the wrong contrast ratio value for elements. From wiki:

I suggest to implement mobile preview button for the Edit section in desktop wiki (see the screenshot)

I decided to create a draft version of the possible solution which I've placed into repo - https://github.com/VadimKovalenkoSNF/wiki-colour-issues-filter
There are two branches: main and client-filtering
In the main branch you are able to check both approaches with filtering - client side and server side.
Server side is commented because I haven't managed to init filtering using domino package (which is using as virtual DOM library for mobileapps).
Probably, they haven't implemented functionality of the window.getComputedStyle (check here - https://github.com/fgnass/domino/blob/12a5f67136a0ac10e3fa1649b8787ba3b309e9a7/lib/Window.js#L55)
As for client side (it is default in my code), it works, but the time of the parsing of the page may vary. Also, at the moment it checks only equal colors and highlight nodes with the wrong styling with red border.

Hi @Jdlrobson ! Regarding template docs it does not display in the mobile view of Wikipedia, it is desktop only.
I've checked /summary endpoint for Acropolis article, it doesn't have coordinates property because this article does not have a dedicated template (which is expected). I've dove deeper and checked coordinates restrictions on mobile html level. These restrictions persist here in MobileHTML and styles. It seems, template works as expected, please re-check.

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?

For example when you say “I think, it is better to add specific class (or even style logic) inside Template to handle different text colors in heading” you mentioned that for the episode_table template but couldn’t that logic apply across the board to all times text appears with certain header backgrounds? Perhaps I am oversimplifying

@Ijm8710

attaching image for Mars Volta as requested

Yes, now I see it. Correct link is https://en.wikipedia.org/api/rest_v1/page/mobile-html/The_Mars_Volta_discography?theme=dark. Issue the same as in Maria Andrejczyk article.

Don’t want to jump the gun, but I’d be curious which of these mean they can/are unlikely to be improved. The more universal they are, the more I’d hope they can be like those affecting most athlete pages across the board

I think we need to prepare a list of these templates and then discuss about style issues with their authors

The commentary on the lindor example has me curious. Why would that be any different from say “Tom Brady” who is themed in dark mode?

Because they utilize different templates. Francisco Lindor uses Infobox baseball biography and Tom Brady Infobox NFL biography

Hi! I went through this checklist. Here is my summary:

I've fixed issue with the white background. However, there is still a bug with a horizontal bar on the top caused by redundant <p> element. It seems, it is on the Template level.

Hi @Envlh ! I've checked this issue on the mobile-html side and indeed if we disable the forbidden infobox class name from div element here we'll be able to retrieve French cyclist infobox. This happens because this infobox wraps into div, not into the table like it does in other wikis. I would rather not delete this regexp rule on the level of the mobile app ( at least for now ). I took a look at the French infobox module source code and found that it could be probably fixed in this string:
local infobox = mw.html.create( 'div' )
I think div should be replaced with the table there ( plus implemented logic for th, tr and other nested table elements ).
cc: @MSantos

Hi @JoeWalsh ! I think this bug has been fixed already.

Hi @cooltey ! Could you, please, provide some other article or doc/example where the content is wrapped by id=spoiler, or at least element <p id="spoiler"></p> exists? I've just checked the article from the description, no spoiler elements exist there in the DOM. Moreover, regarding this doc - https://en.wikipedia.org/wiki/Wikipedia:Spoiler, spoiler warnings are no longer used.

Hi @Mholloway ! Could you provide some input regarding this patch?

@Tsevener Is there any update regarding this task? Does my assistance is needed in the current stage?

Hi @Tsevener ! I reproduced this issue and also checked response output for different language variants:

1. kk-latn and kk-arab, kk-cn, kk-cyrl, kk-kz, kk-tr;
2. ike-latn and ike-cans;

(More language codes here - https://www.wikidata.org/wiki/Help:Wikimedia_language_codes/lists/all)

Hi @Ijm8710 ! We aware of issues you have mentioned. We're working on them in this patch which is currently in progress because at the moment we are looking for a solution that can cover all dark/theme issues which you can take a look at this umbrella task - https://phabricator.wikimedia.org/T252904.

@Tsevener I expect to see these changes working in the beta cluster once this patch with reverted changes and other fixes is merged. You will no need to setup RESTBase locally then. But for local testing, I had to use it.

Hi @Dmantena ! Thank you for pointing out this bug. The reason why this happened is that item.srcset[0].src property in routes/page/media.js can contain encoded URI characters for some images. I'll push relevant bug fix along with other fixes in the upcoming patch.

Hi @cooltey
I've added title redirection for /related pages in the patch above along with other changes that have been implemented in the reverted patch
To check 'read more' section locally I had a need to deploy a RESTBase

Hi @Ijm8710 @MSantos !
I've uploaded a patch that solves these recent issues.
I want to emphasize about /Mary_Matalin however. Article was created incorrectly itself (wrong template usage). I fixed this issue in the latest revision.
Issue with black text in /Francisco_Lindor article already fixed in the patch related to T284327
Issue with salmon color rows in /Don_Mattingly fixed in the path related to T282295
We continue working on similar issues. If you find anything else, please, let me know.

I've uploaded a preliminary patch with updated minerva styles for mobileapps, pls check.
cc: @MSantos, @Jdlrobson

I've checked minerva theme handling in mobileapps and it seems that all it does is just getting .less files from private/styles/minerva and transpile/concat them into base.css during build process.
As per commit [1] minerva styles were added manually. However, here [2] was added functionality to handle request directly to ResourceLoader module. Regarding commit message from [2] we are unable to access load.php explicitly via preq module to get the relevant minerva theme from the ResourceLoader.
I was expecting that within the scope of this task I need to implement some sort of async function to upload particular theme styles (as a single bundle file), but last research confused me about whether it is appropriate.
@MSantos , @Mholloway could you assist?

Hi @Tsevener , thank you for the testing! We've merged T277059 and T269312 today and now you are able to check this on the staging environment:

Update: I combined T277059 with patch related to this task.
cc: @MSantos

Hi @MSantos , @Tsevener !
I've uploaded the patch that solves both this task and T269312
I created resolve redirection method and chained it to these routes:

• /v1/page/summary/{title}
• /v1/page/media-list/{title}
• /v1/page/mobile-html/{title}

Worth mentioning that I perform overriding title parameter of the request - in the previous patchset it was a real redirect invocation with changing URL
Now there is an implicit redirection - for example, article sr.wikipedia.org/v1/page/mobile-html/Burek will redirect to article with title Бурек but URL title param in the search bar will remain Burek.

@MSantos
I've checked the differences between those two articles locally (title a bit different, but article itself the same):

1. localhost/en.wikipedia.org/v1/page/media-list/Barack_Obama
2. localhost/en.wikipedia.org/v1/page/media-list/Barack_obama

I've uploaded a patch with redirection algorithm. The main logic there is to check the converted: [{ 'from': '...', 'to': '...' }] property from mediawiki api for each request. If this property exists, mobile html will perform redirection to route, specified in converted[0].to property. Link titles remain untouched, the redirect route will recalculate only when the user clicks the link.
cc: @MSantos , @Tsevener