Hey @MSantos, again not to oversimplify but wanted to circle back to one approach one more time please just to make sure it’s indeed not possible as it seems to me like a feasible approach .

Totally understand all the templates have different elements/setups, but is there really no way to parse the color gradient of the background regardless of what template it’s in and simply assign text color automatically as a secondary step (or if it’s detected that there’s a color-conflict override what’s there)

2 Examples:

https://en.wikipedia.org/api/rest_v1/page/mobile-html/The_West_Wing_(season_7)?theme=dark

^the headers for the episode guide tables have black background so it will render text white instead of black on black

https://en.wikipedia.org/api/rest_v1/page/mobile-html/The_Mars_Volta_discography?theme=dark

^the fop table has a very light sky blue hence the text color should render black and not white once it detects the conflict

Perhaps it might not be 100% at first but at least conceptually to me, if you split the entire gradient of colors, you basically can have white or dark text work for the great majority of backgrounds

This may deserve another separate ticket, but I see a bunch of articles where they have legend-dictated shading for the tables yet in dark mode it doesn’t carry over

Here’s one example; https://en.m.wikipedia.org/wiki/List_of_Oklahoma_Sooners_head_football_coaches

Note that this is just one example, but it’s a much more pervasive issue across many template rules.

Would this be unbrellad with the other dark issues or can we file a seperate ticket for it if another one doesn’t exist already for it please? @MSantos @vadim-kovalenko

Android email feedback from July 14:

For approximately 2 weeks I have been experiencing a display issue with the Wikipedia App on my Android OS device (Samsung Galaxy S7 - OS Version 8.0.0) and have attached Screenshots for Reference

I currently use the Black App Theme when viewing information. Black and Dark appear to be the only App Themes that present the issue

This occurs when I Expand a List on an Article with every other Line Term obscured by a White Background,and the text in the affected area only becomes visible after I highlight it. So far this only happens with a "Track Listing" List on articles pertaining to musicians,albums,soundtracks,etc.

{F35344064}

{F35344065}

Do we have any documentation for editors to reference on how best to avoid dark mode issues in the apps? I'm thinking of something similar to https://www.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis. If not, it may be beneficial to write something up in the meantime while we work on these technical solutions.

Background: I came across this code comment in PCS, and I was wondering if we've advertised any theming hooks like this.

@Tsevener to add on to you comment, is there any reason why the background can’t simply be used to determine whether the text goes white or black. There are so many articles I can’t read (especially tables) where it’s white on white or black on black. I do recall there were like 5 seperste suggestions on possible fix methods and all went cold. And as a result for 2-3 years it’s basically rendered using the Wikipedia app religiously in dark mode impossible. While documentation adds a context, it does not alleviate the underlying issue which I feel will never be fixed. There are so so many articles affected

Is there please any way to follow up on any of this. I first reported this nearly 3 years ago and it’s actually gotten worse especially for sportsmen templates (ie boxing records and grand slam timelines for tennis players). All along it seemed like the intent was hope the templates could be nudged to be better managed by the editors. But as I expected all along that wasn’t going to help with the issue in the slightest. Feels it would Be better to directly address the most popular templates individually and perhaps have some rules for color backgrounds (ie white background uses black text and vice versa) but certainly this feels it can be in a much better place after all this time, please

@LGoto @JMinor @MSantos @Tsevener is it please possible to hear any update based on my last reply. I first filed this nearly 3 years ago and it’s only gotten worse based on many of the examples I’ve provided

Hey @Ijm8710, I've been taking a look into the dark mode issues we see on apps and digging into the challenges over the last few weeks. The following is a summary of what I've found:

TemplateStyles definitely remains the best route forward, especially when we have to deal with 300+ wikis. I also agree we should put together some good guidance for how to best support dark modes. This will benefit both the apps and any future web dark themes. Whatever solution we take needs to support both the apps and future possible approaches on desktop and how we should identify dark mode styles on the content style.

Approach to styles

There are two ways we can move forward:

• client-based dark modes via the prefers-color-scheme css media query. It's leveraged and supported across all platforms including iOS and Android but it is relatively new with widespread adoption only in the last 2-3 years.
• body.xx class identifiers. There are pcs specific theme classes but if we went with this approach probably would want to add a generic dark mode, black, sepia, and light theme CSS classes that aren’t PCS-specific.

What are the complications?

• Relying on cookies to request theme settings from servers brings challenges with caching. We'd need to make some fairly substantial changes to how our caching works requiring either to store two (or more) separate versions of every article or some sort of uncoupling of the content cache from the rest of the software. This is no small task and the benefits don't outweigh the cost here.
• Editors are more like to need to switch between modes and so the web might wish to consider supporting cookie-based theme switching since caching isn't an issue for logged-in users.
• Using javascript and local storage results in the unseemly content flash on the web browser. It's an extremely unpleasant experience for users and essentially unsuitable.
• prefers-color-scheme is so new though that it is not supported by a good chunk of our current Grade A browser stack. Uptake would be incremental on the browser side but we'd need to have the support on web at the same time. Handing this function over to browsers and OS is probably best for readers in the long term.
• Either should be fairly simple for community members to implement. Should we go with prefers-color-scheme it might be possible to support dark/light overrides set via some other method using the :not() pseudo-class. This would avoid the duplication of style TemplateStyles.
• To allow more time for web we could add skin-light as standard to all of web and have all templatestyles utilise something like body:not(body.skin-light) its a little hacky but it solves the problems we have today and doesn't shut the door for the future.
• Migrating away from inline style= is a must and that is going to have a long curve to it. We need to create a plan and recommended approach and possibly build some tools to aid in processing through all the instances.
• Also mentioned in T284327#7334686 is that we probably could look to start stripping out or replacing inline colours via PCS and cleaning up the whack-a-mole rules we've been building up till now.

What other dependencies are there?

As well as the above here are a few technical challenges to overcome:

• One of the blockers to greater adoption of template styles is T200704 which prevents inline styling within links. Parsoid's approach to rendering should in theory overcome this is used for read-views and template styles.
• TemplateStyles will need to receive a patch to work with parsoid directly T272941
• prefers-color-scheme isn't currently permitted by the CSS-sanitizer and but that is easily changeable (and previously requested in 2020 and discussed in 2021 T241946).

Hi @Seddon first off thanks for your reply but a lot of this approach wise confuses me based on what you are saying

1. I first reported this roughly 2.5-3 years ago. And I have a huge rubrik of the biggest cases where this affected template-wise. At one point, this was helpful as it addressed it for many of the biggest templates but then that just stopped. Vadim and jgiannelos opened like 5-6 seperate tickets for potential methods to address this issue. Most of them seemed to have little potential in my eyes as it left the honus in the hands of editors who either were completely oblivious or just didn’t care enough. To rethink this strategy once again shows that we’re back to square one, years into it
2. As I mentioned, a lot of the manual template adjustments did work! I’m not saying you have to fix each and every template. But to look into the 20-30 biggest templates would have a huge reduction of this issue. I’m talking TV-episode templates, music track listing templates, the info boxes for athletes, head to head record templates for boxers/UFC fighters, etc.
3. I still never got a concrete reason why there can’t be better automated logic for background vs text color. Often, I’ll see black text on dark blue background. Shouldn’t there be automated logic where if the background is dark enough, white text is used and vice versa (white background, black text)

Please don’t over complicate this. At least to get it to a slightly better place. It can’t be left in the hands of editors. That simply hasn’t worked over years. Even with better documentation.

I haven't yet had a chance yet to explore what options exist for algorithmic transformations and ones that will work across 300+ wikis, and won't cause performance issues.

As I noted we might be able to just strip out the colours en masse and apply some generic styling for PCS. But that might just create a whole other host of edge cases.

The community wants dark mode on desktop (having appeared in countless community wishlists) as well so many of these problems need solving for that anyway and so the approaches need consideration anyway. Having the whole of the WMF pulling in a single direction on this topic would make a lot of headway for everyone.

Please be patient with me, I've only been on the apps team a few months as an engineering manager and I am still getting up to speed on a bunch of things.

Thanks @Seddon, im wiling to be patient. Just would love to stay in-sync with you slightly if you don’t mind and hopefully have a plan. Felt like last time this was addressed a bunch of plans were proposed but ultimately it never became more than a plan. Like you said, you just took it on, so the past is not your fault. If you need any examples of some common dark mode inconsistencies more than happy though at this point I’m sure you’re more than well aware. Thanks

Hi @Seddon as promised i am willing to be patient but at what point can we circle back to this that’s fair.

Also another issue, if you open the article (this is one example of many as I’ve been seeing it happen more and more), “the challenge: war of the worlds” (first season) and proceed to the first cast table it doesn’t scroll horizontally correctly. That is until you collapse the table and then re-expand it. Then you’re able to scroll it fully horizontally to see both female and male challenge cast-members.

A lot of items I’ve reached out to the team on for almost half a decade to even almost a full decade. For example I have emails from 2017 with the team begging for a swipe-forward gesturing. I’ve deeply been pleading for ability to sort tables. One of my biggest asks has been on app-search. The ability to search someone by last name and it to return the most relevant people/result is vastly diff on web from App (basically having the ability to use the “search within pages” option on iOS. And I’ve had a bug sitting useless for a few years whereby within super long articles, the table of contents doesn’t scroll correctly with where you move within the article and was confirmed bug. Understood that things take time, but the base functionality/gesturing of the app is almost identical to where it was from the very first release. A lot of the focus has been on editors. And I get that. And this is a big reason why most of my focus has only been on the dark theme issues. But even those have not changed for 3-4 years. So if you need some time to get ramped up, absolutely, but just want to have some commitment on when it’s fair to say, hey let’s start actionably making them begin to get improved

Hey @Ijm8710

Dark mode: I don't have anything tangible to offer at the moment, but I'm meeting with the web team next week on this topic. No guarantees on timelines right now but it is a problem that is currently in my court and I'm working on.

T272761: I've spoken with the team product manager and I'm getting one of our engineers to take a look at it next week.

Sortable tables: @vadim-kovalenko is currently working on it T181452 right now.

Regarding the issue with horizontal scrolling of tables, I could get Vadim to take a look at that whilst he is looking at tables, do you know if that has a pre-existing ticket at all or should I create one?

Appreciate the reply @Seddon and this is giving me a bit more faith

Regarding horizontal tables, I know I personally haven’t filed it before so there’s a good chance it hasn’t been ticketed so I would appreciate that

Regarding the app search, just was curious your thought on my mention. If you use the “search within pages” option that comes up as an option on web when searching, it prioritized surnames which is, at least for me, the most common thing I’m searching. Would it be a huge endeavor to port that over to app? The biggest hiccup currently is that as is, a lot of times y oh have to type both first name and last name and more importantly since there’s not really a did you mean, you have to type them “almost” perfectly. Even if you’re one or two letters off it generally doesn’t find them and the search within pages option seems to do much better with searching partial names of people

Lastly, one long time request I had was porting of categories to app. The roadblock I generally heard was that categories was being mostly phased out but then I heard that may have been changed. I’m not really sure where all that stands but do you plan to see categories in app-form within the next few years or if not, do you expect to see a suitable replacement for it or personally dont t see the value to it

And last of all, do you ever foresee the value of a fwd button. A lot of times you want to proceed back in the reverse direction of backward. Yes you can go to history but admittedly the way history and search is presented in the app gets very convoluted, especially when you jump down a rabbit hole of article after article. In fact, that was probably one of the very first things I reached out to the team about, specifically Carolyn madeo like 7 or so years ago . She had drafted a way to unify that experience but unfortunately that ticket didn’t really gain any traction.

Thanks again for your transparency!

In T286643#8664767, @Ijm8710 wrote:

Appreciate the reply @Seddon and this is giving me a bit more faith

Regarding horizontal tables, I know I personally haven’t filed it before so there’s a good chance it hasn’t been ticketed so I would appreciate that

Will take a look when I'm back in work on Monday

Regarding the app search, just was curious your thought on my mention. If you use the “search within pages” option that comes up as an option on web when searching, it prioritized surnames which is, at least for me, the most common thing I’m searching. Would it be a huge endeavor to port that over to app? The biggest hiccup currently is that as is, a lot of times y oh have to type both first name and last name and more importantly since there’s not really a did you mean, you have to type them “almost” perfectly. Even if you’re one or two letters off it generally doesn’t find them and the search within pages option seems to do much better with searching partial names of people

Do you have an example I can test to see what you mean?

Lastly, one long time request I had was porting of categories to app. The roadblock I generally heard was that categories was being mostly phased out but then I heard that may have been changed. I’m not really sure where all that stands but do you plan to see categories in app-form within the next few years or if not, do you expect to see a suitable replacement for it or personally dont t see the value to it

One day categories will be phased out. When? Who knows but there is a need for it to be replaced by something akin to structured data on commons. There is value in the categories but I don't see it being a priority any time soon especially with a replacement looming in the distant future. I know that in our teams long long term (multi-year) interests there is a desire to improve "Explore related content" and maybe categories is something that could be evaluated and explored then. But that work isn't on a any schedule.

And last of all, do you ever foresee the value of a fwd button. A lot of times you want to proceed back in the reverse direction of backward. Yes you can go to history but admittedly the way history and search is presented in the app gets very convoluted, especially when you jump down a rabbit hole of article after article. In fact, that was probably one of the very first things I reached out to the team about, specifically Carolyn madeo like 7 or so years ago . She had drafted a way to unify that experience but unfortunately that ticket didn’t really gain any traction.

A good friend of mine said something similar to me very recently and I was going to create a ticket but haven't gotten around to it. If you remember the ticket feel free to link it but if you don't I'll create one. I'll chat with Carolyn and see if its something we have consciously decided to not do or whether just something that never got picked up by.

@Seddon Any update on the readability issues in dark mode? I saw a related ticket here was marked resolved. Do you consider it fixed? Not something I am seeing.

@Seddon please any change to followup on the readability issues. I see a lot of these tickets being marked resolved and the issue is none the better

Also forgot to answer from a few months back when I mentioned tthe did you mean/search.
An example I had from a while back is “steyer”. If you search in the wiki app none of the results relate to a person. But if you search on the site it will surface people leads and “tom steyer” will be the top result. I may be specific but I don’t think I’m a huge outlier in saying that a huge majority of my searches are people related so the way this works on mobile web and also wikipanion app is much better at prioritizing people pages. Plus the work is already mostly done, the prioritized people pages are built, they’re just not surfacing in the app. The other related item on this is spelling. Many times I’d you’re just two letters off but spelling it correct phonetically you’re SOL if you don’t know the exact spelling. Just a quick example although there are probably much better ones, take Ted kaczynski if you spell “kazinski” he’s nowhere to be found. Many times you may be wiki a person who’s name you may not know exactly