Template talk:Navbox

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Navbox not showing right[edit]

My Navboxes

  • dont show any border,
  • are squeezed to the left
  • have "vte" in vertical bullet-list and
  • consist of {{{title}}}{{{group1}}}|{{{list1}}}, etc. stuff

I exported/imported the whole Navbox-Template-Series, style (MediaWiki:Common.css) and script (MediaWiki:Common.js) and have LUA running. Afaik, I've Tidy running (although I found a statement saying it's not needed anymore).

Plz, what else is needed or needs to be done?!?Collabet (talk) 11:02, 3 March 2014 (UTC)

Did you also copy the styles for .navbar and .hlist? Edokter (talk) — 11:40, 3 March 2014 (UTC)
Took the whole common.css (fresh MW 1.22 so didnt care) .navbar/.hlist not in there?!?Collabet (talk) 12:32, 3 March 2014 (UTC) ... thx for the hint! Dunno what the "export pages" put into my package, but it sure wasnt the media:common.css ... now it's running ... 2 days^^ *gnarf*Collabet (talk) 12:43, 3 March 2014 (UTC)
I am also running into trouble porting this over to another Wiki. I don't have server side access, but I did copy the (MediaWiki:Common.css) and script (MediaWiki:Common.js) (tied the ones from MediaWiki first then Wikipedia, but both had the same result). Most of the navbox displays correctly, except my lists are vertical. I copied the navbox/doc subpage, so I know the formatting is correct. I copied {Flatlist} to our Wiki just in case it was required, and it is working fine, but the {navbox} is still vertical. I can see the .navbar and .hlist entries in the Common.css files I copied, so I am not sure what else I missed. We do not have Lua installed, so I am using the original scripts for the non-Tidy installations. The show and hide is working great. Kentsmith9 (talk) 07:35, 29 June 2014 (UTC)
@Kentsmith9: Would you share the link to your wiki ? (I wouldn't mind having a look) also have you posted at MediaWiki help desk ? Mlpearc (open channel) 14:09, 29 June 2014 (UTC)
@Mlpearc: No problem, here http://wiki.waze.com/wiki/Template:USA_Navbox No I have not posted at the help desk, but I will now. Thanks. Kentsmith9 (talk) 16:57, 29 June 2014 (UTC)
I have now posted the question over there as recommended if anyone is having similar problems and wants to see what happens. http://www.mediawiki.org/w/index.php?title=Project:Support_desk#Navbox_not_working_100.25_44855 Kentsmith9 (talk) 16:57, 29 June 2014 (UTC)

hlist wrapping[edit]

so, we now have module:team roster navbox. this is basically a frontend to module:navbox, which adds non-breaking spaces to list items. it seems like this could either be made more general, and/or an option could be added to module:navbox to 'nowrap' list items. basically, you would add <span class=nowrap> to any lists in the input fields if a flag is set. comments? Frietjes (talk) 18:28, 11 March 2014 (UTC)

In the beginning, the entire list item were nowrapped via CSS by default. This caused to many bugs, who's workaround only created more bugs, so the nowrap was removed. As long as you only nowrap the content of a list item, then it should not be a problem. Can you try wrapping the content of the list items inside a nowrap span? Edokter (talk) — 20:40, 11 March 2014 (UTC)
right, the idea is to have the module add <span class=nowrap> to each list item, if a flag is set. Frietjes (talk) 23:21, 11 March 2014 (UTC)
I mean, can you test it in module:team roster navbox instead of adding non-breaking spaces? Edokter (talk) — 01:18, 12 March 2014 (UTC)
yes, will do shortly. Frietjes (talk) 16:20, 15 March 2014 (UTC)
see Module:Navbox with nowrap lists, as implemented in template:navbox/sandbox3. there is an additional hack to prevent lists from being processed twice. for example, when you use child navboxes. seems to work on most of the tests I have tried, but I am sure there is some corner case that I haven't considered. Frietjes (talk) 01:00, 19 March 2014 (UTC)

Would this solve the sublist wrapping error,

  • ............................................................
  • i.e.
  • when |template edge
  • (this
  • happens)
  • ......

instead of

  • ............................................................
  • i.e.
  •   |template edge
  • when (this
  • happens)
  • ......

(at least, in Firefox-based browsers)...? Sardanaphalus (talk) 22:45, 27 May 2014 (UTC)

Categorisation into Navboxes using background colours[edit]

Template:Other category-header templates is in Category:Navboxes using background colours, and that's fine. It's used on Template:Redirect category/doc, which is not in Category:Navboxes using background colours, and that's fine as well. But Template:Redirect category/doc is used in Template:Redirect category, which is in Category:Navboxes using background colours, but shouldn't be. Why is Template:Redirect category in a cat which is not applicable? --Redrose64 (talk) 11:20, 14 June 2014 (UTC)

I see what's going on. The intent of the tracking category is to catch navbox templates that use background colors, but it can't distinguish between navbox templates and regular templates that use navboxes (but it can distinguish between templates and doc pages). There's currently not a good way to fix this, but I plan to add a feature to Scribunto soon that will take care of it. Jackmcbarn (talk) 14:40, 14 June 2014 (UTC)
Is there no equivalent to <noinclude>...</noinclude>? --Redrose64 (talk) 15:17, 14 June 2014 (UTC)
There is, but that won't work. We need it to include one level deep, but no further. Jackmcbarn (talk) 15:23, 14 June 2014 (UTC)
In module Module:Navbox, the code in the hasBackgroundColors function is just checking to see if the titlestyle or groupstyle are used and if they are, the page gets added to Category:Navboxes using background colours. The code could be updated to check for "background" or "background-color" within those two parameters before adding pages to the category since templates such as Template:Other category-header templates use groupstyle but are only setting it to "font-weight:normal;" which has nothing to do with background colours. Should also be checking the basestyle parameter as well. -- WOSlinker (talk) 17:58, 14 June 2014 (UTC)
That fixed this particular instance of the problem, but it didn't fix the root cause. Jackmcbarn (talk) 15:55, 18 June 2014 (UTC)

Template-protected edit request on 18 June 2014[edit]

I would like to add the page "{List of songs recorded by 5 Seconds of Summer} into the template. Btloveadele1d (talk) 09:15, 18 June 2014 (UTC)

I'm sorry, the template linked to the wrong talk page (I fixed that). However, there is no page with the title List of songs recorded by 5 Seconds of Summer, but 5 Seconds of Summer discography does exist, and is linked from the navbox. -- [[User:Edokter]] {{talk}} 09:27, 18 June 2014 (UTC)


There doesn't seem to be a class parameter that's interchangeable with bodyclass as style is with bodystyle – is this correct, or am I just missing something?

If there is no class parameter, then, for the sake of consistency, would someone with the know-how please add it..? Sardanaphalus (talk) 17:31, 18 June 2014 (UTC)

Is there a need for it? If not, adding redundant parameters is not an action that improves the template. In fact, I just removed the style= parameter from the documentation. -- [[User:Edokter]] {{talk}} 18:44, 18 June 2014 (UTC)
  • There may be a need for clarification. I'm not sure if each pair (class / bodyclass, style / bodystyle) is (or should be?) taken as synonymous. Is the "body" of (in this case) a template always taken to mean the entire template, or, for instance, the entire template less anything header or footer-like (e.g. a titlebar, a "below" line, {{navbar}} links, etc)..? The style and class parameters, their documentation and other things may yet be useful (if that qualifies as needed). Sardanaphalus (talk) 15:55, 19 June 2014 (UTC)
The body refers to the entire body of the template. -- [[User:Edokter]] {{talk}} 19:02, 19 June 2014 (UTC)
  • ...except when it's used to refer to the "middle" of the template or to "everything under the title / main heading" of the template, etc. Perhaps, therefore, it's better to retain class and style rather than bodyclass and bodystyle? Sardanaphalus (talk) 07:32, 20 June 2014 (UTC)
We have bodyclass, aboveclass, groupclass, listclass, belowclass and respective style parameters. For additional styling we have even more style parameters like basestyle, imagestyle, etc. That should proivide for any feasable scenario. -- [[User:Edokter]] {{talk}} 10:21, 20 June 2014 (UTC)
  • That's not the point. The point is that bodyclass, bodystyle etc are ambiguous: "body" is sometimes used to refer to (1) an entire template, including headers, footers, etc; and/or (2) a template's container (usually invisible, e.g. a table); or (3) a template's contents other than any headers, footers, etc. So, while I'd retain bodyclass, bodystyle etc as alternate names, I'd keep class and style as the basic names. Sardanaphalus (talk) 15:56, 23 June 2014 (UTC)
For the purpose of styling, 1) and 2) are the same. For the middle, you can combine groupclass and listclass. We're not adding class parameters just for the sake of it. -- [[User:Edokter]] {{talk}} 16:41, 23 June 2014 (UTC)
  • This is still beside the point. It's not about what I might want or could do, etc, etc. It's because "bodyclass" and "bodystyle" are ambiguous. Do you understand? Sardanaphalus (talk) 23:34, 23 June 2014 (UTC)
In any structure with identifiable header(s) or footer(s), the body is that part which is neither header nor footer. When there are neither headers nor footers, the body is then synonymous with the structure as a whole. Either way, it's case (3) described in your post of 15:56, 23 June 2014 - do you have examples of cases (1) or (2)? --Redrose64 (talk) 08:01, 24 June 2014 (UTC)
Not to hand, no, but it's something I've seen a number of times previously. Sardanaphalus (talk) 11:43, 29 June 2014 (UTC)
In navbox, |class and |bodyclass are synonymous. What is your point? -- [[User:Edokter]] {{talk}} 08:30, 24 June 2014 (UTC)
  • That it isn't necessarily thought of as such. Why such resistance to retaining class? Do you also oppose retaining style alongside bodystyle? Sardanaphalus (talk) 11:43, 29 June 2014 (UTC)
──────────────────────────────────────────────────────────────────────────────────────────────────── Yes I do. That is why I removed style= from the documentation. The reason I oppose is simple; what if body and style are needed at some point in the future that does differ in functionality from bodyclass and bodystyle? -- [[User:Edokter]] {{talk}} 12:17, 29 June 2014 (UTC)
  • Any thoughts as to what that functionality might be...? (Meanwhile, class and style should be retained.) Sardanaphalus (talk) 08:22, 30 June 2014 (UTC)


I'm here to request a groupnclass be added to this module. This would be useful for navboxes which have some sections that should only be viewed by certain user groups (such as the "actions" group of {{User toolbox}} for example since all of those pages would return "no permission" type errors, those links shouldn't be shown to "most" users. I've added the code for this functionality to this example template to be able to use it as a preview (since the parameter existing and not being used hurts nothing)). I would do it myself in the sandbox, but don't currently have enough knowledge of Lua to feel comfortable doing it right now (I may tackle it in a few weeks in no-one gets to it by then). Thanks for your consideration in this request. — {{U|Technical 13}} (etc) 15:41, 28 June 2014 (UTC)

I made that change I mentioned and in the process of doing so I've found that groupn and listn when set to display: none; leave an extra gap and I'm hoping someone can fix that. I also found out that setting groupnstyle doesn't also apply to listnstyle... So, I'm assuming that in addition to groupnclass we'll also need listnclass to be able to apply that style (group-show class) to the group and list. — {{U|Technical 13}} (etc) 23:01, 28 June 2014 (UTC)
That is quite different from the above request, so I have split it. Groupn- and listnstyle are ment to work independently; that is by design. I'll have to dive in the gap issue, but that may be an old issue caused by hiding rows and cells. -- [[User:Edokter]] {{talk}} 00:35, 29 June 2014 (UTC)
  • Edokter I'm hoping to get groupnclass and listnclass added to the module, this would eliminate the need to use the ...nstyle because the class would do all the styling... Just to make sure I'm clear. Thanks. — {{U|Technical 13}} (etc) 02:14, 29 June 2014 (UTC)
  • I know where you're going. Unfontunately, as navbox is structured now, it won't work without the gaps. You would want to hide the entire row, plus its accompanying 'gap row' (you'd need a rownclass). Is there any way to detecta usergroup in a module? Then you can simply call that module as a condition checker for the entire group/list. -- [[User:Edokter]] {{talk}} 10:01, 29 June 2014 (UTC)
No, there's no way of detecting user rights from Lua at the moment. — Mr. Stradivarius ♪ talk ♪ 10:23, 29 June 2014 (UTC)

If you change the code in User toolbox from

| group5            = Admin history
| group5class = {{#ifeq:{{Yesno|{{{simple|yes}}}}}|yes|{{#ifeq:{{Yesno|{{{admin|no}}}}}|yes||usertoolbox-admin}}}}
| group5style = {{#ifeq:{{Yesno|{{{simple|yes}}}}}|yes|{{#ifeq:{{Yesno|{{{admin|no}}}}}|yes||display: none;}}}}
| list5style = {{#ifeq:{{Yesno|{{{simple|yes}}}}}|yes|{{#ifeq:{{Yesno|{{{admin|no}}}}}|yes||display: none;}}}}
| list5                =


| group5            = Admin history
| list5{{#ifeq:{{Yesno|{{{simple|yes}}}}}|yes|{{#ifeq:{{Yesno|{{{admin|no}}}}}|yes||donotshow}}}} =

then it will get rid of the gaps. -- WOSlinker (talk) 10:36, 29 June 2014 (UTC)

  • I didn't see anything like this documented... I'll play with it on a testcases page and see if it will work for what I have in mind. — {{U|Technical 13}} (etc) 13:00, 29 June 2014 (UTC)

Wouldn't it be simpler to do (simplified):

{{#if: <very complicated parser function used above>|
{{!}} group5 = Admin history
{{!}} list5  = ...

-- [[User:Edokter]] {{talk}} 11:02, 29 June 2014 (UTC)

  • I'm not aware of any way to get the viewing user's username or groups without JavaScript. Isn't that why the group-show css classes were created in the first place? — {{U|Technical 13}} (etc) 13:00, 29 June 2014 (UTC)
| group8         = Actions
| group8class = sysop-show
| list8            =
: [[Special:Block/{{{1|{{PAGENAME}}}}}|block]]
: [[Special:Unblock/{{{1|{{PAGENAME}}}}}|unblock]]
: [[Special:Userrights/{{{1|{{PAGENAME}}}}}|flag]]
: [[Special:RenameUser/{{{1|{{PAGENAME}}}}}|rename]]
: [[Special:Nuke/{{{1|{{PAGENAME}}}}}|mass delete]]
: [[Special:GlobalBlock/{{{1|{{PAGENAME}}}}}|globally block]]
: [[Special:GlobalUnblock/{{{1|{{PAGENAME}}}}}|globally unblock]]
: [[Special:CentralAuth/{{{1|{{PAGENAME}}}}}|merge global account]]
: [[Special:GlobalBlockWhitelist/{{{1|{{PAGENAME}}}}}|disable global blocks locally]]
issue where it is only suppose to show if the viewing user is in the administrator usergroup. Defining the class for the group should define it for all components of the group. — {{U|Technical 13}} (etc) 12:00, 30 June 2014 (UTC)
I was merely trying to optimize WOSLinkers code. Using classes is not possible due to the gaps issue; it is not possible to hide an entire HTML table row using either class or style. The only way for that to work is to add rowclass/rowstyle. -- [[User:Edokter]] {{talk}} 12:44, 30 June 2014 (UTC)
Red information icon with gradient background.svg Not done for now: I see. It actually "can" be done using tables, but not everything is set in place for that. I'm guessing the best way for this to happen, is that the module should be rewritten to make use of divs instead of a table. This is not a project I would expect anyone else to undertake, and I've no time to start working on learning Lua to do it myself for at least a couple weeks. As such, I'm marking this as not done for now, but will ping the commenters of this page when I do have time and have a working sandbox/testcases version to get some consensus as to whether or not to switch to that version if no-one beats me to it. — {{U|Technical 13}} (etc) 13:34, 30 June 2014 (UTC)


I'm almost sure that the answer is no, but I wanted to clarify: If I'm using hlist class, do I need to use the {{nobr}} template for certain elements (like {{nobr|SomethingVeryLong-OtherLongPartOfElement}}). --Edgars2007 (talk/contribs) 15:10, 22 July 2014 (UTC)

You don't need to, and not really recommended, but you can use it for individual list items if absolutely necessary. -- [[User:Edokter]] {{talk}} 15:51, 22 July 2014 (UTC)
Thanks. --Edgars2007 (talk/contribs) 08:46, 23 July 2014 (UTC)