User talk:Jdlrobson

Note: Thanks to Echo I now do monitor this talk page. If for whatever reason you lack a reply your best bet is to e-mail me at jrobson@wikimedia.org

Note that I am a developer at the Wikimedia foundation currently working in the web team and working to make it easier for Wikipedia readers to become Wikipedia editors. As a result my team creates simple to use tools to make editing easier.

If there are problems with contributions I have made it is likely there is code responsible and your best bet is to discuss this on a mailing list/contact me directly so we can improve that code.

Let's make Wikipedia better together! ~ Jon

Archives: 2012-2020, 2020-2023

Fun with colors

Some comments:

1. Module:Documentation/styles.css#L-40 feels really heavy weight for color fussing. I don't think there's anything to do about that, just noting.
2. A request that probably needs your dev hat on: Please give the preferences for night mode more semantic names in the classes they're emitting. I think option 1 is "dark always" and option 2 is "do what my OS/browser setting requests" but I'm not totally sure, and it would save some grief for future readers. I assume there's an implicit option 3 already existing in case we wanted to flip the expectations here i.e. define the light mode color and then just let the dark mode inherit naturally...?
3. Your use of side-box is incorrect in multiple places, which is what caused me to check in on your changes. The class is intended solely for Module:Side box and templates/modules using that one. I suspect your other recommendations are also similarly... wrong? on the recommended friendliness page. (Other wikis might need it, but there are going to be better ways to deal here.)
4. I was definitely not a fan of the introduction of navigation-box in one of your edits as we should keep potentially conflated names to a minimum. Module:Navbox already has a well defined name and assigning a random class somewhere feels pretty wrong (even if that thing looks like it is providing navigation -- which would do better with the relevant aria role or the I-still-can't-use-<nav>-in-wikitext). Separately, that class being used there feels like it should just have been the "override random stuff" class.
5. Syntaxhighlighter styles, e.g. at Module:Documentation, could use some coloring for the line numbers in whatever stylesheet is appropriate upstream.
6. Similarly for catlinks in Minerva (see the bottom of Module:Documentation on a desktop width browser).
7. Is there an easier way to check how dark mode works without manually adding the relevant stuff into the URL?

Still working through your recent changes. I'm happy to work on other stuff if I had a full list of the best set of options to support dark mode in one consolidated space (e.g. "pick a class, add some colors" and whatever else - is that the dark mode page that I think you have somewhere (and or link?)). If you want, you can set up a section on MediaWiki talk:Common.css/to do above the Done section to add stuff you run into that you'd like to sort dark mode coloring for and I can chase those down. Izno (talk) 04:05, 11 March 2024 (UTC)

Hey Izno! Thanks for reaching out!

In terms of process I am using the reports on https://night-mode-checker.wmcloud.org/ and the WCAG Color Contrast checker Chrome extension. I use the former to find issues with dark mode and then the Chrome extension to confirm.

1. Regarding "color fussing" for now I figured disabling colors where they are non-essential was a good first step - as that also allows us to easily find the templates impacted by dark mode in future. I'm hoping better informed people could evaluate those and improve on the styles (in some cases it's a case of choosing new background colors and colors). Personally I wish we didn't have to repeat the styles for both modes, but I've not found a good way to do that yet - but color scheme inheritance seems promising.

2. Regarding semantic classes - yes you've understood correctly. Option 3 etc does not exist right now, but as this matures I did start to wonder whether this should be about theme rather than tied to dark mode (e.g. how would a sepia theme work here?). Or do you mean changing just the suffix or all the class? Since this supports anonymous users we have a few constraints on these but these classes could be changed. It might need a bit of bikeshedding first though (I know that some people have complained about the use of the word "night" in the class). Would you be able to open a Phabricator ticket for that? It's likely to get more attention if it's not created by me.

3. Sorry about that. I've been trying to evolve mw:Recommendations_for_night_mode_compatibility_on_Wikimedia_wikis based on what I've been seeing in the wild. Many projects do use side-box in that way, and I'm trying to surface and encourage the most common ones as it helps make our articles in multiple languages as machine-readable/themeable as possible. Are there any other classes on that page that could be used instead? Please feel free to reply on the talk page there and we can evolve those guidelines to avoid this happening again.

4. I've been trying to encourage navigation-box as 1. lots of projects already use it and [2] navbox gets stripped from projects so understandably projects need an alternative. Is there a ticket for the NAV element - that does seem like it might help as an alternative.

5. I believe that's covered in phab:T356956. I have been struggling to get this prioritized. However, as of today there was a product decision to temporarily disable dark mode on various namespaces for the initial launch so I guess that bought us some time.

6. phab:T357166

7. Right now... the best way is to temporarily add some code to Special:MyPage/minerva.js:

const c = document.documentElement.classList; c.remove( 'skin-night-mode-page-disabled' ); c.add( 'skin-night-mode-clientpref-1' );

.

Please feel free to ask any more questions or create any bugs in https://phabricator.wikimedia.org/tag/fy2023-24-we_2.1_typography_and_palette_customizations/ - I definitely appreciate your reactions early on in this!

Thanks again for sharing! Jdlrobson (talk) 15:54, 11 March 2024 (UTC)

1. Yeah, I think probably background-color: inherit is pretty reasonable until someone wants to make new colors (that's not me, I'm just as happy to set everything to inherit for now). (Not sure why you originally went for 'none' there.) My annoyance is mostly the quite lengthy additional count of rules/query to account for both "dark" and "OS setting".

2. how would a sepia theme work here? Yeah, IDK. Depends on how dark it is? W3C standardized only support for light and dark in prefers-color-scheme, rather than any of a variety of others, so someone has to make a judgement where on the gray scale a specific other 'theme' sits and then decide whether that's dark or light and then either add one rule or two, depending.

   I was looking to change clientpref-2, but if you're thinking about other potential theming options such as sepia, I think it's probably worth looking at the whole name, yes. phab:T359983

3. Are there any other classes on that page that could be used instead? Maybe elsewhere, but not here. The point I'm trying to make is that each of those classes you've identified can be traced to one or two "source" templates/modules to their exclusion elsewhere -- in other words, they're meant to be used by the module/template they're named after, not arbitrarily. Some wikis it may be easier to shoehorn them in, but on others like here, I took the time to clean the arbitrary uses so as to guarantee as best I can that TemplateStyles are delivered exactly when they're supposed to be and style exactly what they're supposed to. As your change particularly caused (and it was no big), expectations break when TemplateStyles aren't delivered with a specific class's use... or the another way, when they're used and TemplateStyles is delivered by something else causing mismatching styles. The use of these classes should be relegated almost exclusively to appearing in the specific templates/modules the classes are named after -- and maybe this is another way in which you can advise other users how to deal with the problem on the recommendations page i.e. saying "update your templates/modules and clean out your arbitrary uses" (the latter of which also helps other wikis on their TemplateStyles journey). (May not be popular, but may be more popular than "use these classes that most wikis probably already associate very specifically with certain classes".) (NB there is one class that does work 'arbitrarily' and that's in Template:Citation/styles.css, but its uses are still restricted to templates that are relevant to citations directly rather than as in item 4, and I did my best to remove other uses. That's one that I'll add to my list of color issues. Is there a color upstream decided for the clicky highlighty of citations in dark?)
4. I mean, navigation-box should probably also get stripped if other wikis are using it in the same way that we are using the similarly-named class, not be used as a workaround in your case, for the same reasons as in the phab:T124168. :) I actually don't think having nav elements would help here in the way that is relevant to this issue, it was mostly just me griping, but you can look at the relevant task in horror if you wish, just so that you know that you're not the only one I yell at. ;) phab:T25932.
5. Scope yes, it fits under that task. I think the reason I noticed is that whatever system does night mode for templates (I do think it's Syntaxhighlight??) was showing up in dark mode as dark (rather than as in the image there which is light). (But now I can't confirm this because it looks like you might have merged the patch between today and Saturday? that makes the option work only in certain namespaces. womp womp) I was mostly just calling out the line numbers (colors are on .mw-highlight .linenos), which it doesn't look like the current patch has covered. In this case the line numbers were readable because the bg was set to none, so it's more a case of "suboptimal colors" and less "I'll be blinded by the light".
6. Noted.
7. Ok, I'll do that.

Izno (talk) 22:04, 12 March 2024 (UTC)

While I have you @Izno and since you have thought about infobox organization more than most people, do you have any thoughts on how we could address inline styles in infoboxes e.g. the box "Representing Brazil" in this example?

We could add the following rule but that would interfere with legitimate use cases such as this example.

Is there a way to add this rule only to infoboxes we have vetted e.g. Template:Infobox football biography ?

.infobox [style*="background"]not( .notheme ) {
   color: inherit !important;
   background-color: inherit !important;
}

Jdlrobson (talk) 00:17, 13 March 2024 (UTC)

Infoboxes using {{infobox}} can take custom TemplateStyles sheets using primarily the parameter |templatestyles= and where necessary |child templatestyles= and |grandchild templatestyles=, see e.g. {{infobox television episode}}.

This would however not really fix the issue presented here which is that the specific "Representing Brazil" is another template entirely embedded using |medaltemplates=, {{Medal}}, {{MedalCompetition}}, and {{MedalGold}} (total aside, it's kind of awkward that they're table templates). We should add TemplateStyles for these other templates. I think probably the best way/name would be Template:Medal/styles.css and then add the styles for all the templates in the series that would otherwise emit colors, which I guess can be found at Category:Medal infobox templates?

To answer the question directly for elsewhere, {{infobox}} templates can take classes in specific rows (see documentation), but I think it would be preferable to move them over to stylesheets, which will generally be safer for any future changes that I get to with the template and which might inspire future editors to pick colors rather than rely on some general override. Izno (talk) 16:25, 13 March 2024 (UTC)

Testing night mode

Hello, I found out from your recent edit to Template:Routemap/styles.css that the night mode project existed, so I tried out the Minerva JS you posted in the above section to see what issues might crop up. I've tested it with {{Overground RDT}} and Yellow Line (BART)/{{Yellow Line (BART)}}.

• The background of the diagram is #F9F9F9 when used in an infobox because of inline CSS added by Module:Routemap, but it's black when not displayed inline. This background colour should be consistent in both settings.
• In the infobox context, the text colour is the night mode default of white even though the background colour is #F9F9F9, so all text without any colour specified is rendered invisible.
• If the background colour is black in night mode, a lot of diagram icons such as  (hSTRc1) or  (MFADEg) (both of which are used in the Yellow Line diagram) will not appear to function correctly in night mode, because they include the background colour so that they can be overlaid over other icons. Accounting for this would necessitate the updating of a lot of diagrams and icons (possibly hundreds or thousands of each).
• Various other elements of diagrams, and inline images such as transit operator/service symbols, have been implemented with the implicit expectation that the background will always be light grey. For example, some parts of  (INT) and  (ACC) would have extremely poor colour contrast (as can be seen in the Overground diagram), and it's impossible to see {{rint|london|river}} in night mode since the symbol is completely black. These inline images are used outside diagrams a lot, particularly in infoboxes. If night mode is taken into account, it becomes much harder to use certain inline images unless somehow they can be switched out or colour-inverted using context-specific CSS.

Jc86035 (talk) 03:26, 14 March 2024 (UTC)

I tweaked this a little more. We can lower the contrast on images while still keeping the darker theme. What do you think of the latest iteration? Jdlrobson (talk) 15:55, 16 March 2024 (UTC)

The change appears to have broken certain things, in particular that overlaid images don't appear to display in the correct stack order (e.g. wrong line colour in the table row below North Concord/​Martinez in {{Yellow Line (BART)}}, interchange symbols at Gospel Oak and Clapham Junction in {{Overground RDT}}). I don't know what caused that.

The colour contrast is now better, but I don't know if this is the right approach. The contrast for darker objects is still not great.

A few diagrams use "filler" table rows which have the line colours specified as inline CSS, so any contrast adjustment should also be applicable to the RMfm class. Jc86035 (talk) 05:03, 19 March 2024 (UTC)