Template talk:Navbox
This template does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||
|
To help centralise discussions and keep related topics together, Module talk:Navbox redirects here. |
|
This page has archives. Sections older than 120 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present. |
Inaccessible links in navbar
[edit]This edit request to Module:Navbox/styles.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
- 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)
- Deactivating request per WOSlinker. * Pppery * it has begun... 04:25, 4 February 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Deactivating request per WOSlinker. * Pppery * it has begun... 04:25, 4 February 2024 (UTC)
- 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)
- Not doneing the request for now since it is not ready to implement. Izno (talk) 02:15, 23 February 2024 (UTC)
- (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)
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)
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)
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)
- 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)
- "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)
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.)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.Move the link out of the box.
This is not an option for obvious reasons (stackability of navboxes).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)
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)
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)
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)
- Somewhat (highly?) related to the above discussion. Izno (talk) 06:28, 23 March 2024 (UTC)
- 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)
- 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)
- @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)
- 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)
- @Jdlrobson, coincidentally, I noticed phab:T361785. Izno (talk) 08:17, 4 April 2024 (UTC)
- 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)
- @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)
- 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)
- 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)
- Could we at least override rules into a stylesheet e.g.
- (style attribute will override all of these so it will function the same but it won't trigger the lint warning)
.navbar abbr { background:none transparent;border:none;box-shadow:none;padding:0; }
- 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)
- 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)- This change is live now and should be percolating. Izno (talk) 21:13, 17 May 2024 (UTC)
- 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
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)
Edit request (conditionally load Module:Navbar)
[edit]This edit request to Module:Navbox has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
- Looks fine. Izno (talk) 19:57, 19 July 2024 (UTC)
- 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)
- Since we're updating the module, I'll also move the
Done Izno (talk) 19:25, 22 July 2024 (UTC)
Make navbox-title links show in dark mode
[edit]It is requested that an edit be made to the template-protected module at Module:Navbox. (edit · history · last · links · sandbox · edit sandbox · sandbox history · sandbox last edit · sandbox diff · transclusion count · protection log) This template must be followed by a complete and specific description of the request, so that an editor unfamiliar with the subject matter could complete the requested edit immediately.
Edit requests to template-protected pages should only be used for edits that are either uncontroversial or supported by consensus. If the proposed edit might be controversial, discuss it on the protected page's talk page before using this template. Consider making changes first to the module's sandbox before submitting an edit request. To request that a page be protected or unprotected, make a protection request. When the request has been completed or denied, please add the |
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- In what I assume is a related CSS problem, on {{Malawian roads}}, I see links to articles as blue or red if non-existent in light mode, but only blue in dark mode. For example, M26 road (Malawi) does not exist, but shows up as blue in dark mode. -- Beland (talk) 20:36, 2 August 2024 (UTC)
- FTR, previewing {{Malawian roads}} and changing it to point to {{Navbox/sandbox}} did not fix the red link color problem. -- Beland (talk) 20:41, 2 August 2024 (UTC)
- In what I assume is a related CSS problem, on {{Malawian roads}}, I see links to articles as blue or red if non-existent in light mode, but only blue in dark mode. For example, M26 road (Malawi) does not exist, but shows up as blue in dark mode. -- Beland (talk) 20:36, 2 August 2024 (UTC)
- 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)
- 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)
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)
Directly render child navboxes
[edit]Lots of articles exceed the post-expand include size limit due to navboxes taking up a huge amount of bytes. A lot of this is caused by navboxes that include child navboxes, because nesting a navbox template inside another navbox template causes the inner navbox to be counted twice towards the limit (and if you are using the template instead of the module directly, it actually counts 4x). To alleviate this, I have modified Module:Navbox/sandbox to allow child navboxes to be added without having to add an additional template call or module invocation. For example, instead of
{{Navbox
| name = {{subst:PAGENAME}}
| title = Title
| list1 = {{Navbox|child
| group1 = Group1.1
| list1 = List1
}}
| list2 = {{Navbox|child
| group1 = Group2.1
| list1 = List1
}}
}}
You could do
{{Navbox
| name = {{subst:PAGENAME}}
| title = Title
| list1 = child
| list1_group1 = Group1.1
| list1_list1 = List1
| list2 = child
| list2_group1 = Group2.1
| list2_list1 = List1
}}
The code only kicks in if the text of list# is the "child" keyword AND at least one parameter is specified that starts with "list#_". The result is a drastically smaller post-expand include size and, in my opinion, easier to read code. Of course, the old method, or a combination of the two, still works, as demonstrated at User:Ahecht/sandbox4. Any thoughts before I make a formal edit request? --Ahecht (TALK
PAGE) 20:08, 30 July 2024 (UTC)
- I've thought about doing it similar to this. I think I'd rather see something like
list1.1
andgroup1.1
which is a little shorter and probably doesn't result in code too different. - I'm not totally certain we need to opt in with
child
, I'm pretty sure this could be done without the additional keyword. Izno (talk) 20:16, 30 July 2024 (UTC)- @Izno So a child navbox in "list 4" would use
group1.4
,list1.4
,group1style.4
,image.4
, or would it begroup4.1
,list4.1
,group4style.1
,image4
, etc? If it's the former, it shouldn't be any more difficult to code, although it doesn't have the same natural indentation, and the hierarchical order isn't what most people would expect (although using4.group1
,4.list1
, etc. fixes that problem). If it's the latter, the code would certainly be more convoluted since some arguments would be delimited, others wouldn't, and the number to extract is in a different place in different variables. It would also make converting existing navboxes more difficult. - You're right that there's no need to opt in with the
child
keyword -- we could scan the arguments for delimited ones, extract the list number, and add it tolistnums
. The only reason I included it is that it makes it clearly visible to someone creating or editing a navbox template that that list number is taken, which should make it less likely they'll accidentally add text to bothlist#
and specify parameters for a child. --Ahecht (TALK
PAGE) 20:58, 30 July 2024 (UTC)- I am slightly more in favour of the
listx_listy
styling, as it will make visually distinguishing the groups (especially if they are aligned). Primefac (talk) 11:57, 31 July 2024 (UTC)- The thing I'm thinking about is that I've seen 3 or even 4 layers of navboxes, so
list1_group1_list1_group1_list1_group1
gets kind of unwieldy. :) Actually, does the implementation work for the more layers case? Izno (talk) 15:52, 31 July 2024 (UTC)- Hrm, good point. Primefac (talk) 16:04, 31 July 2024 (UTC)
- @Izno, Primefac The implementation is recursive so it does work with nested lists (I added an example to User:Ahecht/sandbox4), although it would "only" be
list1_list1_list1_group1
. The more I think about it, the more I dislike thelist1_list1
notation (since it's not really a list at that point), and I'm leaning towards eitherchild1_list1
/subgroup1_list1
as more descriptive or just1_list1
as more concise. --Ahecht (TALK
PAGE) 16:47, 31 July 2024 (UTC)
- The thing I'm thinking about is that I've seen 3 or even 4 layers of navboxes, so
- I am slightly more in favour of the
- @Izno So a child navbox in "list 4" would use
This edit request to Module:Navbox has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
- I've updated the sandbox at Special:Permalink/1239318936 to accept
child1_list1
,subgroup1_list1
, and1_list1
notation, as demonstrated at User:Ahecht/sandbox4. It currently requires either thechild
orsubgroup
keywords, but that requirement could be potentially removed in a future update. I also made the function that reads the arguments recursive to keep references in the correct order even when children/subgroups are used.--Ahecht (TALK
PAGE) 13:53, 8 August 2024 (UTC) Done I went ahead and implemented this. Hopefully I didn't just break 8% of Wikipedia! --Ahecht (TALK
PAGE) 18:03, 16 August 2024 (UTC)
Dark mode white border
[edit]In dark mode, for all navboxes, the border looks like this:
Is there a way to fix this so that the borders appear correctly? It's a minor thing but one that affects a lot of articles.