Module talk:Sidebar/Archive 1

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Archive 3

→

Archive 5

Glitch

I am aware of the glitch in folowing articles. Working on it... --Cool Cat ^{My Talk} 13:40, 15 July 2005 (UTC)

Fixed... kida. There is a big chunk of white space tho... :) --Cool Cat ^{My Talk} 13:51, 15 July 2005 (UTC)

Hmm

This seems to be getting used a lot for text that would be better off being integrated into the main text as a section or subsection. While this is an engaging layout tactic style in magazines and textbooks etc, I don't think it's useful for an encyclopedia article. — Matt Crypto 11:17, 31 March 2006 (UTC)

Please document this template

I can't find this template under Wikipedia:Template messages -- it needs to be there so people know about it. (If it's already there and I missed it, please feel free to break a piano over my head.) Also, it could do with being put into an appropriate template category. — Johan the Ghost _seance 09:58, 27 April 2006 (UTC)

Current status of template, and suggestions

So the template has been overhauled. That's a good idea, and I look forward to using it in future. I've got a few comments about the current direction:

The code currently uses the author's (IMO) excessively idiosyncratic syntax styling. This makes it rather difficult for other users to work on it. I'd really rather that the template adopted a more minimal approach, such as by stripping out the lavish embellishment of comment tags.
The default width doesn't match that of {{infobox}}. This makes stacking sidebars and infoboxen look less neat.
The parameter names are subtly different from {{infobox}} / {{navbox}} too. This makes it harder to pick the template up.

Thoughts? Chris Cunningham (not at work) - talk 11:13, 28 October 2008 (UTC)

Well, the "excessively idiosyncratic" styling is a consequence of my awareness of the differences between sidebars that use dividing lines, no dividing lines but headings with backgrounds, or nothing to indicate each section in a sidebar. I've been wondering whether it's worth setting up some default stylings within the Sidebar code to reflect this, i.e. something like sectstyle = divider-lines or = heading-backgrounds or = none. I imagine that might make the code more modular, i.e. easier to edit -- although most I also imagine most editors wouldn't want to edit the code itself but use the various styling parameters available.
I haven't checked, but I don't think there is a default width..?
Unintentional, so probably worth tweaking ("correcting"), although they were created with Navbox and its like in mind.

Sardanaphalus (talk) 13:00, 28 October 2008 (UTC)

I wasn't actually referring to the styling, but to the layout of the code itself: about a 30% overhead in whitespace, comment lines and indenting. by and large, WP code isn't indented, there are rules to when line breaks can be used without bleeding through to the output, and a comment line like
------------------------------- topimage --------------------------------
doesn't really tell any reader who is capable of parsing the code anything that they wouldn't be able to see themselves. I didn't want to remove this, but nor do I think keeping it is likely to attract others to edit it.
That's part of the problem. Editors shouldn't be expected to know to have to put width=22em if they want a sidebar to fit flush with infoboxen. Sensible defaults should be specified, even if the ability to override them is included.
See, for instance, "heading" versus "header", for instance, and the different definition of "title".

Chris Cunningham (not at work) - talk 13:13, 28 October 2008 (UTC)

Well, I find them useful (here and in other template code) as they make it easier to identify chunks of code quickly, especially when coming back to it after some time. I guess they're the coding equivalent of headings in sidebars themselves -- or, in your ideal world, would you want to be rid of those as well?
I think there's a fair number of sidebars where 22.0em would be too wide, e.g. to point to one I've seen recently, {{Culture of Poland sidebar}}. The Politics series sidebar templates and Political ideology templates use an inherited 18.0em. However, I suppose this default could be mentioned in the documentation and/or placed  next to the |style = entry in the "Full blank syntax" section, or in a separate section of its own?
My understanding is that "header" applies only to items at the top of a page/template/document/etc, whereas "heading" doesn't; hence "heading"s here as they can appear throughout the template. Not sure how "title" differs from its {{Navbox}} use..?

Sardanaphalus (talk) 14:45, 28 October 2008 (UTC)

I'm aware that we disagree here. The point is that on the whole more editors appear to contribute when the code is simpler, so in the interests of furthering participation in the use of the template is might be a gesture of good faith to adopt a simpler coding style in it.
For a sensible default to be useful it has to be a default, as in on. Infoboxen can override their widths too, but the point is thatby default they have a set identified width. 22em is also the default width of -small-classed navboxen and message boxes. it would be good to match that.
"Heading" and "header" are basically synonyms. In terms of what they do in code, they both put up a bold, centred line of text. There's little reason to give them different names.

Chris Cunningham (not at work) - talk 15:05, 28 October 2008 (UTC)

If it's the case that more people tend to be put off by headings and alignments than find them useful, then I suppose it makes sense to remove them. I have no idea whether or not that's true, though. If so, maybe it's because templates like this only tend to be edited by people who are relatively experienced at computer programming, unlike myself. My experience is that trying to find the start of a section of code, or the braces that mark the end of an {{#if:, etc, etc, can be time-consuming and frustrating in templates where there's little or no code spacing/formatting.
I think there are probably as many pages -- maybe more -- that include sidebars alone as pages that include sidebars and infoboxes, so I'm beginning to think that setting no default might be the most appropriate situation. 22.0em eats a fair way into the page -- especially in smaller windows/screens -- and would be wider than the majority of sidebars I've seen so far, so I'd say setting this width feels more like an exception than a good default.
Okay, by all means add "header" as an alternative parameter name, or make "heading" the alternative to "header". (Is it {{Infobox}} that uses "header"?)

Sardanaphalus (talk) 10:09, 29 October 2008 (UTC)

navigation boxes with common arguments?

I was just looking at some of the navigation box meta-templates, and it seems like each one uses different names for the arguments. This makes it much harder than it needs to be to change the style of a template. Specifically:

template:Navbox and template:navbox with collapsible groups seem to share common argument names

|group1 = 
|abbr1 = 
|list1

template:Sidebar uses totally different names

|heading1 = 
|content1 =

and template:Sidebar with collapsible lists uses yet another set of names (incompatible with either of the above).

|list1name  = 
|list1title = 
|list1 =

Several of the other parameters have different names as well.

Am I looking at the wrong templates? Is there another set of navigation metatemplates that is coordinated? Are there adapter templates that mask all this in a nice way? (If we can't change the base templates, one can build template(s) to tidy this up, but no sense in doing that if it is already done.)

I was looking at this while looking at a template that has both a horizontal and a vertical version (which people are trying to keep synchronized manually); somebody asked if there wasn't a way to use one template and two different views. I think I see how to do that, but didn't reckon with having to change the names of the parameters in order to do it. But perhaps there is already a standard way to do what I want without messing with these templates?

By the way, why is it "navbox with collapsible groups" and "sidebar with collapsible lists"? Again, consistency would be nice. Thanks Zodon (talk) 07:41, 30 October 2008 (UTC)

And now I see template:infobox uses yet another set of names

|header1 =

|label1 =

|data1 =

Admitedly, it isn't a navigation template, but still. I know, "consistency is the hobgoblin of small minds." Zodon (talk) 07:52, 30 October 2008 (UTC)

I agree and have probably unwittingly added to the potential for confusion; see the thread above. I imagine the most robust solution is to include alternative parameter names in the code, while trying to promote a particular set. I'll try to come up with a suggested set in the near future. I'm not sure whether or not there are any "adapter templates", but if there are, I wonder whether they're a good long-term solution. Meanwhile, some kind of automated reformatting between a navbox (horizontal) and sidebar (vertical) version of a template is something that's crossed my mind too, although I haven't yet tried imagining how tricky it might or might not be.
Currently, I think "Navbox with collapsible groups" might be a misnomer -- I use the "Navbox with collapsible sections" redirect -- and "Sidebar with collapsible lists" rather than "...collapsible sections/groups/something" came about because it uses {{Collapsible list}} -- but that, I guess, could be renamed to the more general "Collapsible section", thereby implying "Sidebar with collapsible sections". The use of {{Collapsible list}} also explains the use of the listNname, listNtitle, etc parameter names in "Sidebar with collapsible lists". Sardanaphalus (talk) 20:00, 31 October 2008 (UTC)

Thanks. If it helps any, I built a little experiment to take a template contents and format it either as a sidebar or as a navbox depending on parameters. (The discrimination template/sidebar are what got me thinking about this, so that is the example code I used.)

In the process I made copies of sidebar and sidebar with collapsible whatevers, and converted them to using the same main arguments as navbox. (I used the navbox parameter names just because that meant the fewest templates to adapt. They seem good enough, but I haven't formed an opinion if any set of terms appeals more.)

I also made a few other tweaks - like adding the border=none behavior from navbox, and creating "sidebar subgroups" (analagous to navbox subgroups).

The code is pretty rough, but you can find it with a (minimal) explanation linked to from my user page user:zodon#Navigation template - Navbox/Sidebar. I mention it in case there are any ideas/additions there that might want to include in the code here. Zodon (talk) 08:43, 2 November 2008 (UTC)

I'm intrigued by user:zodon#Navigation template - Navbox/Sidebar and will take a closer look once the current {{Sidebar}} work starts winding down. Thanks for the link. Sardanaphalus (talk) 03:23, 7 November 2008 (UTC)

tnavbar=none broken?

If I set tnavbar=off it hides the navbar. Setting tnavbar = none doesn't seem to work (it still shows the navbar).

The code doesn't look right to me - seems to be comparing tnavbar to a variable named none (with a default value of off), but I am not up on all the intricacies and tricks to be sure what it is doing.

Also, if I turn off the tnavbar, it should also suppress the separator line above the tnavbar. Zodon (talk) 05:14, 31 October 2008 (UTC)

Thanks for spotting. I've clarified the code and documentation to accept only "none". You're probably correct about omitting the line along with the Tnavbar, so I'll look into that -- do you have any examples to hand? Sardanaphalus (talk) 20:11, 31 October 2008 (UTC)

The now-upgraded {{Sidebar}} now handles both "none" and "off" (using #switch:). Sardanaphalus (talk) 13:50, 12 November 2008 (UTC)

Code revamp, and discussion

I've started a sandbox page at {{sidebar/sandbox}} to play with the future of this template.

As mentioned in threads above, the template arbitrarily deviates from the syntax of other meta-templates. In addition, its layout differs to that of its closest cousin display-wise, {{infobox}}, in that it uses "exttitle" where "title" is used in {{infobox}}, adds a "topimage" at the start of the table, and uses "title" for what {{infobox}} calls "above". IMO the layout should be normalised against that of {{infobox}} before it is so widely used that updating existing deployments becomes impossible. This will entail manually updating those deployments against the following syntax:

{{{exttitle}}} -> {{{title}}}
{{{topimage}}}, {{{topimagecaption}}} and {{{title}}} -> {{{above}}}. This will require more attention than a simple copy-paste.
{{{headingX}}} -> {{{headerX}}} everywhere
{{{contentX}}} -> {{{dataX}}} everywhere

There's also a rather ridiculous level of customisation allowed currently, such as per-entry style overrides. I'm not sure that allowing these is a good idea, as it could be seen to encourage the styles to be overridden at will.

Anyway, I'd appreciate any thoughts on this. The next step will be to temporarily allow the {{sidebar}} code to deal with legacy naming while the existing deployments are fixed, then to update the existing deployments, then to remove the compatibility code. Chris Cunningham (not at work) - talk 12:43, 3 November 2008 (UTC)

The next step, I feel, is a little further consideration. I'm not sure that following {{Infobox}} is the best way to proceed; in fact, {{Infobox}} and possibly even {{Navbox}} might also benefit from some revision.
1. I agree that exttitle is not the most intuitive name for a parameter; outertitle has just occurred to me as a possible improvement. However, renaming it title seems odd when the majority of sidebars I've passed by have their titles inside rather than outside the sidebar panel.
2. Don't understand how bundling topimage/topimagecaption and title together as above is wise, since images above a sidebar's title (that is, a title inside the sidebar) are infrequent and above doesn't seem to be intended for images in both Infobox and Navbox. Furthermore, unlike Infobox, above doesn't appear to be intended for title-like use in Navbox. Instead, it looks as though the most common positions for titles in infoboxes and sidebars are, respectively, outside and inside their panels, so perhaps it would make more sense to set up the use of above, title, outertitle and innertitle (name suggestions) across the three basic templates thus:

{{Navbox            {{Infobox            {{Sidebar
|name  =            |name  =             |name     = 
                    |title =             |outertitle = 
                                         |pretitle = 
|title =            |innertitle =        |title    = 
|above =            |above =             |above    =

Infobox's innertitle and above would be equivalent. Following from the above, Navbox and Sidebar offer two image positions -- image/imageleft and image/topimage, with the more commonly-used position (righthand side or below title, respectively) taking the simpler name -- whereas Infobox looks as if it offers one, above everything else within the infobox. Perhaps it might be worth revising it to offer two as well, reserving image for the position above everything else within the infobox:

{{Navbox            {{Infobox            {{Sidebar
|name  =            |name  =             |name     = 
                    |title =             |outertitle = 
                                         |topimage [or upperimage?] = 
                                         |pretitle = 
|title =            |innertitle =        |title    = 
|image =            |image =             |image    = 
|imageleft = 
|above =            |above =             |above    =

3. headingX rather than headerX seems a more appropriate default name to me here, as I've seen "header" being used to identify whatever's at the top -- and only the top -- of a page (e.g. in word-processing). The "headers" used in Infobox and potentially in Sidebar, however, can appear throughout. (headingX could even be set up for Navbox as an alternative to doctoring listX or using {{Navbox with collapsible sections}}..?) I guess headerX could be retained as equivalent to headingX (or vice versa).

4. I suggest contentX as a more non-technical, user-friendly and open-ended description. For instance, the discussions I've seen about templates and their... contents seem to use "content" or "contents" more frequently than "data".

Lastly, I don't think customization is encouraged if the possibility of and options for it are kept toward the end rather than the beginning of templates' documentation. I'd say the degree to which it may or may not be a good thing is moot given the regular (if not frequent) occurrence of content that would leave gaps, extra lines, under or over-distinguished text and other such side-effects if it were left formatted as default.

Sardanaphalus (talk) 00:42, 5 November 2008 (UTC)

If modification of the parameters for Infobox and/or navbox is to be considered, then it seems like this discussion needs input from/connection to those templates. (at least a pointer to this discussion from talk:infobox and talk:navbox), possibly discussion should occur in some more widely read forum - since all those using infobox and navbox would also be affected.

Is it even reasonable to consider wholesale change to the arguments to navbox or infobox? (i.e. how many uses would have to be fixed)? I am not objecting to change, just seems like a big thing and a whole lot of work, so may needs a broader consensus. Zodon (talk) 06:12, 5 November 2008 (UTC)

I don't think a wholesale renaming of Infobox and especially Navbox parameters is necessary, just the inclusion of the alternative names in their code for use from now onwards. Meanwhile, there could always be a gradual renaming, whether organized or as and when existing templates are revisited. One correction to Navbox is outstanding: titlestyle currently acts as if titlebarstyle, i.e. it affects the formatting of the v·d·e and [show/hide] links in the titlebar as well as the title itself.

I've reformatted the naming suggested above to show equivalent parameters by row. Here's a basic Navbox, Infobox and Sidebar which try to indicate these equivalences:

Navbox

Infobox

  {{Infobox
  |name  = Infobox
  |width = 17.0em;
  |title = title ''(outertitle)''
  |above = <div style="padding-bottom:0.5em; font-weight:normal;"><small>[implement ''top/upperimage''..?]</small></div> above ''(innertitle)''
  |image   = image ''(lowerimage)''
  |header1 = header1 {{nobold|''(heading1)''}}
  |label1  = label1 {{nobold|''(group1)''}}
  |data1   = data1 ''(content1, list1)''
  |label2  = label2 {{nobold|''(group2)''}}
  |data2   = data2 ''(content2, list2)''
  |header3 = header3 {{nobold|''(heading3)''}}
  |label3  = label3 {{nobold|''(group3)''}}
  |data3   = data3 ''(content3, list3)''
  |label4  = label4 {{nobold|''(group4)''}}
  |data4   = data4 ''(content4, list4)''
  |data5   = ''etc''
  |below = below
  }}

Sidebar

Thinking of the ability to switch between a horizontal (Navbox) and vertical (Sidebar) template design, perhaps Navbox, Infobx and Sidebar should all use the same parameter names in their code but with the corresponding established names included as alternatives, i.e.


ESTABLISHED USE             IN SHARED CODE            ALTERNATIVES

{{Infobox
|name  =                    {{{name}}} 
|title =                    {{{title1}}}              {{{outertitle}}}
|image =                    {{{image1}}}              {{{topimage [upperimage?]}}}
|above =                    {{{title2}}}              {{{innertitle}}}
|[lowerimage =]             [ {{{image2}}} ]          [ {{{lowerimage}}} ]
|headerX =                  {{{headingX}}}            {{{headerX}}}
|labelX =                   {{{labelX}}}
|dataX =                    {{{dataX}}}               {{{contentX}}}
|below =                    {{{below}}}
}}

{{Navbox                  
|name  =                    {{{name}}}
|title =                    {{{title2}}}              [ {{{innertitle}}} ]
|above =                    {{{above}}}
|image =                    {{{image1}}}
|imageleft =                {{{image2}}}
|groupX =                   {{{labelX}}}
|listX  =                   {{{dataX}}}               {{{contentX}}}
|[headingX =]               [ an amended {{{dataX|{{{contentX|{{{listX}}}}}}}}}...? ]
|below =                    {{{below}}}
}}

{{Sidebar
|name  =                    {{{name}}}
|outertitle =               {{{title1}}}
|topimage [upperimage?] =   {{{image1}}}
|pretitle =                 {{{pretitle}}}
|title =                    {{{title2}}}              {{{innertitle}}}
|image =                    {{{image2}}}              {{{lowerimage}}}
|[above =]                  [ {{{heading1}}} ]        [ {{{header1}}} ]
|headingX =                 {{{headingX}}}            {{{headerX}}}
|contentX =                 {{{dataX}}}               {{{contentX}}}
|below =                    {{{below}}}
}}

In other words, the fundamental parameter names that would be common to all three templates Navbox/Infobox/Sidebar and their variants would be name, name, title1, title2, image1, image2, above, headingX, labelX, dataX, below (accompanied by corresponding ...style and some ...class parameters). This should render any need to choose between "heading"/"header" or "data"/"content" unnecessary.

I'll also throw in here my feeling that {{Sidebar}} might benefit from changing its current default of using dividing lines to one without these lines, with {{Sidebar with dividers}} and {{Sidebar with heading backgrounds}} then used to feed it formatting that, respectively, includes these lines or headings on backgrounds. These two formats (with dividing lines or with headings on backgrounds) seem to be the two major ways in which sidebars with more than one section are presented.

Sardanaphalus (talk) 16:50, 5 November 2008 (UTC)

Have begun work on a plainer basic Sidebar here with a view to creating "Sidebar with dividers" and "Sidebar with backgrounds" as described above. Tests are here. Sardanaphalus (talk) 03:26, 7 November 2008 (UTC)

Have now deployed plainer {{Sidebar}} with {{Sidebar with dividers}} and {{Sidebar with heading backgrounds}} derived from it. Sardanaphalus (talk) 13:08, 12 November 2008 (UTC)

The treatment of "above" for sidebar isn't quite clear. Treating it as heading1 will just make the code less clear. Seems like creating the above parameter, by duplicating the headingn code and changing the name to "above," would make it easier to read (rather than having to shift everything so heading1 -> heading2, ...) (i.e. unless I am not following the table above, the proposed IN [SHARED] CODE version for sidebar should say headingX+1 rather than headingX, and likewise for dataX. (I am suggesting it should say above in the code as well). Otherwise cases where somebody uses both above and heading1 (style1, etc.) won't work right.
- It might also make the even/odd style harder to manage.
The note in the navbox above that says "suggestion: using headingx as alternative to using listx for ..." doesn't make sense to me, nor does the headingx use in the established use/IN [SHARED] CODE box.
- If one wants to be able to switch between navbox and sidebar, then navbox headingX would be same as groupX/labelX.
- If one has a subgroup level that will use labels above the data, then one would use a sidebar (that is what a sidebar is for). (If one wants to alternate heading locations freely, then one does the heading in the list item, as is currently done.) Zodon (talk) 08:10, 9 November 2008 (UTC)

Having just deployed the plainer {{Sidebar}} and its two preset formats {{Sidebar with dividers}} and {{Sidebar with heading backgrounds}}, I agree and will amend them accordingly.
Yes, it's a bit cryptic (sorry). What I'm think of is this kind of situation:

Hope that helps. Sardanaphalus (talk) 13:08, 12 November 2008 (UTC)

What I was trying to say is that for navbox, headinX should map to labelX (in the inCode version).

Looking back I see my comment was not clear. Sorry. It isn't that it wasn't clear what was meant, but that there is a problem with doing it that way. Specifically, if headingx maps to datax in navbox, then when I convert a sidebar to a navbox, it will look the same as it did when it was a sidebar (the heading will still be above the data.) What should happen is that when I convert a sidebar to a navbox, the headings will be beside the data (i.e. the headingx maps to groupx (or Labelx), the group labels).

(Well actually it is more complex than that, since if headingx mapped to datax it would overwrite datax. But the point is even if you insert extra heading bits to solve that, when you converted a sidebar to a navbox it will still look like a sidebar, unless you map headingx to labelX.) Zodon (talk) 09:40, 13 November 2008 (UTC)

width

Should sidebar have a width parameter? Seems likely to be used frequently. Sure you can do it with styles, but with a parameter it could be made to dissapear more naturally when redone as a navbox (i.e. just ignore it.) Zodon (talk) 09:35, 9 November 2008 (UTC)

I guess I was assuming the conversion of a Sidebar (of width:anything) to a Navbox would be to a Navbox of width:100%. If a width other than 100% is needed or desired, though, perhaps a separate width parameter will be needed. I haven't thought that far yet! Sardanaphalus (talk) 13:08, 12 November 2008 (UTC)

I was thinking that if sidebar had a width parameter (rather than people having to use the a css style for width), then when one went over to a navbox, the width parameter could just be ignored. Having it as a parameter makes ignoring it easy, as compared to if it is in a style parameter someplace. (Or maybe handle by just overriding the width specified in style.) Zodon (talk) 08:31, 13 November 2008 (UTC)

collapsing

How do we handle collapsible sidebars?
- Just making a plain sidebar collapse, the hide/show part for the whole sidebar seems to be missing.
- With all the stuff before the title it isn't obvious how this should work. Should it just show the title and when you uncollapse it the pre-title material pops out as well as the rest?

If we consider the parameters to {{template:navbox with collapsible groups}}, then in that case we add:


selected = 
abbrn = 
staten = [autocollapse, uncollapsed, collapsed, plain, off]

imagen = (This is passed as image parameter to n'th navbox, so goes on the right)
imageleftn = (left)

Since imagen is used in the "with collapsible groups" version, the use of image1, image2 in the code, as indicated above, might be slightly confusing (perhaps imagea/imageb; imagebefore/imageafter; preimage/postimage; ?).

Again, you're ahead of me here, so right now I'm not sure what might work best. My instinct is to say that whatever remains visible in the Sidebar (with collapsible lists/groups/sections) even when everything else collapsed is what should remain visible in the Navbox (with collapsible groups/sections). But, as above, I need to think it through. Sardanaphalus (talk) 13:08, 12 November 2008 (UTC)

[This also made me notice] a bit of an asymmetry in the images. (if read in english reading order)
- navbox "title - above - imagea - body - imageb - below"
- sidebar "imagea - title - above (presumably) - imageb - body - below"
- So in navbox the images bracket the body, whereas in sidebar they bracket the title. (Not having seen how they are used I can't comment on the desirability of either style - presumably one can always stick an image in the below item if want one after the body.)
One control that is missing from navbox with collapsible groups is a way to change the default state for all groups at once. (Like liststyle vs. listnstyle).
- Useful if you want to have the whole navbox displayed (for instance, have it totally expanded on the template page, but let it collapse on pages that use it.)
- State is already used to control the expansion of the navbox as a whole, so can't use that.
- This could of course be over-ridden on an individual basis by staten.
- I realize more apropos of that template, but mention here since assigning names. Zodon (talk) 09:35, 9 November 2008 (UTC)

Yes, I'm seeing the image slots above and below a title in a Sidebar (or both below an outertitle) as corresponding to the image slots to the left (rare) and right (usual) in a Navbox.
You mean like {{... |expanded=all}} for a Sidebar with collapsible lists? If so, I agree and something else to add to the to-do list. Sardanaphalus (talk) 13:08, 12 November 2008 (UTC)

v t e title
above
group1	list1	image
group2	list2
currently list3 -- *but suggest heading3/header3* more apt, as that's how it's being used...**
group4	...i.e. headingX/headerX (with heading/headerstyle) in place of listX produces a subheading/subheader at position X. It might be necessary to use headingX/headerXs rather than listXs here so that switching between a Navbox and Sidebar format works correctly..?
etc
below