Template talk:Navbox

Active discussions

Request for an "experimental" parameter to allow innovation in getting navboxes to show up on mobileEdit

Hi there! I come here from Template_talk:Taxonbar#Making_Taxonbar_mobile-friendly_and_serve_half_of_all_Wikipedia_readers. As you may be aware, many navboxes are unusable on mobile and break the reading experience and as a result are removed by brute force from the mobile site.

This was meant to be a short term solution, but as with most short term solutions has become long term (see phab:T124168. I'm keen to make steps to rectify this beginning with the Template:Taxonbar, however I need a slight adjustment here to allow me to do this.

My hope here is to provide a general solution that can be applied to other templates.

Any element with the `navbox` class will be removed from the HTML on mobile, so to workaround this issue and allow experimentation in the area, a temporary parameter is needed that will allow us to use a different class to e.g. `navbox-experimental`. Feel free to name this parameter/class anything that makes sense. It could also be mobile=1 and `navbox-mobile-friendly` for example. The important thing is the `navbox` class should not be added.

e.g. proposed change:

		local nav = res:tag('div')
			:attr('role', 'navigation')
			:addClass('navbox')
			:addClass(args.navboxclass)

to

		local nav = res:tag('div')
			:attr('role', 'navigation')
			:addClass(args.experimental ? 'navbox-experimental': 'navbox') # not sure if this is valid Lua code but hopefully it's clear what I'm trying to do here. The class should be navbox-experimental when the flag is set.
			:addClass(args.navboxclass)

Is this possible? If so I promise to report back when I have something cool to show. Jdlrobson (talk) 23:24, 24 November 2020 (UTC)

I actually recently just set everything to display block in a media query and it actually looks pretty reasonable as a first-try stupid solution. There's some white space that is showing up that's weird and I don't know how it will go with e.g. the image cell. Try it in Timeless or Minerva on the desktop domain while on mobile. (I haven't had a chance to look at Anonymous's solution yet since he put something on the task recently.)
I'm not really a fan of a parameter for it.... If it's successful it's a lot of cleanup of an unused parameter and if it's not successful it's a lot of cleanup of an unused parameter. --Izno (talk) 00:38, 25 November 2020 (UTC)
I'm not a fan of a parameter either TBH, but without the parameter, I see this as a little deadlocked as I don't have any intention of fixing all the navboxes right now. The alternative would be to fork the template e.g. Template:NavboxV2. Would that be better? Jdlrobson (talk) 02:04, 25 November 2020 (UTC)
You don't have to fork it, just use Module:Navbox/sandbox. I gather you plan to make a sandbox with some text and a modified navbox, then view the result on mobile? And experiment to see what is needed to make mobile work? Another approach would be to use Special:ExpandTemplates to get the output of whatever you are working on, then edit the raw html in a sandbox. As I recall, this module puts everything in one line which make editing a bit ugly. I think that's why I once used Module:Dump#Dumping a navbox. Lua uses "and...or" as a useful kludge for "?...:". I can put that in a module if needed. Johnuniq (talk) 05:58, 25 November 2020 (UTC)
It might just be preferable to write in a hard exception here as in 'if name = Authority control then navbox-exp else navbox'. That said, that particular template is a really simple example to try to work on these problems, and I'm fairly sure it will not extend. As for TemplateStyles, we still have not decided how to deal with TemplateStyles in these meta modules; the solution I'm coming around to supporting is something of the "for templatestyles..n parameters, add a templatestyles tag" so that multiple invoking templates (i.e. navbox -> intermediate navbox -> final navbox) can have access to their own tstyles. (This of course makes the special 'single border' CSS harder to write.)
In general, just spitballing and/or providing info. --Izno (talk) 18:37, 25 November 2020 (UTC)
(On an aside, I am not entirely certain Authority control needs to be written using navbox at all; it's such a simple template that it could reasonably be written in like 4 lines of Lua to remove the navbox dependency. I don't know what the collective thoughts are on such a thing. --Izno (talk) 18:39, 25 November 2020 (UTC))

Non-unique idEdit

I noticed that this template uses the title of the navbox as an ID (:attr('id', mw.uri.anchorEncode(args.title))). However, it cannot be assumed that these IDs will always be unique, which creates invalid HTML. For an example of this, see the article Madame Nhu, which has a section titled Buddhist crisis, as well as a navbox Buddhist crisis. The fact that navboxes are usually present on related subjects makes such occurrences likely. I propose that when the ID is created, that it be prefixed with "navbox_" so it doesn't clash with any section headers or user-added anchors. Opencooper (talk) 17:01, 17 December 2020 (UTC)

Not sure what you mean by "invalid HTML"; what tangible effect is this having on the page? Primefac (talk) 17:08, 17 December 2020 (UTC)
For now, maybe none (though I noticed it because I have a userscript that does stuff with IDs and the elements ended up getting switched). However, the concern is that any CSS or code that targets this specific ID in the navbox will instead end up being applied to an anchor that comes before it (run document.getElementById("Buddhist_crisis") on the Nhu page and you'll only get the header). Currently I see the following inline style being applied: font-size:114%; margin:0 4em. Given that eventually the goal is to move inline styles to TemplateStyles, this might end up happening inadvertently.
And the HTML is invalid because IDs are supposed to be unique within a document. Here it is straight from the spec: When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree (note, "must"). Given that we could make our HTML valid just by prefixing the ID, I think this should be addressed. Opencooper (talk) 17:39, 17 December 2020 (UTC)
Yeah, I noticed this template was emitting an ID the other day and wasn't sure how to deal with it. Given its use for ARIA labelledby, I think tacking on a "_navbox_aria" in the string creation makes sense (or something to that effect). Still can't do much about the testcases page, but that's not exactly a use case envisioned by W3C/WHATWG regarding IDs. Best would be an overhaul of this template to not use tables, which may/not come around the time TemplateStyles get integrated. (I've slowly been working on the latter if you are interested at Mediawiki talk:Common.css/to do.) --Izno (talk) 18:06, 17 December 2020 (UTC)
I think it's fine if the testcases page has duplicates since that's not really reader-facing. Agreed with your proposed solution, though it might all be moot if the whole thing gets overhauled. Opencooper (talk) 18:45, 17 December 2020 (UTC)

Can |groupwidth = __ be used to narrow cells?Edit

Using the "|groupwidth = #em " parameter appears to force extra whitespace and widen the group column of a subgroup, but is there a way to force the column to be narrower? I am asking because a long group name can force extra whitespace into all of the other group names. I can insert <br /> line breaks manually to adjust this, but I was wondering if there is a way to let auto-formatting take care of that via a fixed groupwidth. -2pou (talk) 19:54, 17 December 2020 (UTC)

@2pou: You have to override the nowrap, so |groupstyle=width:8em;white-space:normal; should do it, or whatever width is appropriate. Thanks! Plastikspork ―Œ(talk) 14:57, 18 December 2020 (UTC)
Thanks, Plastikspork! The white-space:normal worked like a charm: Special:Diff/994992577. I couldn't get the width part to narrow down any further, but this does what I was looking for. -2pou (talk) 16:53, 18 December 2020 (UTC)

"Purely decorative" imagesEdit

The template documentation says of its image field that "Typically it is purely decorative"... yet MOS:DECOR says "Icons should serve an encyclopedic purpose and not merely be decorative." Should the documentation reflect that, and discourage images that only add decoration? If so, where's the line drawn for what's "decorative"?

I had the policy pointed out to me by someone removing a picture of a potato from Template:Potato dishes, which is maybe fair enough, but that kind of usage seems fairly common across navbox templates. --Lord Belbury (talk) 17:59, 12 January 2021 (UTC)

I've taken a bold approach and edited the doc. — Mike Novikoff 00:50, 16 January 2021 (UTC)
WP:DECOR is about icons, little national flags and that sort of thing, not images in general. Also it is a manual of style matter, offering guidance, not hard rules. The bold edit above saying most images should be removed on sight is grossly inappropriate and, in my view, should be reverted. DECOR does not apply and this discussion should not have been regarded as concluded. Thincat (talk) 11:10, 22 January 2021 (UTC)
WP:DECOR also talks about navigation and discourages images that serve no navigational purpose. I agree that images should be in navboxes only in exceptional circumstances. They take up space better used for navigational links, and they do that typically on many pages. WP:DECOR's They should provide additional useful information on the ... subject, serve as visual cues that aid the reader's comprehension, or improve navigation. is good advice. -- Michael Bednarek (talk) 12:10, 22 January 2021 (UTC)
Are we referring to different guidelines? By my understanding WP:DECOR is the section of the manual of style relating to icons. What you say may be the case but it isn't DECOR that says it. Thincat (talk) 13:03, 22 January 2021 (UTC)
WP:DECOR defines icons as any small images and it deals with navigational issues. This discussion start with concerns about Template:Potato dishes; what possible value does the small image in this version of that template have? -- Michael Bednarek (talk) 17:16, 23 January 2021 (UTC)
I'm not giving any opinion on its value. I'm saying it isn't an icon. And DECOR doesn't say either icons or small images should be removed on sight. Thincat (talk) 19:06, 23 January 2021 (UTC)
If pages with multiple navboxes collapse them all by default, which seems to be the case, I suppose there can be no possible navigational purpose to the image field - the user has to navigate to and open the box before they see the image. Stacked navboxes on an article like Knish would be quicker to navigate if they all had recognisable icons (the excessive example at File:Navboxes - Jennifer Doudna - en.Wikipedia - 2020-10-07.png has clear Nobel Prize sections even at illegible thumbnail size), but not if they all start off collapsed. --Lord Belbury (talk) 12:32, 4 February 2021 (UTC)
I find the image in Template:Jewish cuisine counter productive. Without it, there would be less wasted whitespace, and I wouldn't need to scroll to see all the links. The image in Template:History of biology is better because the aspect ratio is more compatible with the box content. Thanks! Plastikspork ―Œ(talk) 14:53, 4 February 2021 (UTC)

Group without a child list itemEdit

Inside the template Template:Trade unions in Myanmar navbox for list2= item, I am forced to put something there, otherwise even the group2 won't show. Does anyone have a work around, besides for empty/invisible string? Shushugah (talk) 21:40, 25 February 2021 (UTC)

1, The navbox shouldn't exist with that many redlinks. 2, you shouldn't have group with no list items. 3, if you needed it you can use above/below to put that link. But once again, this navbox should only exist to navigate between existing pages. DLManiac (talk) 22:14, 25 February 2021 (UTC)
Agreed. If you're trying to have a navbox where only the group shows, you need to rethink and/or restructure your navbox. Personally, with that navbox I would use sequential indentation for |list1=, having what are currently your "groups" under * and all of the values in "list1" having ** indentation. That will still give you the necessary splits without having to bodge things up. Primefac (talk) 15:28, 26 February 2021 (UTC)
Return to "Navbox" page.