Vis kilden til Maldiskusjon:Navbox

{{WikiProject banner shell|
{{WikiProject Templates|template_for_template_maintenance=y}}
}}
{{User:MiszaBot/config |archiveheader={{talkarchivenav}} |maxarchivesize=70K |counter=25 |minthreadsleft=4 |minthreadstoarchive=1 |algo=old(120d) |archive=Template talk:Navbox/Archive %(counter)d}}
{{Centralized talk page|Module talk:Navbox}}
{{Archives |auto=long |search=yes |bot=MiszaBot II |age=120 |
* {{longitem|See [[Template talk:Navbox generic]] for previous discussions.}}
}}

== Mobile view wanted ==

Hello, when I asked earlier on the help desk ([[Special:PermaLink/1342484613#Navigation template doesn't show up in mobile view]]) about the fact that navboxes don't show up in the mobile view, I learned from another Wikimedian that this is by design. He also hinted at the possibility of using personal CSS to enable it. So far, I found mentions of why that design was made in a way to be hidden on mobile views in [[Template talk:Navbox/Archive 18#Not visible in App]] from 2015, [[Template talk:Navbox/Archive 22#Navbox not displaying on mobile sites]] from 2018 and [[phab:T124168]] from 2024, summarising, it's apparently due to the intent of reducing the amount of transmitted data and possibly also issues with screen sizes. Well, wouldn't it be time to reconsider it, now, in 2026?<br />
Usual mobile devices now have a screen resolution equal or better to full HD and even in Germany with its comparatively high priced mobile data transfers, a few KB of additional HTML per page would be imperceptible within the common data flat rates of several GB per month (the tracking ad pestilence is much more data hungry).
Anyway, I'd be glad if at least somebody could tell me what CSS is needed to enable these navboxes for me in mobile view! I didn't see any instruction for it either in the TP archive nor on Phabricator. Regards, [[User:Grand-Duc|Grand-Duc]] ([[User talk:Grand-Duc|talk]]) 06:25, 9 March 2026 (UTC) (PS. Please ping me in any answer as I'm actually more of a regular on Commons and DE-WP)

:There is no CSS which enables them in mobile view. As noted, the intent is to reduce the HTML load, and it happens the way this is done is to remove the HTML entirely from the page. (Which is realistically the only way such a thing could be implemented.)
:Remember that you, as a contributor from a developed country, do not have the same restrictions on hardware and data infrastructure as people in developing countries. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 16:24, 9 March 2026 (UTC)
::And it turns out it is not a "few" KBs, the price is substantial for a construct which has little to no benefit for the vast majority of mobile {{em|readers}}. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 16:25, 9 March 2026 (UTC)
:::My "developed country" is, in fact, in my opinion somewhat behind when speaking about mobile internet. Our local right-wing parties already stoke ressentiment against refugees also because they usually own quite high-end smartphones - but that's disregarding that we autochthones have access to landlines, desktop computers and public authority offices, whereas immigrants do rely upon their device for everything: communicating, banking, organising everyday life, etc. So, it's no wonder that they have a single device fit for holding an entire life.
:::Additionally, navboxes are things that would likely benefit ''readers'' much more than editors: in a book, we're turning pages, on Wikipedia, we're clicking navigation links. For casually browsing, reading and learning, navboxes are important, I'd say. Regards, [[User:Grand-Duc|Grand-Duc]] ([[User talk:Grand-Duc|talk]]) 10:58, 31 March 2026 (UTC)
:On my Android tablet in Chrome I can turn on desktop view (bottom of screen). That makes navboxes visible though I am glad they are at the end of articles where I can easily ignore them. [[User:Thincat|Thincat]] ([[User talk:Thincat|talk]]) 11:06, 31 March 2026 (UTC)
::The importance of navboxes as maps to their Wikipedia topics remains a key component feature of original Wikipedia. Mobile readers are missing these maps, and one present-time solution may be to add a line on each mobile view that the maps exist and can be viewed on desktop/laptops. [[User:Randy Kryn|Randy Kryn]] ([[User talk:Randy Kryn|talk]]) 11:11, 31 March 2026 (UTC)
:::@[[User:Thincat|Thincat]]: I certainly know about the mobile/desktop view switch. Actually, the desktop view of the watchlist (for me: on Commons) is a bit more comfortable, as it condenses category changes (e.g. for [[:c:Category:Media requiring renaming]], where you have an item for each change in "mobile", but a summary like "14:34 / Category:Media requiring renaming 52 / changes" in "desktop"). On the other hand, the font size and page layout for an article body makes for a more comfortable reading in the mobile view. I still maintain that the best of both worlds would be having the navboxes in the mobile view, too. Regards, [[User:Grand-Duc|Grand-Duc]] ([[User talk:Grand-Duc|talk]]) 12:39, 31 March 2026 (UTC)
:::{{replyto|Randy Kryn}} Here's an idea. We have the link as you suggested, but it takes the reader to the navbox template, exactly as if a normal user had clicked the "v" link of the "v-t-e" group. The navbox in the template either has (a) an additional class inside {{tag|noinclude}} which makes the navbox visible for mobile users, or it has (b) modified behaviour in [[Module:Navbox/styles.css]] for the existing <code>navbox</code> class so that it's visible on the template page, but still not in articles. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 15:43, 1 April 2026 (UTC)
::::I don't know the ideal solution, but I do know that the current arrangement (navboxes are simply ignored completely on mobile, invisible, non-navigable, not even affecting SEO) is plainly a mistake. For one thing, all the thought that has gone into making Wikipedia navigable through navboxes is lost to as much as 70% of the audience. That navigability goes with the indexing effect of a good navbox: here is what we have to say on this whole topic, and here is how this article fits in. In addition, many articles (hundreds of thousands, probably) were written assuming that readers could navigate using navbox links; many still certainly do not contain all the links provided in the navboxes that desktop readers can see and use. Could we please have something practical for mobile use? A single link to the template would be much better than nothing. Another view would be that mobiles today have way more memory, way faster processors, and way quicker access to the Internet than in 2016 (1000 times more in each case, maybe?), and that the old decision urgently needs revisiting. Heck, users could even be given a switch to turn navboxes on (default) or off (if their gadget really is s-l-o-o-o-w). Time to think again, please. [[User:Chiswick Chap|Chiswick Chap]] ([[User talk:Chiswick Chap|talk]]) 13:06, 26 May 2026 (UTC)

== Bug in anchors for navboxes with markup in title ==

There's a issue at {{slink|Template talk:Authority control/Archive 17#Odd HTML anchor}} due to [[Module:Navbox]] using the navbox title to produce anchors even when the title has complex markup. Perhaps [[Module:Navbox]] needs an optional anchor parameter to use instead of the navbox title? [[User:Daask|Daask]] ([[User talk:Daask|talk]]) 19:32, 23 April 2026 (UTC)

:It seems this was first [https://en.wikipedia.org/w/index.php?title=Module:Navbox&diff=prev&oldid=730005287 added] in 2016 &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 20:57, 23 April 2026 (UTC)
:This is now implemented in the sandbox and tested at [[Template:Navbox/testcases#Custom id attribute]] &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 11:17, 21 May 2026 (UTC)
::Kind of meh on having another parameter possible. (Not per se opposed today since this one is not going to cause much in the way of heartburn but not really supportive since it's another potential dimension for incorrect use.)
::I've previously mused about [[Template_talk:Navbox/Archive_23#c-Izno-2020-11-25T18:37:00.000Z-Jdlrobson-2020-11-25T02:04:00.000Z|just supporting authority control directly]] in some ways so as to limit the general need for Stuff Like This. Would make this module slightly impure. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 17:14, 21 May 2026 (UTC)
:::I guess it depends on whether any other templates are likely to need this "id" argument. If not, then we can indeed hard-code a variant for authority control &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 21:20, 21 May 2026 (UTC)
:::Unless you have further thoughts on alternative methods, I will implement this today &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 10:25, 1 June 2026 (UTC)
::::I mean, my personal POV is that people.... shouldn't make "complex" titles. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 16:22, 1 June 2026 (UTC)
:::::How else can we produce the pencil icon in the authority control template? &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 17:08, 1 June 2026 (UTC)
::::::This is the correct way to do so.
::::::I guess ultimately I'm stuck at "the purpose of the ID is to be targeted by aria-labelledby" and not anything else. Is this broken from that perspective? If not, then I don't think a change is ultimately needed here. One should not be linking to this ID because it is not always present (today at least, see mobile), and in general I would see as generally bad to point a user at a navbox containing authority control: they'll either find it or they won't (on desktop). [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 21:56, 1 June 2026 (UTC)
:::::::So your position is that <code><nowiki><div id="Authority&#95;control&#95;databases&#95;frameless&amp;#124;text-top&amp;#124;10px&amp;#124;alt=Edit&#95;this&#95;at&#95;Wikidata&amp;#124;link=https&amp;#58;//www.wikidata.org/wiki/Q7749994#identifiers&amp;#124;class=noprint&amp;#124;Edit&#95;this&#95;at&#95;Wikidata539" style="font-size:114%;margin:0 4em"><a href="/wiki/Help:Authority_control" title="Help:Authority control">Authority control databases</a></nowiki></code> is fine because it functions perfectly well and is only aesthetically displeasing? &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 07:44, 2 June 2026 (UTC)
::::::::I suppose so. And "aesthetically displeasing" is doing a lot of work there seeing as only the technically curious will even notice it. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 16:14, 2 June 2026 (UTC)
::[https://en.wikipedia.org/w/index.php?title=Module:Navbox/sandbox&diff=1355349804&oldid=1355348693 The change] is also incomplete. The ID is solely there to support aria-labelledby (people should not be linking to it). You've now added an ID parameter which changes the ID but you have not corrected the target of the aria-labelledby. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 21:55, 1 June 2026 (UTC)

== Hardcoded border color for 'with columns' mode affects dark mode ==

For [[Template:Navbox with columns|'with columns' mode]], <code>border-left</code> is hardcoded in the module to <code>#fdfdfd</code>, which is the same color as the background in light mode. This makes it appear as if there is no border at all. However, in dark mode, this creates very high-contrast divisions between columns. If it is not intended to be seen, I believe the border should not be set; if it should be seen, then it should be a different color to the background (set as a variable so it changes based on theme). [[User:Plighting Engineerd|<span style="color:yellow;text-shadow: 0 0 5px #000,1px 1px 0px #000;">Plighting Engineerd</span>]] ([[User talk:Plighting Engineerd|talk]]) 22:35, 5 June 2026 (UTC)

:seconding this. personally, I'd use the darker gray the other borders use - it seems sufficient to split the boxes without being distracting - but either way, consistency would be preferable to the current mix. [[User:Rexogamer|'''<span style="color: #0b797d;">Rexo</span>''']] ([[User talk:Rexogamer|talk]] &#124; [[Special:Contributions/Rexogamer|contributions]]) 00:21, 19 August 2026 (UTC)

== Line break bug in navbox lists ==

See [[Template:Routes of administration, dosage forms]]; what could be causing the problem with the line breaking when an image is included in a preceding section? See [https://en.wikipedia.org/w/index.php?title=Template:Routes_of_administration,_dosage_forms/sandbox&oldid=1361924287 this] sandbox.<p><!--Any editor may remove sandbox transclusion when it changes/is resolved.--></p>
{{Template:Routes of administration, dosage forms/sandbox}}
[[User:TheFeds|<span style="font-family:Constantia; background:linear-gradient(to left,#00fed5,#0077bb); -webkit-background-clip:text; -webkit-text-fill-color:transparent; color=#0077bb; font-size:medium; line-height:0.0;">'''''TheFeds'''''</span>]] 21:48, 30 June 2026 (UTC)

:So, this works in Parsoid but not in the old parser. So that to me says that the old parser is interpreting the list/sublist relationships wrong in some way.
:Either way, you should use the parameters that are there for this, {{para|image}} (or {{para|imageleft}} as might be your desire).
:Consider also whether these are decorative uses of an image. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 22:40, 30 June 2026 (UTC)
::Honestly, I don't even care about the images, and I do tend towards your thinking that they are unnecessarily decorative. (I'll try to fix them, and then maybe remove them in another edit, so that if anyone cares, it's easy to revert.) Given the parsing bug has been brought to the attention of this talk page, maybe someone can fix it eventually. [[User:TheFeds|<span style="font-family:Constantia; background:linear-gradient(to left,#00fed5,#0077bb); -webkit-background-clip:text; -webkit-text-fill-color:transparent; color=#0077bb; font-size:medium; line-height:0.0;">'''''TheFeds'''''</span>]] 05:55, 1 July 2026 (UTC)

== Title colors on subgroups? ==
Hi, I'm putting together a template that uses green for the title backgrounds rather than the default blue. I don't have a lot of experience with editing templates, and I can't seem to get subgroups to show up as green as well:

{{Navbox
|image=
|name=Navbox title
|state=expanded
|title={{colored link|white|Navbox title}}
|titlestyle= background:#006A4D; color:white;
|groupstyle = background:#006A4D; color:white
|belowstyle = background:#006A4D; color:white; font-weight:bold;
|listclass=hlist

| group1 = Main group A
|  list1 =
* example 1
* example 2
* example 3

 |group2  = Main group B
 |list2   = {{navbox|subgroup
 |group1  = Subgroup A
 |list1   = 
* example 4
* example 5
* example 6

 |group2  = Subgroup B
 |list2   = 
* example 7
* example 8
* example 9
}}

| group3 = Main group C
| list3 =
* example 10
* example 11
* example 12
}}

In the example above, I want the labels "Subgroup A" and "Subgroup B" to be white text on green background. I've tried inserting the titlestyle into the subgroup's navbox header, but it doesn't do anything:

{{Navbox
|image=
|name=Navbox title
|state=expanded
|title={{colored link|white|Navbox title}}
|titlestyle= background:#006A4D; color:white;
|groupstyle = background:#006A4D; color:white
|belowstyle = background:#006A4D; color:white; font-weight:bold;
|listclass=hlist

| group1 = Main group A
|  list1 =
* example 1
* example 2
* example 3

 |group2  = Main group B
 |list2   = {{navbox|subgroup|groupstyle= background:#006A4D; color:white;
 |group1  = Subgroup A
 |list1   = 
* example 4
* example 5
* example 6

 |group2  = Subgroup B
 |list2   = 
* example 7
* example 8
* example 9
}}

| group3 = Main group C
| list3 =
* example 10
* example 11
* example 12
}}

Hopefully someone can help me! -[[User:Literally Satan|Literally Satan]] ([[User talk:Literally Satan|talk]]) 19:22, 1 July 2026 (UTC)
:You need to set the {{para|groupstyle}}, not the {{para|titlestyle}}. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 08:04, 3 July 2026 (UTC)
::Redrose is correct. I have changed it in the second navbox above. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 12:54, 3 July 2026 (UTC)
:::Thank you!!! -[[User:Literally Satan|Literally Satan]] ([[User talk:Literally Satan|talk]]) 17:32, 6 July 2026 (UTC)

== New self-linking behavior ==
{{tracked|T424777}}
When I go to an article like [[United States]] and scroll down to the {{t|United States topics}} navbox at the bottom of it, it used to be that clicking the "United States" in that navbox would do nothing; it was just bolded as a self-link. However, recently I noticed that doing so causes the page to reload. Was this an intended change (in which case I'd be curious to see the discussion) or an unintentional side effect of something else? This doesn't appear to be happening beyond navboxes, as the link at [[Help:Link#Self link]] is still just bold. <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">[[User:Sdkb|<span style="color:#FFF;text-decoration:inherit;font:1em Lucida Sans">Sdkb</span>]]</span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 03:00, 6 July 2026 (UTC)

:Not happening for me; it's black and bold. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 07:28, 6 July 2026 (UTC)
::Still works for me in Incognito (although the link text doesn't turn blue on hover the same way it does when I'm logged in). Precise steps to replicate:
::# Go to [[United States#Maps]]
::# Move the cursor to the "United States" in the title bar of the top navbox.
::# Click on it, and see if the page reloads.
::<span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">[[User:Sdkb|<span style="color:#FFF;text-decoration:inherit;font:1em Lucida Sans">Sdkb</span>]]</span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 14:09, 6 July 2026 (UTC)
::On investigating further by testing in Microsoft Edge, it looks like once the link has been clicked before, it'll turn purple (the same color as any previously clicked normal link turns on hover, just without underline) on hover. That wasn't happening in Incognito just because the browser didn't remember a previously clicked link there. <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">[[User:Sdkb|<span style="color:#FFF;text-decoration:inherit;font:1em Lucida Sans">Sdkb</span>]]</span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 14:13, 6 July 2026 (UTC)
::That's a Parsoid quirk, try [https://en.wikipedia.org/wiki/United_States?useparsoid=1].  [[user:sapphaline|<span class="skin-nightmode-reset-color" style="color:#c20;text-decoration:underline">sapphaline</span>]] ([[user talk:sapphaline|<span class="skin-nightmode-reset-color" style="color:#236;text-decoration:underline">talk</span>]]) 13:08, 7 July 2026 (UTC)
:::There is a request to change this Parsoid behaviour at [[phab:T424777]]: "Parsoid-generated selflinks should not be clickable links". [[User:PrimeHunter|PrimeHunter]] ([[User talk:PrimeHunter|talk]]) 13:25, 7 July 2026 (UTC)
::::To clarify the different behaviour on some pages, it happens on pages saying "Page was rendered with Parsoid" at the bottom. Currently, articles are generally rendered with Parsoid but not help pages. [[User:PrimeHunter|PrimeHunter]] ([[User talk:PrimeHunter|talk]]) 13:32, 7 July 2026 (UTC)
:::::Thanks for the link, {{u|PrimeHunter}}! I think we should probably aim to keep the status quo behavior in the absence of any discussion establishing consensus to change it (no prejudice against holding such a discussion). <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">[[User:Sdkb|<span style="color:#FFF;text-decoration:inherit;font:1em Lucida Sans">Sdkb</span>]]</span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 13:54, 7 July 2026 (UTC)
::::::I have added a note about the issue to [[Help:Link#Self link]].[https://en.wikipedia.org/w/index.php?title=Help:Link&diff=prev&oldid=1363014027] [[User:PrimeHunter|PrimeHunter]] ([[User talk:PrimeHunter|talk]]) 15:12, 7 July 2026 (UTC)

== Template-protected edit request on 22 August 2026 ==

{{edit template-protected|Module:Navbox|answered=y}}
Add <code>class=notpageimage</code> for {{para|image<sub>''(left)''</sub>}} parameter. [[User:Dabao qian|Dabao qian]] ([[User talk:Dabao qian|talk]]) 11:56, 22 August 2026 (UTC)
:Please link to a page where the lack of this code is causing a problem. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 12:59, 22 August 2026 (UTC)
::For technical reasons, to avoid navbox images appear in results returned by [[mw:Extension:PageImages|Extension:PageImages]]. [[User:Dabao qian|Dabao qian]] ([[User talk:Dabao qian|talk]]) 15:05, 22 August 2026 (UTC)
::I preformed a test and no issues was founded, maybe this request can be cancelled. [[User:Dabao qian|Dabao qian]] ([[User talk:Dabao qian|talk]]) 15:14, 22 August 2026 (UTC)
:{{not done}} The relevant class needs to be added to the image itself, not the parameter holder. It remains a desire of mine to support this natively in a navbox, but it is non-trivial (and in {{tl|sidebar}}). [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 15:42, 22 August 2026 (UTC)

== WCAG AA 2.0 / MOS:CONTRAST ==

I am aware this has been discussed before, but I don't see any proposed firm solutions to it. The css styles applied to navboxes don't meet MOS:CONTRAST: 1) .navbox-title uses a background colour of {{Legend inline|#CCF}} (#CCF) and 2) .navbox-abovebelow, .navbox-group, .navbox-subgroup, and .navbox-title  use a background colour of {{Legend inline|#DDF}} (#DDF). These do not sufficiently contrast against the Wikipedia link colour of {{Legend inline|#36C}} (#36C) at only 3.48:1 and 4.05:1 respectively, whereas both WCAG and Wikipedia set a minimum contrast of 4.5:1 for normal point font. Correcting this is simple, requiring only a lighter shade of {{Legend inline|#EAEAFF}} (#EAEAFF) for 4.52:1 and then from there you can use any of {{Legend inline|#EEF}} (#EEF) to {{Legend inline|#FCFCFF}} (#FCFCFF). This assumes insistence on retaining the present hue. Two other options are to shift to a cyan colour such as {{Legend inline|#CFF}} (#CFF with the same saturation as #CCF) or a better contrasting colour such as yellow {{Legend inline|#FFC}} (#FFC) or green {{Legend inline|#CFC}} (#CFC). I imagine the principle of least astonishment may favour something on the line of {{Legend inline|#CCF2FF}} (#CCF2FF) and {{Legend inline|#DDF6FF}} (#DDF6FF) as a minimal hue change. I've put some examples down below:
{{Navbox
 | name       = Navbox
 | title      = Example
 | above      = Subexample
}}
{{Navbox
 | name       = Navbox
 | title      = Example
 | titlestyle = background-color:#EAEAFF;
 | above      = Subexample
 | abovestyle = background-color:#F9F9FF
}}
{{Navbox
 | name       = Navbox
 | title      = Example
 | titlestyle = background-color:#CCF2FF;
 | above      = Subexample
 | abovestyle = background-color:#DDF6FF
}}
{{Navbox
 | name       = Navbox
 | title      = Example
 | titlestyle = background-color:#FEC;
 | above      = Subexample
 | abovestyle = background-color:#FFF3DD;
}}
The issue exists for the normal point 'show/hide' button and the V.T.E links. Personally, I'd rather revert Wikipedia's chosen Vector 2022 {{Legend inline|#36C}} links as it is wholly impossible to meet WCAG AAA 2.0 with that font colour as even on a white background the normal point font only contrast 5.36:1, whereas WCAG AAA standards set 7:1. I much prefer Vector 2010's {{Legend inline|#0645AD}} links for specifically this reason. I have Vector 2010 enabled in preferences, so for me there is no issue, but that's just not true for the overwhelming majority of Wikipedia readers. [[User:Mr rnddude|Mr rnddude]] ([[User talk:Mr rnddude|talk]]) 06:35, 29 August 2026 (UTC)

:The relevant earlier consensus was {{section link|Template_talk:Navbox/Archive_19#RfC:_Should_the_default_colors_for_this_template_be_changed_to_satisfy_AAA_level_accessibility_color_contrasts_WP:COLOR?_If_so,_to_which_colors?}}. I had a separate discussion that was very related at {{section link|Template_talk:Navbox/Archive_24#Inaccessible_links_in_navbar}}. You also need to consider <code>a:visited</code>, not just <code>a</code>. Which limits the colors even more dramatically. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 15:47, 29 August 2026 (UTC)
:In general, I think we should strive for best effort here. The other factor I think we should consider is that WCAG 2 is not really the best contrast standard. WCAG 3 ([https://www.w3.org/WAI/standards-guidelines/wcag/wcag3-intro/ in development]) uses an algorithm called Accessible Perceptual Contrast Algorithm to decide whether contrast is good. It takes into account additional factors like text boldness and size (and I think the actual contrast calculation differs but I do not remember).
:I don't know if APCA helps or hurts but given that there is a lot of bold in these templates in the purple colored parts I suspect it will help. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 15:54, 29 August 2026 (UTC)
::a:visited appears to be {{Legend inline|#6A60B0}} (#6A60B0). The colour contrast scores for it are as follows: {{Legend inline|#EAEAFF}} (4.52:1 - pass); {{Legend inline|#CCF2FF}} (4.52:1 - pass); {{Legend inline|#FEC}} (4.69:1 - pass). It seems to be about a bad a colour as #36C overall with the same limit of 5:36:1 against {{Legend inline|#FFF}}. For clarity, I am not proposing AAA compliance here as it is not possible to achieve it with the Vector 2022 skin; it is possible to achieve AA compliance despite it. I'm really proposing we attain the bare minimum here. WCAG 2.0 also does take into consideration boldness (14pt/18px + bold) and font size (18pt/24px) with a reduced contrast requirement of 3:1. {{pb}} WCAG 3.0 is in development and will not be ready for ''years'' to come. Its 'contrast ratio test' is in the exploratory phase with {{tq|the contrast algorithm used in WCAG 3 is yet to be determined}}.[https://www.w3.org/TR/wcag-3.0/#dfn-contrast-ratio-test 1] APCA may be a candidate, but that sets a higher standard to achieve. #36C and #6A60B0 both require 14pt/700w on a {{Legend inline|#FFF}} (#FFF) background and even {{Legend inline|#000}} (#000) fails below 14px/500w or 15px/400w.[https://apcacontrast.com/ 1][https://www.achecks.org/apca-accessible-colour-contrast-checker/ 2] Though this is a distraction, as whether or not WCAG AA is the best standard isn't meaningful when we're below even it (here and elsewhere). {{pb}} This also doesn't address whether any of the proposed solutions are viable/desirable. The lighter colours in all cases seem to increase the immediate identifiability of the show/hide button and the V.T.E links. I don't expect anyone to favour the bright orange despite it scoring the highest (both on WCAG and APCA with an Lc of 67.1), because it doesn't fit with the general Wikipedia aesthetic, it is mostly of demonstrative value. We could at the very least simply brighten the existing colour. [[User:Mr rnddude|Mr rnddude]] ([[User talk:Mr rnddude|talk]]) 00:18, 30 August 2026 (UTC)
::Addendum, since I'm re-passing here: I neglected to mention that the current font size and weight of the V.T.E links and the show/hide button is 14px/400w. They do not benefit from the reduced contrast requirement for either WCAG or APCA.  [[User:Mr rnddude|Mr rnddude]] ([[User talk:Mr rnddude|talk]]) 08:25, 30 August 2026 (UTC)
:::Yes, "best-effort" was an acknowledgement that AAA is definitely silly even to attempt at this point and that AA was sillier than not.
:::I agree that orange is the wrong direction. I am partial to grey personally, but changing the lightness would be a start. We'd have to hash out the intermediate colors also. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 19:41, 31 August 2026 (UTC)
::::The only intermediate colour that I was able to identify with a problem for both a and a:visited is that used for the various subheaders of {{Legend inline|#DDF}}. I shifted both {{Legend inline|#CCF}} and {{Legend inline|#DDF}} by the same amount to {{Legend inline|#EAEAFF}} and {{Legend inline|#F9F9FF}}. The colours of the list entries {{Legend inline|#FFF}} and {{Legend inline|#F7F7F7}} don't present any problems, though I suppose you could match the light grey list colour to the light blue-grey colour as in {{Legend inline|#F7F7FF}} and {{Legend inline|#F7F7F7}} or {{Legend inline|#F9F9FF}} and {{Legend inline|#F9F9F9}}. I suspect the distinction being drawn is too narrow for 99% of people to be able to tell without checking the source code. I checked these colours against APCA as well and in all cases we're looking at a score above Lc60 which is stated to be '[t]he '''''minimum''''' level recommended for content text that is not body, column, or block text [... as in] text you want people to read' (''emphasis in original'').[https://apcacontrast.com/ 1] In dark mode, everything appears to be fine under our current standard, though APCA presumably finds the link colours of {{Legend inline|#88A3EA}} and {{Legend inline|#A799CD}} to be an issue with the background colour of the documentation template of {{Legend inline|#0B1B1C}} – the navbox itself defaults to a transparent background. That isn't an issue to address here as it applies to all links on every template documentation page; it also has no bearing on the navbox as it appears in articles. [[User:Mr rnddude|Mr rnddude]] ([[User talk:Mr rnddude|talk]]) 23:51, 31 August 2026 (UTC)
:::::We should sort out the light colors before worrying about the dark, IMO. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 23:56, 31 August 2026 (UTC)
::::::Then are there any other colours you need me to address? [[User:Mr rnddude|Mr rnddude]] ([[User talk:Mr rnddude|talk]]) 02:47, 3 September 2026 (UTC)

== Want to create Template:1300s ==
Create An Navbox, [[Template:1300s]] <!-- Template:Unsigned IP --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/~2026-47853-29|~2026-47853-29]] ([[User talk:~2026-47853-29#top|talk]]) 01:24, 3 September 2026 (UTC)</small>
:Does anyone know where this should be posted? The above is referring to a new navbox which has been placed at [[Template talk:1300s]]. It has been used at [[Kremnica Mint]] + [[Leffe]] + [[Wieliczka Salt Mine]]. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 02:06, 3 September 2026 (UTC)
::Note: I've since moved it to {{tl|Companies established during the High Middle Ages}} as "1300s" was a confusing and unhelpful name for its content. – [[User:Scyrme|Scyrme]] ([[User talk:Scyrme|talk]]/[[WP:SOLIDARITY|solidarity]]) 04:07, 3 September 2026 (UTC)
:::To be clear, my moving the template out of the Talk page and changing its title to match its content are not reflections of my views regarding whether or not the template should exist at all. I only intended to make the template function as intended, and I have no strong opinion about whether it should be kept or deleted. Feel free to nominate it at [[WP:TfD]]. {{pb}} I also have no strong attachment to the name I chose; I only intended to address the vagueness of its previous name. – [[User:Scyrme|Scyrme]] ([[User talk:Scyrme|talk]]/[[WP:SOLIDARITY|solidarity]]) 04:41, 3 September 2026 (UTC)
:And now [[Template talk:DC Franchise]]. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 03:47, 3 September 2026 (UTC)
::The content seems to be redundant with {{tl|Live-action theatrical films based on DC Comics}}. – [[User:Scyrme|Scyrme]] ([[User talk:Scyrme|talk]]/[[WP:SOLIDARITY|solidarity]]) 04:15, 3 September 2026 (UTC)
:::I've nominated it for deletion at [[Wikipedia:Templates for discussion/Log/2026 September 3#Template:DC Franchise]]. – [[User:Scyrme|Scyrme]] ([[User talk:Scyrme|talk]]/[[WP:SOLIDARITY|solidarity]]) 04:24, 3 September 2026 (UTC)