Template talk:Navbox

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Navbox/doc)
Jump to: navigation, search

Merging nowrap navbox[edit]

From the MfD, it is proposed that some features of the above module be merged into Module:Navbox. The proposal is that a new parameter be added. If the parameter is set to yes, each item in each list would be processed by the module to replace:



<span class="nowrap">item</span>

The nowrap span would not be added if it is already present.

Module:Navbox with nowrap lists currently applies that processing to items in each listN parameter, and to parameters above and below (it would also process the seldom-used aboveclass + abovestyle + belowclass + belowstyle although I assume that is unwanted).

For the parameter name, a December 2014 discussion at Template talk:Navbox/Archive 18#Nowrap lists proposed:

  • |nowraplists=yes (from Frietjes; Edokter said that was ambiguous)
  • |nowraplistitems=yes (from Edokter)
  • |nowrapitems=yes (shorter alternative from Edokter; supported by Frietjes at MfD)


  1. Is a parameter in {{Navbox}} doing the above wanted?
  2. Should the parameter be named nowrapitems?
  3. Should parameters above and below have the nowrap processing?

Johnuniq (talk) 04:47, 23 March 2017 (UTC)

@Johnuniq: Not sure; yes; and yes. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
05:03, 23 March 2017 (UTC)
@Johnuniq: yes, yes, yes. note that this would allow for the merger of template:Team roster navbox / Module:Team roster navbox as well, and allow for the removal of explicit &nbsp; and {{nowrap}} markup from a large number of navboxes. I could see a case for |nowrapitems= for all items, and |nowraplistitems= for just the items in the lists parameters, but I think starting with just |nowrapitems= for all items would be a great start. Frietjes (talk) 13:19, 23 March 2017 (UTC)
I suppose my question: Edokter says the nowrap CSS in Common.css was removed because IE would not cooperate. Is that still the case? Is that still the case with modern browsers? If not, I would propose that we should re-instate the CSS that was removed instead. (Ref MediaWiki talk:Common.css/Archive 15#Horizontal lists: Default nowrap behaviour for list items disabled perhaps.) --Izno (talk) 16:22, 23 March 2017 (UTC)
Izno, the only potential problem is that we have gone so long now without nowrap for hlists, that turning it on by default could cause problems. I recall having to add {{allow wrap}} to long list items (e.g., footnotes) before the nowrap css was disabled. but, I wouldn't object if people feel that the good outweighs the potential problems. I think it would take longer to get nowrap for hlist back into MediaWiki:Common.css than it would to add something here. Frietjes (talk) 19:36, 23 March 2017 (UTC)
I'm skeptical. The principal objector in the previous case (and who was otherwise generally careful with site CSS, JS, and templates) is who-knows-where. I would guess that the majority of people here would be willing to sacrifice the offending browser(s). --Izno (talk) 19:46, 23 March 2017 (UTC)
How can this be moved forward? Would WP:VPT be the right place to ask about the technical issues such was whether restoring the nowrap CSS would be desirable, and which browsers might be affected, and whether that is a problem. First, it would be helpful to find a link to something specific about the "nowrap CSS" that I know nothing about. Hmm, perhaps 17 November 2013 is a diff showing Edokter removing the CSS that is now wanted. The edit summary was "hlist: removing default list item nowrap behaviour; it causes to many issues in IE, and each fix causes even more issues", and it was briefly discussed here. Johnuniq (talk) 03:04, 24 March 2017 (UTC)
I'd start at MT:Common.css and if no response, invite editors at VPT (as well as here, and perhaps TT:Sidebar). --Izno (talk) 14:23, 24 March 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── and, the entire process has been torpedoed again, with the added bonus of having functionality removed this time (module was deleted with no solution added). I still don't understand why we can't just add something to this module as suggested above. Frietjes (talk) 14:40, 1 May 2017 (UTC)

OK I'll start on this and should have it in the sandbox soon. Will post here. Johnuniq (talk) 01:39, 2 May 2017 (UTC)
@Frietjes: I will never understand what all the css stuff is doing and fortunately I do not need to. However, I see that class="nowraplinks..." is in the output of a navbox (see my sandbox2 or permalink). Very briefly and only if you happen to know, what is that about and what would be the effect of nowrapitems=yes at say Atlanta Braves#Current roster? Is that article the kind of thing aimed at? If not, what is? I would feel more comfortable if I knew what the module changes should achieve in a sandbox test, so if you have an example demonstrating the issue, you might like to edit my sandbox2 to replace its contents. Johnuniq (talk) 04:23, 2 May 2017 (UTC)
I updated sandbox2 to show a navbox with a list. I think that is the issue? That means the module needs to break each listN item into lines, and put the nowrap around each line, but if there is an asterisk at the start of the line, do not include it in the nowrap? LOL, it's all coming back to me now because I looked at it before. Johnuniq (talk) 05:07, 2 May 2017 (UTC)
Relax everyone! I found my note where I had copied the now-deleted Module:Navbox with nowrap lists and that makes it clear what is wanted. Johnuniq (talk) 05:50, 2 May 2017 (UTC)

I updated the sandbox module to handle nowrapitems=yes. I will examine the code in the next day or two because it was rather rushed and is untested. Please use {{navbox/sandbox}} to try it out. It would be good if a few simple tests could be put somewhere, possibly my sandbox2. Johnuniq (talk) 11:50, 2 May 2017 (UTC)

Johnuniq, thank you, anything using Template:Team roster navbox would be a potential test case. other test cases include Template:US Presidents, and possibly Template:Orders, decorations, and medals of the United Kingdom (see note in the source). Frietjes (talk) 12:50, 2 May 2017 (UTC)
@Frietjes: I put a demo in my sandbox2 (permalink). Please carefully examine it, and preferably examine the html source, to check everything seems ok. If you confirm that it is ready, and no one sees any problems, I will update the main module. — Preceding unsigned comment added by Johnuniq (talkcontribs)
Ping for Frietjes, since John's post will not have pinged (missing sig). --Izno (talk) 12:00, 3 May 2017 (UTC)
Johnuniq, thank you, looks great. I diffed the HTML source and the only change is the addition of the "span nowrap" tags, which is exactly what we want. I also diffed the output from the live and sandbox version, and there were no differences when nowrapitems was not equal to yes. so, I would say it's ready to go. thank you again. Frietjes (talk) 13:11, 3 May 2017 (UTC)
OK, it's live. Johnuniq (talk) 01:49, 4 May 2017 (UTC)
Johnuniq, thank you. I tried it in Template:Champion shot medals and it appears to be working well. Frietjes (talk) 14:50, 4 May 2017 (UTC)
Here's a list of some to look at updating -- WOSlinker (talk) 18:48, 4 May 2017 (UTC)
WOSlinker, thank you! I updated most of the entries on the list. one interesting quirk that I found while working through the list is the following:
{{Navbox | listclass = hlist | nowrapitems = yes | list1 =* {{MOSMETRO-bull|11|text=2}} }}
. Johnuniq, any ideas on what is going wrong with this one? otherwise, it looks like it's working great! Frietjes (talk) 20:01, 4 May 2017 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────@Frietjes: Special:ExpandTemplates gives the following result for {{MOSMETRO-bull|11|text=2}}:

[[Third Interchange Contour|<span title="
#11 Third Interchange Contour"><span style="font-weight:bold"><span style="font-family:sans-serif;font-size:15px;color:
#000000;;border-radius:15px;line-height:15px;"><span style="letter-spacing:-1px"> 11 </span></span></span></span>]]<span > [[Third Interchange Contour|Third Interchange Contour]]</span>

The above is four physical lines. The last three lines start with "#" and the module (when nowrapitems=yes is used) interprets them as forming a numbered list, so the module inserts the nowrap span around the rest of the physical line that follows each "#". I guess that MOSMETRO-bull should be fixed so it does not produce separate lines. Is that reasonably achievable? Johnuniq (talk) 22:49, 4 May 2017 (UTC)

Fixed with some edits to {{MOSMETRO-bull}} and {{font}} -- WOSlinker (talk) 07:42, 5 May 2017 (UTC)
looks like that fixed it, so the lesson here is to look for constructs like {{#if: ... | #00AABB }} since the parser inserts a newline before the # making it look like an ordered list item. Frietjes (talk) 13:50, 5 May 2017 (UTC)

Is there a way to stop separator middle dot from detaching from previous item? Sometimes it gets displayed at the very beginnig of the new line. It could be done in a similar way as external link icon is handled in CS1 modules. --Obsuser (talk) 15:43, 7 May 2017 (UTC)

Is this with the new nowrapitems=yes parameter, or is that irrelevant?
Navbox does not control middots in any way I can see. Given a list of three items, navbox outputs html for the list as follows:
  <th scope="row" class="navbox-group">Three examples</th>
  <td class="navbox-list navbox-odd hlist" style="text-align:left;border-left-width:2px;border-left-style:solid;width:100%;padding:0px">
    <div style="padding:0em 0.25em">
      *Example 1
      *Example 2
      *Example 3
Someone might have a suggestion how that could be tweaked. Johnuniq (talk) 01:53, 8 May 2017 (UTC)
In Russian Wikipedia we just use hlist-items-nowrap class in ru:MediaWiki:Common.css for nowrap items. Iniquity (talk) 19:22, 1 June 2017 (UTC)

Bug with collapsible navbox?[edit]

For example, if I go to Carbon_monoxide#Lasers, and click "show", it scrolls me up to the top of the page and the navbox is never open at all. What is wrong? Llightex (talk) 13:14, 16 May 2017 (UTC)

@Llightex: It works for me. Try clearing your cache or purging the page (add ?action=purge to the end of the URL). What browser are you using, and do you have any scripts enabled? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
13:29, 16 May 2017 (UTC)
@Jc86035: You're right, it was due to a script. Thanks!

Border-spacing instead of gutter rows[edit]

I'd like to propose using CSS border-spacing for layout rather than HTML gutter rows. I've made the relevant changes at Module:Navbox/sandbox. Template:Navbox/testcases should show no significant differences in modern browsers or IE ≥ 8. Matt Fitzpatrick (talk) 05:52, 17 May 2017 (UTC)

@Matt Fitzpatrick: The padding between groups and lists seems to too wide (especially for the odd-numbered/grey rows). The border-spacing might work better at 0.15em instead of 0.2em, although it doesn't fix the aforementioned issue. (Firefox 53.0.2.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
06:29, 17 May 2017 (UTC)
@Jc86035: Got it, thanks! I tweaked the border-spacing to be vertical, i.e. between rows, only. Matt Fitzpatrick (talk) 06:45, 17 May 2017 (UTC)
@Matt Fitzpatrick: There are also some issues with child navboxes, like in Template:Navbox/testcases#Subgroup tests and Template:Navbox/testcases#Container tests. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
06:55, 17 May 2017 (UTC)
@Jc86035: Phew! After much trial and error, it looks like the best solution might be to go back to basics. This sandbox diff just strips the gutter rows, nothing fancy. This CSS, once merged into the sitewide CSS, applies the new borders. :first-child is CSS 2.1, so this should work all the way back to IE 6. Matt Fitzpatrick (talk) 12:13, 17 May 2017 (UTC)
Got it down to one new CSS rule instead of two (diff). Tested on IE7 and 8, seems okay. Will put in a common.css edit request in a few days if no problems come up. Matt Fitzpatrick (talk) 06:32, 27 May 2017 (UTC)
FYI, I had to change navbox Canada to use box-shadows instead of borders after this change. there may be other templates which were using borders. but, the fix isn't that difficult. Frietjes (talk) 15:18, 3 June 2017 (UTC)
@Frietjes and Matt Fitzpatrick: There may be as many as 200 of them (although there might be more; example fix). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
09:21, 24 June 2017 (UTC)
@Jc86035 and Matt Fitzpatrick: it would be possible to automatically transform inside of navbox, but that might be a bit much. so, for now, I created Template:Box-shadow border to simplify the syntax. let me know if you see any problems with the implementation, or would like to change the parameter order, etc. thank you. Frietjes (talk) 14:49, 25 June 2017 (UTC)
@Frietjes: Works well; thanks for creating the template. I've fixed a few more templates, although they may need to be gone through again because many of the ones I've fixed are international sports navboxes which are supposed to use consistent colours across the series for each continent but don't due to arbitrary ordering of groups. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
16:10, 25 June 2017 (UTC)
@Jc86035 and Matt Fitzpatrick: in renderNavBar we have 'border:none' to stop the V-T-E links from inheriting border styling from the titlestyle / basestyle. if we are going to use box-shadow for the borders in the basestyle or titlestyle, we probably want to add something similar for 'box-shadow', '-moz-box-shadow', '-webkit-box-shadow'? I had to execute this revert since it was adding box-shadows to the V-T-E links. Frietjes (talk) 23:00, 28 June 2017 (UTC)
@Frietjes: Added a box-shadow test at Template:Navbox/testcases#Navbar and state tests. There's probably a nicer way to strip CSS declarations from the navbar, but this change seems to work for now. Matt Fitzpatrick (talk) 00:20, 29 June 2017 (UTC)
Matt Fitzpatrick, thank you. if you look at the extractstyle function in Module:Team roster navbox, I pull out only the color and background from the style to pass on to the span inside the links. that module could probably be merged with this one at some point. the only thing that it does that the standard navbox module doesn't do is automatically color links. Frietjes (talk) 13:35, 29 June 2017 (UTC)


Is it possible to fix cases like this so that |image= content is automatically aligned to the right, |imageleft= content to the left, and main content always centered? --Obsuser (talk) 05:35, 19 May 2017 (UTC)

@Obsuser: What's the issue in the linked page? I'm not sure what the problem is. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
09:17, 19 May 2017 (UTC)
Right image is not aligned "totally" right (what looks better and is more intuitive to expect), and bigger issue – main content (block of hlist items) is not centered but pushed to the left. /Win7, Chrome/
This is not noticed maybe when there is more links but in this case it is.
Image alignment can be fixed by adding either |imagestyle=text-align:right (|imageleftstyle=text-align:left) or |right (|left) in the [[File:]] syntax. But is is case with every image i.e. chance that someone added this is smaller than that one didn't (as in my example). Main content is not centered in any case. I played in sandbox with previewing modification of adding the same image on the left if right is defined and left is not (and same image on the right if left is defined and right is not) with visibility:hidden in order to center content but column tags got mixed and it did not work...--Obsuser (talk) 09:39, 19 May 2017 (UTC)
@Obsuser: the common fix for centering the list in that case is to use |liststyle=padding-left:50px to offset the 50px width of the image on the right. Frietjes (talk) 14:04, 20 May 2017 (UTC)
Can this be fixed automatically? --Obsuser (talk) 15:21, 20 May 2017 (UTC)


Hello, can anybody help me? I want to move arguments from ru:Module:Navbox to a datatable (for example ru:Module:Navbox/data), is it possible? I am using local variables for localization now, but I think it is a bad way. Iniquity (talk) 23:56, 1 July 2017 (UTC)

Padding for images and width for Authority control cell[edit]

Could someone review and add these edits: 5px padding for images and removal of width:auto in Authority control template so that this cell does not get too wide? --Obsuser (talk) 17:25, 9 July 2017 (UTC)

I have too little context here to evaluate these changes. Please provide examples, argumentation etc. —TheDJ (talkcontribs) 17:48, 9 July 2017 (UTC)

Navbox|border=subgroup vs. navbox subgroup[edit]

In the documentation, it states that It is recommended that one use {{Navbox subgroup}}, but the same result can be reached by using {{Navbox}} with border = child or the first unnamed parameter set to child.. can someone explain why it's recommended to use {{navbox subgroup}} instead of {{navbox|subgroup}}? I would think the recommendation would be the reverse since (1) using {{navbox subgroup}} is less efficient due to the additional wrapper later, and (2) {{navbox subgroup}} cannot support more than 20 groups/lists. I am guessing that this recommendation (which was added by CapitalR in this edit) was true in the past, but is no longer true? Frietjes (talk) 21:18, 14 July 2017 (UTC)

While working on Module:Navbox last March I wondered about {{Navbox subgroup}} but ended up ignoring it as what I was doing was already complex. A very quick look at the wikitext in {{Navbox subgroup}} suggests that it tries to pass all parameters to {{Navbox}} except that grouppadding defaults to 0em 0.75em;. Is {{Navbox subgroup}} useful? I have not followed the work done on the module recently regarding using css, but presumably any default padding should be set there. Johnuniq (talk) 23:24, 14 July 2017 (UTC)
I agree that we should be setting any padding for subgroups in MediaWiki:Common.css, and to avoid confusion we should have the same group padding for both {{navbox subgroup}} and {{navbox|subgroup}}. checking the current MediaWiki:Common.css I see padding: 0.25em 1em which is close to the 0em 0.75em value. if we really want to have less padding for groups in subgroups, I believe we can handle that in MediaWiki:Common.css as well. It would be great if {{navbox subgroup}} were a very thin frontend that was functionally equivalent to {{navbox|subgroup}}. Frietjes (talk) 23:40, 14 July 2017 (UTC)
for a comparison try
{{navbox| group1 = group1| list1 = {{navbox subgroup | group1 = group1a | list1 = list1a}}}}
{{navbox| group1 = group1| list1 = {{navbox|subgroup | group1 = group1a | list1 = list1a}}}}
Frietjes (talk) 23:42, 14 July 2017 (UTC)
I put an example in my sandbox (permalink). I can hardly see a difference. Does anyone know of cases where {{navbox subgroup}} should not be replaced with {{navbox}}? Johnuniq (talk) 00:37, 15 July 2017 (UTC)
I don't know of any. If I recall, we used to have Template:Navbox generic and Template:Navbox subgroup, so the slight difference may be something left over from the merge. Thanks! Plastikspork ―Œ(talk) 12:42, 15 July 2017 (UTC)

There are thousands of templates that link to Template:Navbox subgroup. Previewing what happens if the subgroup template is not used shows a very minor difference in spacing—if that difference is desirable, it should be in the main template. Any thoughts on how to proceed? The cautious approach would be to edit a couple of navboxes from the "what links here" list to replace
{{navbox subgroup|...}} with
then see what happens. A faster strategy would be to replace {{navbox subgroup}} with a redirect to {{navbox}}. Johnuniq (talk) 04:34, 20 July 2017 (UTC)