Jump to content

Template talk:Navbox

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

[edit]

The navbox styled in Module:Navbar/styles.css uses a color contrast for links that doesn't pass AA guidelines for small text.

Please consider adding the following rule or similar: 

.navbar a { color: #1C376D; }
.navbar  a:visited { color: #423168; }

? Jdlrobson (talk) 04:37, 2 February 2024 (UTC)[reply]

Wouldn't it be better to update the colors for all links in commons.js rather than just these as there are going to be others of a similar size defined elsewhere? -- WOSlinker (talk) 08:37, 2 February 2024 (UTC)[reply]
Deactivating request per WOSlinker. * Pppery * it has begun... 04:25, 4 February 2024 (UTC)[reply]
The issue is specifically with the Navbar. It is changing the background color but not the link color, so it is creating a color contrast issue. The issue doesn't exist on normal links outside the Navbox so must be made here. Jdlrobson (talk) 22:49, 7 February 2024 (UTC)[reply]
You can see the issue on Portal:Current_events in "Current events by month". The background color is set on .navbox-title but the links inside this remain the default #3366cc which creates a color contrast issue (you can run Lighthouse in Chrome dev tools to flag this under "Background and foreground colors do not have a sufficient contrast ratio.")
Another approach would be to drop this rule or change the color to something more compatible with link colors:
.navbox-title {
	background-color: #ccf; /* Level 1 color */
}
Let me know if this request is still not clear. Jdlrobson (talk) 22:55, 7 February 2024 (UTC)[reply]
The navbox title color is set in Module:Navbox/styles.css. If the title background color is to be changed then it would probably need the other colors in the navbox reviewing as well so that there is still some differences between the different sections of the navbox. There have been discussions in the past about the set of navbox colors (for example at Template talk:Navbox/Archive 19) and while going for paler colours helps the text to be more visible on the backgrounds, it makes it more difficult to distinguish between different areas of background. Could you make your original css rules more specific so that they only applied to navbars within navboxes? -- WOSlinker (talk) 10:59, 8 February 2024 (UTC)[reply]
I think either the background color or the links color should be changed. I assumed the links color would make more sense here and is already scoped to navbars.
If we want navbars inside navboxes the following seems appropriate, no?:
.navbox .navbar a { color: #1C376D; }
.navbox .navbar a:visited { color: #423168; } Jdlrobson (talk) 17:57, 16 February 2024 (UTC)[reply]
I've moved this discussion (@Jdlrobson@Pppery@WOSlinker) because I'm fairly certain it concerns only navbars in navboxes.
Regarding which, we have a consensus from 2015 about changing the background colors instead to support AAA which never got implemented. With the adjustments in link colors since due to style guideline adjustments and etc., I think it would be more prudent in the meanwhile to adjust the group/title background colors since those are what are being set to at least support AA (though I anticipate some yowling) with the default colors in Vector22. I would appreciate someone throwing some colors at the wall that are in the generally same palette as today. Izno (talk) 02:14, 23 February 2024 (UTC)[reply]
Not doneing the request for now since it is not ready to implement. Izno (talk) 02:15, 23 February 2024 (UTC)[reply]
(We can also remove Module:Navbox/styles.css#L-17 when we have the colors ready since there are no navboxes directly next to other navboxes these days.) Izno (talk) 02:31, 23 February 2024 (UTC)[reply]

Current blocks of colors that need adjustment: 

.navbox-title {
	background-color: #ccf; /* Level 1 color */
}

.navbox-abovebelow,
.navbox-group,
.navbox-subgroup .navbox-title {
	background-color: #ddf; /* Level 2 color */
}

.navbox-subgroup .navbox-group,
.navbox-subgroup .navbox-abovebelow {
	background-color: #e6e6ff; /* Level 3 color */
}

Izno (talk) 02:35, 23 February 2024 (UTC)[reply]

And the current link colors in Vector 22 are:

  • unvisited, hover, focus(visible/within), target: #36c.
  • visited: #795cb2
  • and for completeness, active (probably not a big issue since it's orange; nb I'd expect focus color to be similar to active): #faa700

Izno (talk) 02:46, 23 February 2024 (UTC)[reply]

AA comparison
Navbox Unvisited (#36c) Visited (#795cb2)
Level 1 (#ccf) 3.49 3.42
Level 2 (#ddf) 4.05 3.98
Level 3 (#e6e6ff) 4.38 4.3

Not inspiring! :) Izno (talk) 01:04, 24 February 2024 (UTC)[reply]

Well, WMF basically made it impossible to keep colors in navboxes without relying on the "if it's bold, it can have a lower contrast" exception that is in the WCAG AA for contrast, using the Vector 22 link colors. We have to go basically to white and various shades of light grey to meet AA 4.5 for normal text (which I wouldn't hate TBF, and I think I recall someone having a go at that before). All of the levels are in bold text though, so perhaps we just decide to ignore it. Izno (talk) 21:52, 25 February 2024 (UTC)[reply]
"WMF basically made it impossible to keep colors in navboxes". How so? What would you have done instead?
It seems like you have several options here:
  • Use a different link color e.g. black or white (consider underlining the link or adding an icon to make it more obvious it's clickable)
  • Move the link out of the box.
  • Put the link itself in a box with a white background
Jdlrobson (talk) 21:45, 28 February 2024 (UTC)[reply]
How so? You changed the link colors in Vector in phab:T213778. We probably weren't hitting the requirement specifically for the navbar links before anyway because we couldn't claim to be meeting the exception for bold text that WCAG allows (unlike the rest of the links in these locations), but changing the colors in the way that you did made it much harder to thread any needle whatsoever (my options really are light grey and no other colors and even now the darkest grey I've suggested below misses 4.5 by half a point [that was a number picked out of hat]). (Incidentally, there appear to be remaining issues as discussed on that task that WMF appears to have moved on from without any response.)
  1. Use a different link color e.g. black or white (consider underlining the link or adding an icon to make it more obvious it's clickable) Adding an icon is not feasible with space requirements. Changing the colors is feasible but fails to meet other expectations of links that also pertain to accessibility (namely, that people know it's a link, which is a far broader issue for users) and makes an inconsistent UI to boot. Adding an underline fails similarly on this second option, has minor readability issues with it, and moreover will get 'unaesthetic' arguments thrown at it (people hate underlines). These links aren't intended to stand out.
  2. Move the link out of the box. This is not an option for obvious reasons (stackability of navboxes).
  3. Put the link itself in a box with a white background This will get me yelled at harder than just going all the way to grey in navboxes (example of which below). Uniform color is going to be seen as more important.
The primary argument against doing anything here just to make the arbitrary validator happy is also probably that these links... aren't all that important, so we don't lose a lot by failing contrast requirements for them. The pages at which they point have other ways to be accessed, if not so easily (click edit, find the navbox of interest in the transcluded templates, fin, just like every other template). Which is halfway to an argument for total removal, but that's also probably not something I can get consensus for, because 1. they are handy shortcuts, and 2. the balance between navbar links and show/hide links is aesthetically pleasing. (Well, these are the arguments I can foresee, I personally think I could get used to the issues presented by both.)
I do think something should probably be done not least because I don't like relying on the bold exemption in the context of what are smaller text items anyway for the links that are in the rest of the navbox (navboxes are at 88% font size), but I also don't have to like changing it. :) We probably also aren't going to get to 4.5 regardless though I think we can improve the current state, and on that you're probably going to just need to deal with it and find other valid things to complain about. Izno (talk) 22:10, 28 February 2024 (UTC)[reply]

Here's something grey. Visited colors against it are 4.0, 4.46, and 4.7. Our "upper bound" is f7f7f7 which is the grey used for the alternating row color. #eee is the darkest we can start if we want to hit 4.5 against visited.

I doubt keeping any colors is remotely possible.

Izno (talk) 22:13, 25 February 2024 (UTC)[reply]

Some other choices would be ditching our triple colors by making groups and titles all the same color and subgroups one color off, as well as nixing the alternating row color (which I would guess no-one can tell is missing these days with how monitors are built). Ditching the alternating colors would make the module simpler, but is much less of a win. I suspect implementing a set of these options is best. Izno (talk) 22:16, 25 February 2024 (UTC)[reply]

Night mode may need explicit color definitions

[edit]

For what it's worth, this template appears to be causing any page using a navbox to be tagged by a new linting rule that tries to identify background colors without an explicit text color. {{Bolvadin District}}, for example, shows three instances (I hesitate to call them errors) on its Page Information page; I think the instances are in the V/T/E section of the template. I have been told that using a URL like https://en.wikipedia.org/wiki/Template:Bolvadin_District?vectornightmode=1 is supposed to show what the page looks like in night mode. For me, ironically, the navbox is the only part of the page that looks reasonable, although it displays in regular, not night, mode; almost everything else on the page is a bunch of blue on black or black on black, so I don't know if night mode has reached a development state in which adding explicit colors will show a useful improvement.

I don't know if there is any action needed here, but it might be worth a discussion either here or in a new subsection of the original linked discussion. – Jonesey95 (talk) 05:17, 23 March 2024 (UTC)[reply]

Somewhat (highly?) related to the above discussion. Izno (talk) 06:28, 23 March 2024 (UTC)[reply]
Until testing can be done, I'm not sure that there is a lot of point making any changes. -- WOSlinker (talk) 09:10, 23 March 2024 (UTC)[reply]
Agreed, unfortunately. Murphy's Law says that we'll spend a bunch of time coming up with a fix and when things get implemented it will side-step everything we've already done. It's not nice playing catchup but it's better than duplicating effort. Primefac (talk) 09:32, 23 March 2024 (UTC)[reply]
@Izno I think https://en.wikipedia.org/w/index.php?title=Module%3ANavbox&diff=1217155387&oldid=1157419082 will fix this provided we reorder the style e.g. append rather than prefix (args[cfg.arg.basestyle] or '') - what do you think? 🐸 Jdlrobson (talk) 06:39, 4 April 2024 (UTC)[reply]
For an example of what this lint rule is flagging: https://en.wikipedia.org/wiki/G%C3%B6lba%C5%9F%C4%B1,_Ad%C4%B1yaman?useskin=minerva&minervanightmode=1
(For clarification - Vector is 2 weeks away from working properly in night mode so only Minerva URLs are good for now) 🐸 Jdlrobson (talk) 06:42, 4 April 2024 (UTC)[reply]
@Jdlrobson, coincidentally, I noticed phab:T361785. Izno (talk) 08:17, 4 April 2024 (UTC)[reply]
The point of the styles in that section of the code is to override users setting the properties already listed there (bg, border, box shadow, padding). That's why the list comes after the two arguments.
Ignoring that, you appear to be trying to set these links as the color of normal text (light theme: blackish, dark theme: whiteish) with your suggestion. Which you need consensus for per the above discussion for the reasons I laid out there (namely, Changing the colors is feasible but fails to meet other expectations of links that also pertain to accessibility (namely, that people know it's a link, which is a far broader issue for users) and makes an inconsistent UI to boot.). Please do not reinstate anything remotely like that edit until you have it. I am not sure why you made the edit now that I think about the fact I had already said that, and the rest of what I had said above. Izno (talk) 08:03, 4 April 2024 (UTC)[reply]
Could we at least override rules into a stylesheet e.g.
.navbar abbr {
background:none transparent;border:none;box-shadow:none;padding:0;
}
(style attribute will override all of these so it will function the same but it won't trigger the lint warning)
This is creating a lot of noise in the Special:LintErrors which is making it difficult for us to QA the other test cases caused by the lint. 🐸 Jdlrobson (talk) 04:10, 5 April 2024 (UTC)[reply]
Jdlrobson I wanted to make a change in the context of TemplateStyling that got this particular block of CSS out of the module, which I've now done in the sandbox by resurrecting a change that I and Frietjes thought up (mostly Frietjes). It restricts the valid CSS for the VTE links to the color property, which is highly used in e.g. sports contexts, but I doubt any other properties are. The second template in Template:Navbox/testcases#Color extraction displays correctly in dark mode now, and the other test navboxes "as expected" for what happens when a color against a white base would otherwise look like (without the "extraneous" CSS that causes dark mode grief). I'll look to deploy this Soon. I hope I get no complaints. :') Izno (talk) 04:14, 17 May 2024 (UTC)[reply]
This change is live now and should be percolating. Izno (talk) 21:13, 17 May 2024 (UTC)[reply]

Discussion on making navboxes compatible with night mode

[edit]

 You are invited to join the discussion at Template talk:Southern California Intercollegiate Athletic Conference navbox § Night mode compatibility?. Sdkb talk 19:43, 14 May 2024 (UTC)[reply]

Edit request (conditionally load Module:Navbar)

[edit]

Assuming I didn't overlook some problem (though the testcases look fine), please copy the changes in Special:Diff/1235534036 to Module:Navbox. This conditionally loads Module:Navbar only when the navbar will actually be displayed (i.e. when |navbar= is not used, basically). I'm aware that I could make this change myself, but it's beyond what I'm comfortable doing on Module:Navbox, even with testcases all looking good, so I'd appreciate someone double-checking the actual change first. It's surprisingly hard keeping "navbox" and "navbar" straight when you're talking about them both... 「ディノ奴千？！」☎ Dinoguy1000 19:53, 19 July 2024 (UTC)[reply]

Looks fine. Izno (talk) 19:57, 19 July 2024 (UTC)[reply]
Since we're updating the module, I'll also move the display: none that has been hanging out in MediaWiki:Print.css to TemplateStyles, which is this diff. Izno (talk) 20:34, 19 July 2024 (UTC)[reply]
 Done Izno (talk) 19:25, 22 July 2024 (UTC)[reply]
[edit]

proposed fix

The following fix should address the issue described here. I do have edit rights but wanted a second opinion before applying these change.

The issue occurs because a mixture of things:

  • We have a well-meaning rule in MediaWiki:Vector-2022.css that makes all links black when a background is detected via inline styles (this corrects the large majority of issues in dark mode so we don't want to remove it)
  • mw:Extension:WikimediaMessages strips styling from navboxes in a way that clashes with the table rule.

My proposed fix is to do this on the template level.

An alternative I considered was to add another !important rule in MediaWiki:Vector-2022.css but I think it is preferable that the fix lives in the navbox styles. Hopefully on the long term we can move the color stripping in WikimediaMessages into the Navbox template itself and this will all be easier to follow. 🐸 Jdlrobson (talk) 18:57, 22 July 2024 (UTC)[reply]

The 3rd alternative is to resolve the task in Phab that allows us to turn off the dark mode for specific components, and then we can turn that one off for navbox. That's something that could take an hour or two tops. Izno (talk) 19:10, 22 July 2024 (UTC)[reply]
Right this is what I am talking about when I say "on the long term".
we are looking at a least a month for a fix for that to go into production given web team's other commitments. There are far more important issues that need addressing unfortunately.
It would be nice to have a short term fix in the mean time. We can reference the phabricator ticket in an inline comment and I can make sure it gets undone whenever that ticket gets worked on. 🐸 Jdlrobson (talk) 21:30, 22 July 2024 (UTC)[reply]
Am I reading the code correctly, inferring that the change applies only to links in the navbox title? If so, what is the fix for visited links in the navbox body, which are also showing as gray-on-black for me? I could be reading the code wrong. – Jonesey95 (talk) 00:43, 23 July 2024 (UTC)[reply]
Can you give an example page @Jonesey95? But yeh this is only for navbox title as that was the only issue I was aware of.
If there are other elements these could use the same rules, substituting th.navbox-title for the relevant selector. 🐸 Jdlrobson (talk) 17:59, 23 July 2024 (UTC)[reply]
It looks like my memory is wrong. I went back to {{Soulfly}}, and it is only the top navbar title and the subhead title where visited links are turning gray instead of purple. Carry on. – Jonesey95 (talk) 18:03, 23 July 2024 (UTC)[reply]

Grey text on a white background

[edit]

When editing a navbox, anything that is NOT a link is grey text on a white background. It was not this way before. Does anyone know how to fix this? --Jax 0677 (talk) 22:20, 23 July 2024 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Navbox&oldid=1236289941"