Template talk:Navbox

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?
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, 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. 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 readers. 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, 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. 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. Randy Kryn (talk) 11:11, 31 March 2026 (UTC)

@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, Grand-Duc (talk) 12:39, 31 March 2026 (UTC)

@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 <noinclude>...</noinclude> which makes the navbox visible for mobile users, or it has (b) modified behaviour in Module:Navbox/styles.css for the existing navbox class so that it's visible on the template page, but still not in articles. --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. Chiswick Chap (talk) 13:06, 26 May 2026 (UTC)

Bug in anchors for navboxes with markup in title

There's a issue at 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? Daask (talk) 19:32, 23 April 2026 (UTC)

It seems this was first added in 2016 — Martin (MSGJ · talk) 20:57, 23 April 2026 (UTC)

This is now implemented in the sandbox and tested at Template:Navbox/testcases#Custom id attribute — Martin (MSGJ · talk) 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 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. 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 — Martin (MSGJ · talk) 21:20, 21 May 2026 (UTC)

Unless you have further thoughts on alternative methods, I will implement this today — Martin (MSGJ · talk) 10:25, 1 June 2026 (UTC)

I mean, my personal POV is that people.... shouldn't make "complex" titles. Izno (talk) 16:22, 1 June 2026 (UTC)

How else can we produce the pencil icon in the authority control template? — Martin (MSGJ · talk) 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). Izno (talk) 21:56, 1 June 2026 (UTC)

So your position is that <div id="Authority_control_databases_frameless&#124;text-top&#124;10px&#124;alt=Edit_this_at_Wikidata&#124;link=https&#58;//www.wikidata.org/wiki/Q7749994#identifiers&#124;class=noprint&#124;Edit_this_at_Wikidata539" style="font-size:114%;margin:0 4em"><a href="/wiki/Help:Authority_control" title="Help:Authority control">Authority control databases</a> is fine because it functions perfectly well and is only aesthetically displeasing? — Martin (MSGJ · talk) 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. Izno (talk) 16:14, 2 June 2026 (UTC)

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. Izno (talk) 21:55, 1 June 2026 (UTC)

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

For 'with columns' mode, border-left is hardcoded in the module to #fdfdfd, 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). Plighting Engineerd (talk) 22:35, 5 June 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 this sandbox.

TheFeds 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, |image= (or |imageleft= as might be your desire).

Consider also whether these are decorative uses of an image. 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. TheFeds 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:

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:

Hopefully someone can help me! -Literally Satan (talk) 19:22, 1 July 2026 (UTC)

You need to set the |groupstyle=, not the |titlestyle=. --Redrose64 🌹 (talk) 08:04, 3 July 2026 (UTC)

Redrose is correct. I have changed it in the second navbox above. – Jonesey95 (talk) 12:54, 3 July 2026 (UTC)

Thank you!!! -Literally Satan (talk) 17:32, 6 July 2026 (UTC)

New self-linking behavior

Tracked in Phabricator
Task T424777

When I go to an article like United States and scroll down to the {{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. Sdkb ^talk 03:00, 6 July 2026 (UTC)

Not happening for me; it's black and bold. --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:

1. Go to United States#Maps
2. Move the cursor to the "United States" in the title bar of the top navbox.
3. Click on it, and see if the page reloads.

Sdkb ^talk 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. Sdkb ^talk 14:13, 6 July 2026 (UTC)

That's a Parsoid quirk, try . sapphaline (talk) 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". 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. PrimeHunter (talk) 13:32, 7 July 2026 (UTC)

Thanks for the link, 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). Sdkb ^talk 13:54, 7 July 2026 (UTC)

I have added a note about the issue to Help:Link#Self link. PrimeHunter (talk) 15:12, 7 July 2026 (UTC)