Template talk:Navbox

From GodWiki
Jump to: navigation, search

Wheel reinvention?

@Djonni: I just have to ask — it looks like you're writing this from scratch? Curious why you picked that route, rather than starting with something like en.wikipedia's Template:Navbox that's the product of nearly 10 years of development time spent thinking about, solving, iterating on, and resolving all of the same issues. I don't even want to think about how much extra work Template:Infobox would've required if I'd decided to write it from scratch. Sure, I had to make a lot of adjustments, particularly to account for the fact that we don't have access to any CSS classes for styling, but even then the existing structure of the code made it way easier to work out the right way to address that stuff.

The biggest obstacle, really, was the fact that the adjustments I did have to make had to be done in 99 different places, since it supports that many rows. (Which is far more than we'll ever need, of course, but I figure having support for more features than we could ever possibly use means that we'll never have to worry about it failing to meet the needs we do have.) Anyway, like most templates — glorified mail merge on steroids — supporting lots of rows just means long-but-repetitive, so fixing the whole thing up was just a matter of pulling it into an offline text editor, doing a couple of quick regular expression edits across the entire file, and then pasting the modified code back into the online editor.

*shrug* It's entirely up to you how you approach it, of course, and it seems like it's coming along quickly anyway so who am I to argue with success? -- FeRDNYC (talk) 11:27, 1 December 2018 (UTC)

Well, I started off by looking at the Wikipedia solution, and used it as a frame for my thinking, but it has dependencies that I was fairly sure (but not certain) we don't meet here, and supported things I didn't see a need for, and didn't support things I thought were worth supporting. When I looked at it I felt like the amount of work to migrate it wasn't necessarily less than the work to just write it from scratch, and when I added the autodidactic value of starting from scratch it seemed an easy choice.
You beat me to the punch, in fact — I was going to use it in User:Djonni/Sandbox and ask you for comments! :) This was obviously a template intended for use in the early days of the GodWiki, and was given up on (out of frustration, presumably; perhaps from an attempt to copy it from That Other Wiki!). I think having this available will help prevent people like me from building monstrosities, and make it more reasonable to add more examples like Template:Navboxdragons and Template:Navboxursidae which I, for one, really like seeing.
I should have time today to put some more use cases together on my sandbox, which may lead to obvious refinements here. I also want sure if I should bother trying to make it able to handle sub-groupings as we have in Template:Navboxbosses (Lvl 1-3), but I'm doubtful it would be worthwhile. (Although perhaps it wouldn't be so hard to make a {{Navbox/Subtable}} for this. I dunno.) -- Djonni (talk) 12:48, 1 December 2018 (UTC)
I'm in the middle of painting a bathroom right now, but one quick suggestion on the Sandbox page: Especially because the spacing under the old templates is so weird, it'd be helpful to put a level 2 section heading before each pair, listing the name of the Navbox template that's about to be compared. That'd make those comparisons much easier to follow.
────────────────────────────────────────────────────────────────────────────────────────────────────
Tick.png Done Good thought. Headers added, and preformatted codeblocks for the novel examples for additional clarity. -- Djonni (talk) 09:53, 3 December 2018 (UTC)
Speaking of Navbox template names, I really want to murder this terrible convention of naming the templates "Navboxwordsallruntogether", and maybe a {{Navbox}} reimplementation is the perfect opportunity to do that. The new versions could be implemented as e.g. {{Navbox towns}} and {{Navbox bosses}} the way they always should've been, and then when they're ready to go live {{Navboxtowns}} and {{Navboxbosses}} could just be made redirects to the new templates under the new (official/canonical) names. Andthenwewon'thavetoreadthingslikethisanymore. -- FeRDNYC (talk) 08:58, 3 December 2018 (UTC)
Heh, the existing navbox names are pretty awful to parse. The navboxnames are dead, long live the navbox names!
Have fun painting the bathroom! -- Djonni (talk) 09:53, 3 December 2018 (UTC)
Fortunately it was only a bathroom, so it didn't require any sort of miracles. But, yay for being done with that. -- FeRDNYC (talk) 12:51, 5 December 2018 (UTC)

Implementation of subgroups

I also want sure if I should bother trying to make it able to handle sub-groupings as we have in Template:Navboxbosses (Lvl 1-3), but I'm doubtful it would be worthwhile. (Although perhaps it wouldn't be so hard to make a {{Navbox/Subtable}} for this. I dunno.)

Or, make the template recursive. That's how Mediawiki did it in theirs.

I think it seems worthwhile to support that, since as you say we already have a template that uses it. So, there's a demonstrable need.

If you think about it, though, sub-groupings are really just sub-navboxes, and the only thing keeping {{Navbox}} from being able to recurse into itself is the forced {{{title}}}. Take that out (or make a |subtable=1 disable it), and it should hopefully only take some minor adjustments to get sub-groupings to work by using {{Navbox|listN={{Navbox|subtable=1|...}}}}.

For the table below, I took the HTML output for your reimplemented Auras navbox, added an additional row, set Pantheons as the header, and dropped the entire HTML content of your reimplmented Pantheons navbox into the <td>...</td>. Then I made only the following changes:

  1. Removed the <tbody>...</tbody> tags since they flummox MediaWiki's HTML parser (heh).
  2. Removed some "white-space: nowrap" styles that caused the table to stretch way too wide.
  3. Removed font-size: 85% from the <td>...</td> containing the inner table, since it's set again on all of the cells there and the font reduction would end up being doubled
  4. Removed the inner table's mw-collapsible class and styled it margin: 0
  5. Deleted the top row (title) from the inner table completely
  6. Added styles like border; none; border-spacing: 0; padding: 0; in a bunch of places around the added row / inner table.
<a class="mw-collapsible-text">Collapse</a><a href="/Auras" class="mw-redirect" title="Auras">Auras</a>
Standard Auras <a href="/Aura_of_abstinence" title="Aura of abstinence"> Abstinence</a> • <a href="/Aura_of_audibility" title="Aura of audibility"> Audibility</a> • <a href="/Aura_of_baiting" title="Aura of baiting"> Baiting</a> • <a href="/Aura_of_bliss" title="Aura of bliss"> Bliss</a> • <a href="/Aura_of_concussion" title="Aura of concussion"> Concussion</a> • <a href="/Aura_of_confusion" title="Aura of confusion"> Confusion</a> • <a href="/Aura_of_curiosity" title="Aura of curiosity"> Curiosity</a> • <a href="/Aura_of_hoarding" title="Aura of hoarding"> Hoarding</a> • <a href="/Aura_of_huckstering" title="Aura of huckstering"> Huckstering</a> • <a href="/Aura_of_hunting" title="Aura of hunting"> Hunting</a> • <a href="/Aura_of_immortality" title="Aura of immortality">Immortality</a> • <a href="/Aura_of_pacifism" title="Aura of pacifism"> Pacifism</a> • <a href="/Aura_of_rage" title="Aura of rage"> Rage</a> • <a href="/Aura_of_reviving" title="Aura of reviving"> Reviving</a> • <a href="/Aura_of_totemism" title="Aura of totemism"> Totemism</a> • <a href="/Aura_of_trail" title="Aura of trail"> Trail</a>
Event Auras <a href="/Aura_of_censorship" class="mw-redirect" title="Aura of censorship"> Censorship</a> • <a href="/Aura_of_overcensorship" title="Aura of overcensorship"> Overcensorship</a> • <a href="/Aura_of_spookiness" title="Aura of spookiness"> Spookiness</a> • <a href="/Aura_of_%E2%96%88%E2%96%88%E2%96%88%E2%96%88%E2%96%88%E2%96%88%E2%96%88%E2%96%88%E2%96%88%E2%96%88" title="Aura of ██████████"> ██████████‎</a>
Pantheons
Long Term <a href="/Pantheon_of_Gratitude" title="Pantheon of Gratitude"> Gratitude</a> • <a href="/Pantheon_of_Might" title="Pantheon of Might"> Might</a> • <a href="/Pantheon_of_Templehood" title="Pantheon of Templehood"> Templehood</a> • <a href="/Pantheon_of_Gladiatorship" title="Pantheon of Gladiatorship"> Gladiatorship</a> • <a href="/Pantheon_of_Storytelling" class="mw-redirect" title="Pantheon of Storytelling"> Storytelling</a>
Short Term <a href="/Pantheon_of_mastery" title="Pantheon of mastery"> Mastery</a> • <a href="/Pantheon_of_Construction" title="Pantheon of Construction"> Construction</a> • <a href="/Pantheon_of_Taming" title="Pantheon of Taming"> Taming</a> • <a href="/Pantheon_of_Survival" class="mw-redirect" title="Pantheon of Survival"> Survival</a> • <a href="/Pantheon_of_Savings" class="mw-redirect" title="Pantheon of Savings"> Savings</a> • <a href="/Pantheon_of_Creation" class="mw-redirect" title="Pantheon of Creation"> Creation</a> • <a href="/Pantheon_of_Destruction" class="mw-redirect" title="Pantheon of Destruction"> Destruction</a> • <a href="/Pantheon_of_Arkeology" title="Pantheon of Arkeology"> Arkeology</a> • <a href="/Pantheon_of_Catch" class="mw-redirect" title="Pantheon of Catch"> Catch</a> • <a href="/Pantheon_of_Duelers" title="Pantheon of Duelers"> Duelers</a>
Guild <a href="/Pantheon_of_Unity" title="Pantheon of Unity"> Unity</a> • <a href="/Pantheon_of_Popularity" title="Pantheon of Popularity"> Popularity</a> • <a href="/Pantheon_of_Duelery" title="Pantheon of Duelery"> Duelery</a> • <a href="/Pantheon_of_Adventure" class="mw-redirect" title="Pantheon of Adventure"> Adventure</a>
Former <a href="/Pantheon_of_Greed" class="mw-redirect" title="Pantheon of Greed"> Greed</a> • <a href="/Aggressiveness" title="Aggressiveness">Aggressiveness</a>

Ignore the crazy content since the links don't get parsed right. But structurally, except for the infuriating double borders (on only three sides!) that I haven't quite figured out how to get rid of yet, it's really almost exactly what we'd want. So, hopefully that approach should be viable to do sub-groupings. -- FeRDNYC (talk) 12:51, 5 December 2018 (UTC)

Enh, actually, I take that back some. Until they converted wikipedia:Template:Navbox to use Lua, they did recommend their own wikipedia:Template:Navbox subgroup, which is only now deprecated because it doesn't use the Lua code at all. (And, presumably, recursion is far easier to implement in Lua.) So a version of it from around 2013 may indeed be informative regarding implementation. -- FeRDNYC (talk) 15:06, 5 December 2018 (UTC)
Mmm, okay, if you think it's worth it (and it seems like you're right) I'll take a good look at the Wikipedia solution. Which do you think is more sensible, {{Navbox subgroup}} or {{Navbox/subgroup}}? (Thanks again for the benefit of your insight!) -- Djonni (talk) 18:10, 5 December 2018 (UTC)
I actually have a definitive answer for that, with reasons why it's not arbitrary. You're of course free to do it however you prefer, and from a technical standpoint it absolutely does not matter in the slightest, but here's my approach to that question/decision:
In my view, even/especially in the Template namespace, subpages are for use internally by the parent. Like, {{Infobox}} has {{Infobox/row}} and {{Infobox/image}} which it calls repeatedly within its own code. But, when a template is available/implemented for use by callers of other templates (even if they're other templates themselves) then it should be a separate Template-namespace entity of its own.
The reason, primarily, is independence. If {{Infobox}} is moved, its subpages have to be moved with it. It won't function without them. (And all of the transclusions of the subpages would be edited, which is easy since they're all in the same parent template.) But {{Navbox subgroup}} could potentially be used with lots of navbox meta-templates of different types, and its transclusions will appear all over the Template namespace. Even moving {{Navbox}} (for whatever reason) doesn't force any changes to {{Navbox subgroup}}, nor to any of its callers. Even though the two templates are meant to be used in concert, they're not actually interdependent in reality. -- FeRDNYC (talk)`
Makes perfect sense. I look forward to seeing how much fiddling with the inline CSS it'll take! I'll get started soon -- Djonni (talk) 09:24, 7 December 2018 (UTC)
Mmm, I was going to mention — wikipedia:Template:Navbox, even when it was written in wikitemplate code, always output HTML table syntax directly, instead of using wikitable syntax. I have a feeling that was done to get access to applying CSS (classes, in their case, but it's equally true for inline styles) at more and different levels than is possible with wikicode, where (for instance) it's impossible to style a row the way you can with <tr style="">...</tr>. So, that's something at least worth considering. There really is no strong advantage to using wikitable syntax, in the context of a {{Navbox}} meta-template, since the callers of the template won't see the syntax either way, it's not their concern. -- FeRDNYC (talk) 10:01, 7 December 2018 (UTC)
Alright, good point, and shouldn't be too much trouble to do 👍 -- Djonni (talk) 10:17, 7 December 2018 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Well, taking a good look at the last pre-Lua implementation of wikipedia:Template:Navbox, and similar with wikipedia:Template:Navbox subgroup, it actually is recursive. Navbox subgroup calls Navbox with a subset of supported parameters and some specific styling defaults. The more I think about it the more sensible this is anyway, as a decision to change styles, colours, what have you in {{Navbox}} could easily neglect to update the same in {{Navbox subgroup}}, and lead to some weird mismatching.

The relevant version of wikipedia:Template:Navbox is real dense, but it seems to use nested <td style="padding: 0px;"><div style="padding: 0em 0.25em">...</div></td>, and switches that apply classes we don't have (navbox-subgroup, navbox-inner, etc), so it's pretty opaque how the various paddings are supposed to wash out. For the purposes of our simpler needs, I think the least troublesome approach may be to just use a parameter |listn-is-subgroup=yes to switch padding off in the container cell, and add a |subgroup=1 passed from {{Navbox subgroup}} to switch borders and text-size:85% off. That's what I'll try as a first iteration, anyway, and see how it goes. --Djonni (talk) 16:51, 8 December 2018 (UTC)

Okay, this should be Tick.png Done now, but I had a lot of interruptions and it's late so I'll finish testing etc in the morning! -- Djonni (talk) 20:41, 8 December 2018 (UTC)
Okay, I'm completely stumped by why I'm not able to conditionally pass-through the part-background parameters from {{Navbox subgroup}} to {{Navbox}}. There seems to be some quirk in template parameter parsing that I'm just missing.
|{{#if: {{{above-background|}}}|above-background = {{{above-background}}}}} seems to behave as expected according to Special:ExpandTemplates, producing just | when {{{above-background}}} is empty/undefined, and |above-background = {{{above-background}}} when it is non-empty. But then {{Navbox}} acts as if the parameter is undefined, converting {{{above-background|default}}} to default. I've tried every variation I could think of to no avail.
So as a hacky work-around I'm simply adding a background: field to the relevant part-style definitions, and call {{Navbox subgroup}} functionally complete. If you know what's up with the parameter parsing, you're welcome to un-hack my hack :) -- Djonni (talk) 13:11, 9 December 2018 (UTC)
I don't think that's possible, if I'm understanding what you want to do correctly. The wikicode parser isn't reentrant — it parses markup and templates as it encounters them, and since the {{Navbox subgroup}} will be parsed in the middle of parsing the outer structure — whether it's a template transclusion (in this case {{Navbox}}), or a wikitable, or whatever — it can't output anything that would alter that structure. Whatever it outputs is going to be dumped into the current cell of the table, or the current parameter of the transclusion, as-is, and can't break outside of that "box" in the parser.
IOW, you can't build a transclusion out of transclusions, because the outer transclusion will be parsed (or, parsing will start) before any transclusions inside it, not after they're completed. It doesn't know enough to start over parsing {{Navbox}} after expanding all of the transclusions inside it (reentrance), which is what it would have to do for those inner transclusions to modify the outer one. -- FeRDNYC (talk) 14:03, 9 December 2018 (UTC)
Ah, yeah, I realise that. What {{Navbox subgroup}} does is transclude a new {{Navbox}} to make a nested table in the cell, and so if I set {{{Navbox subgroup|group1-background=white}} for the first group header in the subgroups, I simply want that child transclusion to know {{Navbox|subgroup=yes|group1-background=white}}. I coloured some of the subgroup cells in the last example on {{Navbox/Documentation}}, to see what I mean. But, nonetheless, it's pretty moot since it's working using another method :)
It remains to tidy up the docs, and write documentation for using subgroups, but otherwise I'm happy for this to graduate out of testing into use, unless you see any impediment. -- Djonni (talk) 14:22, 9 December 2018 (UTC)

What {{Navbox subgroup}} does is transclude a new {{Navbox}} to make a nested table in the cell, and so if I set {{{Navbox subgroup|group1-background=white}} for the first group header in the subgroups, I simply want that child transclusion to know {{Navbox|subgroup=yes|group1-background=white}}.

The only way I know of to do that is to have {{Navbox subgroup}} transclude {{Navbox}} like this:
{{Navbox|subgroup=yes
|group1-background={{#if:{{{group1-background|}}}|{{{group1-background}}}|}}
|group2-background={{#if:{{{group2-background|}}}|{{{group2-background}}}|}}
|...}}
Repeated for every possible parameter that might need to fall through. Otherwise, you hit the same issue of reentrance — the transclusion of {{Navbox}} has to be structurally complete independent of any inner code, because that code isn't run until it's in the middle of being parsed. The only thing the inner code can do is determine the nature of the parameter values that it works with — the structure of the transclusion itself can't be generated dynamically.
That was the issue with my original idea about rewriting {{Pet}} as a "proxy" call to {{Monster|pet=yes|...}}, and why I quickly backed down from that idea. (I got the pseudosyntax completely wrong, there, but the issue was the same.)
It's also why {{Infobox}} uses {{Infobox/row}}, and the meat of it looks like this:
{{Infobox/row
 |header={{{header1|}}} |headerstyle={{{headerstyle|}}}
 |label={{{label1|}}}   |labelstyle={{{labelstyle|}}}
 |data={{{data1|}}}     |datastyle={{{datastyle|}}}
 |class={{{class1|}}}   |rowstyle={{{rowstyle1|}}}
 |rowlabelstyle={{{rowlabelstyle1|}}}
 |rowdatastyle={{{rowdatastyle1|}}}
}}{{Infobox/row
 |header={{{header2|}}} |headerstyle={{{headerstyle|}}}
 |label={{{label2|}}}   |labelstyle={{{labelstyle|}}}
 |data={{{data2|}}}     |datastyle={{{datastyle|}}}
 |class={{{class2|}}}   |rowstyle={{{rowstyle2|}}}
 |rowlabelstyle={{{rowlabelstyle2|}}}
 |rowdatastyle={{{rowdatastyle2|}}}
...and so on another 97 times. (I was wrong about the {{#if...}}, you don't have to bother with that since you're going to be passing in an empty parameter anyway for the unset case, so the inner template needs to be able to handle that regardless.)

It remains to tidy up the docs, and write documentation for using subgroups, but otherwise I'm happy for this to graduate out of testing into use, unless you see any impediment.

In the code itself, no — the |listN-is-subgroup= thing is the only thing that jumped out at me, other than that it seems great. The proof is in the execution, so the fact that you've used it to reimplement a bunch of the existing navboxes says it all: Clearly, if it's capable of reimplementing our existing navboxes, then it's able to be used as a replacement for our existing navboxes, because obviously.
The only thing I can see that's lacking is documentation, in particular concise examples.
Real-world examples are great, and they're certainly invaluable for development and testing. (I created two whole pages just to test real-world cases for {{Infobox}} transclusions, and I didn't even write most of it!) But as examples of syntax, real-world examples are basically useless.
Generally, in documentation examples, you want the example to contain the minimum information necessary to illustrate the specific aspect being highlighted by the example. Real-world samples are too busy for that. It's the difference between this as a subgroup-syntax example:
{{Navbox
|title = Things I own
|group1 = My clothes
|list1 = List of my clothes
|group2 = My box
|subgroup2 = {{Navbox subgroup|
  |group1 = Things in it
  |list1 = Some things
  |group2 = Things not in it
  |list2 = Other things
  }}
}}
and this:
{{Navbox
|title = [[Boss-monsters]]
|group1 = Aboveground
|list1 = [[Archnemesis]] • [[Arrestocrat]] • [[Awkwarg]] • [[Broadbandit]] • [[Centourist]] • [[Cholestroll]] • [[Jaguardian]] • [[Megaphony]] • [[Obituarian]] • [[Pundemonium]] • [[Ragnarokker]] • [[Snowman]] • [[Spirit of Halloween]] • [[Terminator T-34]] • [[Wraptor]]
|group2 = Dungeon
|subgroup2 = {{Navbox subgroup
  |group1 = Lvl 1
  |list1 = [[Bagstabber]] • [[Bluffalo]] • [[Boozerker]] • [[Catastroflea]] • [[Cementalist]] • [[Dungeon Sweeper]] • [[Escargolem]] • [[Flowsnake]] • [[Hypnogriff]] • [[Keyborg]] • [[Minotourist]] • [[Nachomancer]] • [[Optimystic]] • [[Plundertaker]] • [[Quasidodo]] • [[Salsamander]] • [[Scaretaker]] • [[Shyborg]] • [[Sighborg]] • [[Telepony]] • [[Turmerisk]]
  |group2 = Lvl 2
  |list2 = [[Aftermoth]] • [[Appetitan]] • [[Archetypo]] • [[Blamethrower]] • [[Buzzkiller]] • [[Detrimentalist]] • [[Exoskeletor]] • [[Flashmobster]] • [[Gastronaut]] • [[Glitch Doctor]] • [[Grimelord]] • [[Hazmatador]] • [[Hellevangelist]] • [[Killdebeest]] • [[Magnum Octopus]] • [[Omnipoet]] • [[Tombcat]] • [[Underminer]] • [[Uranium Slug]] • [[Warmongrel]]
  |group3 = Lvl 3
  |list3 = [[Adminotaur]] • [[Afterlifeguard]] • [[Ark Enemy]] • [[Bosstradamus]] • [[Difficultist]] • [[Ducktator]] • [[Dungeon Keeper]] • [[Flawyer]] • [[Godbuster]] • [[Hangoverlord]] • [[Hyperbully]] • [[Megahurtz]] • [[Obscentinel]] • [[Oxydjinn]] • [[Satyrant]] • [[Shamaniac]] • [[Spelun King]] • [[Stalactitan]] • [[Thug-of-war]] • [[Tinkerhell]] • [[Tubercolossus]]
  }}
|group3 = Mini-Quest
|list3 = [[Ancient Demon]] • [[Drowned Captain]] • [[Level Boss]] • [[Mad Clown]] • [[Vegan Cannibal]] • [[Wherewolf]]
|group4 = Underground
|list4 = [[Alpacalypse]] • [[Alpha Mole]] • [[Bossferatu]] • [[Dragonandon]] • [[Giga Byter]] • [[Heromnivore]] • [[Jack Lantern]] • [[Moleosaurus]] • [[Mount Dracula]] • [[Oreoboros]] • [[Overtaker]] • [[Placeboss]] • [[Pumpkinhead]] • [[Rootbear]] • [[Squirmisher]] • [[Terracotta Worrier]] • [[Vertigoat]]
}}
Especially if the goal is for navboxes to be editable by "lay users", I think clear, simple examples are critical. They can always read the actual templates if they want real-world examples, all the source is right there. The purpose of reading documentation is to get the code broken down so it's easier to follow, that way you can see exactly how to read (and hopefully write) the real-world code.
Other than that, I agree it looks ready to launch, really awesome! I think it'll be a huge help. What were you thinking for next steps? I'm still big on the idea of writing new Template:Navbox whatever templates that reimplement {{Navboxwhatever}} using {{Navbox}}. Then we can cut over to them by just replacing the old template with a redirect to the new one. Easy-peasy, and we get sane (canonical) names to boot. -- FeRDNYC (talk) 20:36, 9 December 2018 (UTC)
I had a flash of insight in the wee hours, and figured out the wikicode parsing behaviour that I hadn't grasped before, and have a much better implementation of the background colour parameters now. Thank for your explanations, I think they helped. {{Navbox subgroup}} can now correctly handle arbitrarily deep nestings of |subgroupN=s with fully granular backgrounds and styles for each level and cell. 👍
Generally, in documentation examples, you want the example to contain the minimum information necessary to illustrate the specific aspect being highlighted by the example. Yeah, I got interrupted when I started rewriting the docs and intend to replace all the examples with far clearer, far simpler dummies, along with quick-start blanks. :) I'll keep Template:Navbox/Documentation pretty simple and give more detailed examples in Template:Navbox subgroup/Documentation for those who want it, since I made {{Navbox subgroup}} able to handle |above=, |below=, and recursive nesting.
What were you thinking for next steps? I'm still big on the idea of writing new Template:Navbox whatever templates that reimplement {{Navboxwhatever}} using {{Navbox}}. Agreed! I was going to work my way slowly through Category:Navigational Boxes, probably (a little lazily) moving the originals to the new names and cutting them to shape from there (seems a simpler workflow than copy-pasting, editing, and then going back to do the redirect). It'll also probably make the history of the navbox templates a little more contiguous for the benefit of any future editors if we become inactive, and someone has a need to trace out the history of it. So that's my plan. Once that's done, maybe I'll get creative with it and start looking for some good thematic candidates for expanding the navbox — I've had some folks say privately that seeing red links in focussed lists (navboxes, the proposal for January) is much more tempting for creating new content than the big Lists. That said, there've been a lot of red links in {{Navboxtaverns}} and a handful in {{Navboxbosses}} for a while now, and not much movement, but we'll see... -- Djonni (talk) 12:52, 10 December 2018 (UTC)

The only thing off about navbox=off was the logic

Taking a look at {{Navbar}}, could you (GodFeRDNYC ) explain to me the purpose of this construction from {{Navboxauras}}?

{{#ifeq:{{{navbar|}}}|off||<span style="float:left;width:3em;">}}<<!--
-->{{Navbar|Navboxauras|mini=1|fontstyle=font-size:88%;border:none;vertical-align:top;}}<<!--
-->{{#ifeq:{{{navbar|}}}|off||</span>}}

If I'm reading it right it checks for |navbar=off, and if present, surrounds the {{navbar}} in a <span>...</span>, but doesn't in fact switch the {{navbar}} off...? I feel like I'm missing something :)

With |navbar= unset:

Auras
Standard Auras Abstinence • Audibility • Baiting • Bliss • Concussion • Confusion • Curiosity • Hoarding • Huckstering • Hunting • Immortality • Pacifism • Rage • Reviving • Saving • Spookiness • Totemism • Trail
Event Auras Censorship • ██████████‎

With |navbar=off:

Auras
Standard Auras Abstinence • Audibility • Baiting • Bliss • Concussion • Confusion • Curiosity • Hoarding • Huckstering • Hunting • Immortality • Pacifism • Rage • Reviving • Saving • Spookiness • Totemism • Trail
Event Auras Censorship • ██████████‎

-- Djonni (talk) 14:32, 1 December 2018 (UTC)

I have no idea what you're talking about, they look right to me! 😇
Yeah, that was basically me screwing up the |navbar=off semantics. I had a hell of a time adapting this:
<!--
---Title and Navbar---
-->{{#if:{{{title|}}}|<tr>{{#if:{{{titlegroup|}}}|<!--
 --><th scope="row" class="navbox-group {{{titlegroupclass|}}}" <!--
 -->style="{{{basestyle|}}};{{{groupstyle|}}};{{{titlegroupstyle|}}}"><!--
 -->{{{titlegroup|}}}</th><th scope="col" style="border-left:2px solid #fdfdfd;width:100%;|<!--
 --><th scope="col" style="}}{{{basestyle|}}};{{{titlestyle|}}}" class="navbox-title" <!--
 -->colspan={{#expr:2{{#if:{{{imageleft|}}}|+1}}{{#if:{{{image|}}}|+1}}{{#if:{{{titlegroup|}}}|-1}}}}><!--

-->{{#if:{{#switch:{{{navbar|}}}|plain|off=1}}<!--
 -->{{#if:{{{name|}}}||{{#switch:{{{border|{{{1|}}}}}}|subgroup|child|none=1}}}}|<!--
 -->{{#ifeq:{{{navbar|}}}|off|{{#ifeq:{{{state|}}}|plain|<span style="float:right;width:6em;"> </span>}}|<!--
 -->{{#ifeq:{{{state|}}}|plain||<span style="float:left;width:6em;"> </span>}}}}|<!--
 -->{{#if:{{{name|}}}|{{Navbar|{{{name}}}|mini=1|<!--
 -->fontstyle={{{basestyle|}}};{{{titlestyle|}}};background:none transparent;border:none;}}|<!--
 --><span class="error" style="float:left;white-space:nowrap;">Error: No name provided</span>}}<!--
 -->{{#ifeq:{{{state|}}}|plain|<span style="float:right;width:6em;"> </span>}}}}<!--

 --><div class="{{{titleclass|}}}" style="font-size:110%;">
{{{title}}}</div></th></tr>}}
...from wikipedia:Template:Navbox (the last old, pre-Lua version) to work directly inline in a template, instead of being called by one, and my first attempt botched it.
(In fact, I botched it pretty heavily, since having a <div> (block element) inside a <span>...</span> (inline element) is a pretty big no-no, as the notes at the bottom of Template:Navbar/Documentation even mention. I'd gotten the purpose of that <span> wrong, it was actually just supposed to pad the navbox's title line when the navbar isn't there, so that turning it off doesn't wildly shift the title centering. Which , as you can see, it now does.)
The fact that I thought the span needed to go around the div (in order to float it left) was down to the fact that I'd failed to inline a style="float:left" into {{Navbar}}'s <div>, due to the CSS navbar class not being available. (The total lack of ability to even request updates to the CSS here is killing me. It's like trying to type with one hand encased in a block of ice.) ...Aaanyway, once I added that, I was able to get the navbar in {{Navboxauras}} properly scoped, and fix it to respect |navbar=off. -- FeRDNYC (talk) 03:53, 3 December 2018 (UTC)
::squint:: Once I've finished my... second coffee, I'll take a fresh hack at my attempt use <span>...</span> in {{navbox}}, since I also committed the same sin of nesting <span><div>...</div></span>. To my credit, I did at least deduce that the point of the <span>...</span> was to balance the centering of the |title= text! :) -- Djonni (talk) 07:09, 3 December 2018 (UTC)
On second thought, perhaps you should simply take care of the implementation of {{Navbar}} in {{Navbox}}, since you've thought your way through it all already on {{Navboxauras}}. By trial-and-error I'd decided on a <span style="float: left; width: 4.75em;">...</span> as the best way to offset the width of the <span style="float: right;">[Collapse]</span> (trying it on a few different displays with varying pixel density), but you've the benefit of greater experience (clearly), and you were working on implementing {{Navbar}} anyway, no point me just coming up with an inferior naive solution.
I put some simple comments in, shouldn't be hard to figure the current state of the code out. -- Djonni (talk) 10:14, 3 December 2018 (UTC)
Sure, I'm happy to tackle that. I'll get it in tomorrow if not tonight. -- FeRDNYC (talk) 06:19, 4 December 2018 (UTC)
Tick.png Done — I also snuck in some other, mostly-minor changes:
  1. Reformatted some of the statements/comments to help me follow the flow when updating the navbar code.
  2. Avoid mentioning things like span sizes in the comments (they have to be adjusted anytime the size is changed)
  3. Table attributes like align="center" and width="..." are deprecated. They're still used in a lot of our old tables, of course, but for new ones it's preferable to use styles instead, so I swapped them out for equivalent style="" attributes.
    (I suspect that things like cellpadding and etc. are in the same boat, but baby steps... it's not as clear yet how to replace those with styles, not having access to the page CSS to define sensible classes and subelement cascades.)
  4. As User:Terezka pointed out, forcing any width on embedded elements can be problematic for mobile screens, especially if that width is wider than the display. Which made me realize that it's actually better if template callers override max-width instead of width, and allow the width of the element to be the smaller of max-width and 100%. I already made that change to {{Diary}}, and I applied the same thing here. So, {{{table-width}}} will set max-width.
    (Also, a question: Why {{{table-width}}}, and not just {{{width}}}?)
  5. I still have to test the implementation of the conditionals (can't do that until I save the changes, which I'll do right after I save this note), but my intent with the code was that an explicit |navbarname=no would disable the navbar. So will leaving it blank, of course, but it's nice to give people an explicit out.
I'll do some more testing of the new code now and fix up anything I flubbed, though everything looks correct in the documentation examples on Preview, so hopefully it's OK. -- FeRDNYC (talk) 11:34, 5 December 2018 (UTC)
Everything looks OK after additional testing, and I updated the documentation some in accordance with my changes. Oh, on this:

By trial-and-error I'd decided on a <span style="float: left; width: 4.75em;">...</span> as the best way to offset the width of the <span style="float: right;">[Collapse]</span> (trying it on a few different displays with varying pixel density)

Ah, but that's the trick — the width of the left span has nothing to do with the Collapse/Expand block, or balancing it. The idea isn't to have the left and right sides in balance, merely to have the centering work the same way regardless of whether the navbar or the collapse/expand text is present or not. So, it's only the width of the element that's being replaced that matters, and which the span should attempt to match.
In fact, after I started writing this I went back to {{Navbox}} and updated it to output the mini-navbar <div>...</div> with a set width of 3.5rem (a little more than it should need, and no harm there), then I changed the filler span in {{Navbox}} to use the same width. So, now it's guaranteed to always block out the same width on the left.
On the right there's no way to completely make the title always center the same, because the width of Collapse/Expand changes when you toggle it (and, indeed, the centering of the title changes too). So, without a reliable width to match in the filler span, I just eyeballed it at 4.5rem for "Collapse" (though that'll be too wide for "Expand", but nothing can be done about that). Hopefully, using rem units will make it map better to display density... though now I'm second-guessing that, since this is one occasion where we'd want local font size to affect the width, come to thin of it. Hmm. -- FeRDNYC (talk) 13:21, 5 December 2018 (UTC)
And then I went to all of our old-style Navboxblehblehbleh templates, and added a span to the left of their title line, because the crazy lurches in centering on User:Djonni/Sandbox after placing the Navbar on the {{Navbox}}-implemented versions was just nauseating.
...Doing that to {{Navboxseasonalevents}} makes me think that rem units were indeed a bad choice, since the centering between the main title and subbox titles worked out much better when I specified the width of the spans on the inner ones in em, so that they took up less space with the reduced font size. -- FeRDNYC (talk) 14:44, 5 December 2018 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

Why {{{table-width}}}, and not just {{{width}}}?

I think my thinking was to distinguish it from, say, {{{group-width}}}, which I decided was a bad idea. So no reason, really. {{{width}}} is semantically much better. (Todo)

Doing that to {{Navboxseasonalevents}}... Look, I think we can agree that the first priority in fixing {{Navboxseasonalevents}} is to set fire to it and watch it burn. 😉 Reworking that into a few smaller, much better considered navboxes is one of the first things I'd like to do with a working {{Navbox}}.

|navbarname=no is a great improvement, as are your other edits. This is almost there, imho. -- Djonni (talk) 18:05, 5 December 2018 (UTC)

Auto-categorization

Re: this, from the Documentation subpage...

|example=anything
Set this to disable the inclusion of category tags, for when you want to give an example of the use of {{Navbox}}, such as on a documentation page (like this one). Note that {{Navbox}} will only include [[Category:Templates]] and [[Category:Navigational templates]] in the Template: namespace, but template documentation is in this namespace.

My strong preference would be to just not do automatic categorization from {{Navbox}}. Then there's no need to disable it.

Auto-categorization is done in article templates because community editors are sloppy, and they shouldn't have to be bothered with that kind of fiddly wiki-housekeeping stuff anyway. Also, transclusions of an article template will be expected to outnumber all other uses by several orders of magnitude, so it makes sense to default to the situation expected to apply in > 90% of the cases, and allow overrides for the few others.

But meta-templates are a different story. They don't get nearly as much use (if we even get to 20 navbox templates it might feel like overkill, and I find it hard to imagine going beyond 50), the types of uses they'll get are much more varied and difficult to predict, and all uses are internal — they're other templates, or template documentation, or template-development discussion, all edited not by the community editors but by template developers. They can be expected to do the required housekeeping chores themselves when (and only when) it's necessary.

There's little benefit to auto-applying template categorization in a {{Navbox}} meta-template, since it's just not that hard to copy-and-paste [[Category:Templates|{{PAGENAME}}]] [[Category:Navigational Boxes|{{PAGENAME}}]] onto the bottom of each navbox template. Having complex logic in {{Navbox}} just to avoid adding that tiny line of code, and then having to build more complex logic to both auto- and manually disable the previous complex logic, seems convoluted and unnecessary. -- FeRDNYC (talk) 04:26, 3 December 2018 (UTC)

I certainly see what you're saying. And, of course, it's very easy to take the logic out. But bear with me for a moment.
There are two reasons I see for having that complex categorisation logic in this meta-template; one to solve a specific problem with navboxes as they are on the wiki now, and one to do with my motivation for building the {{Navbox}} meta-template at all.
Firstly, a specific problem with Navboxes on the wiki now: the number of our navboxes that transclude extra trailing whitespace because of:
|}

<noinclude>{{doc}}[[Category:Templates|{{PAGENAME}}]] [[Category:Navigational Boxes|{{PAGENAME}}]]</noinclude>
and variations thereof. (User:Djonni/Sandbox has a few examples of this.) Is this a big problem? No, not particularly, an editor can just come along and edit that whitespace away, and pages that transclude multiple navboxes where that would be visible are minimal, at the moment. Big problem? Not at all. Easy problem to solve by making it unnecessary to include that kind of fiddly wiki-housekeeping stuff in a navbox in the first place? Yes, in fact, it is.
Secondly, among my motivations for reviving this old {{delete}}d template was this concern of yours, from Talk:Main Page#Navbar line on navboxes (emphasis, obviously, mine):

But with Navboxes, there's nothing to edit in the article, and you do need to edit the template code to modify them. So, it's a little different. There is still the danger, though, that the links will lead to inexperienced people messing up the Navbox templates more frequently.

It seems to me that making navboxes 1) as easy as possible to create and edit, and 2) as difficult as possible to make a counterproductive edit to, are important considerations for a meta-template like this one, and a handy way to minimise this specific concern with inviting more frequent edits by less experienced editors. Templates based on {{Infobox}}, for example, are entirely form with no content, and it's reasonable to make efforts to minimise edits to them in general; by contrast, templates based on {{Navbox}} are purposefully full of content that an inexperienced editor might see opportunities to improve, and should be paradigmatically treated (I think) more like content than like templates.
(Implicit in the logic of if ({{NAMESPACE}}=="Template" && NOT |example=set) is the assumption that the editor of a /documentation subpage is a more experienced editor than the editor of a {{Navboxsubject}}, and that edits that might omit a required |example= will be must less frequent than edits that may disturb |}<noinclude>...</noinclude> in a navbox.)
All that being said, I do hear you saying [m]y strong preference would be to just not do automatic categorization from {{Navbox}}. I'll leave the autocategorisation in for now while we discuss, but before removing the {{construction}} hatnote and taking this to Talk:Main Page we'll come to a consensus on this one — I'm certainly not married to including the automatic categorisation, just explaining why it could be a good choice in our usage context. :) If you still think it's a bad idea, I defer to your experience and judgement, and it's trivial enough to come back and reinstate it down the track if the need arises. -- Djonni (talk) 07:02, 3 December 2018 (UTC)
I'd love to hear any further thoughts on this? If they remain the same, no probs, I'll take out the categorisation :) -- Djonni (talk) 17:42, 9 December 2018 (UTC)
Nah, you've swayed me — I'm on board for the grand experiment.
I'm not sure I believe that the need to include documentation and/or categories is the reason that so many of the existing navbox templates contain extra whitespace — if that was the case, I wouldn't spend so much time editing it out of article source. It ends up there mostly because people just don't think about it, and they don't test the results — or it's never noticed because it's an invisible problem, like the whitespace under the navboxes. You'd never spot that unless you stacked them together, and that's not something we've ever done in the article namespace.
But, that being said, MediaWiki's automatic trimming of whitespace at the end of a document will save at least some people from making that particular blunder, so it's worth doing. I'm still expecting to see Template:Navbox something edits that leave them looking like this:
{{Navbox
| title = Groups Of Things

| group1 = First things
| list1 = Some list of things

| group2 = More things
| list1 = A copy-pasted list of things

| group3 = Frustrating things
| list3 = Why isn't my second list showing up???????1???111?????one???



}}
...but that's because I'm a cynic, so it's good to assume that we can put more faith in people than I typically have. Plus, at least it'll be obvious when ^^ that ^^ kind of mess happens, unlike hidden trailing whitespace. -- FeRDNYC (talk) 20:03, 9 December 2018 (UTC)

A suggestion on listN-is-subgroup

I do have a suggestion, though, on |listN-is-subgroup=.

Rather than doing that, I would approach it more like {{Infobox}} does it (which I can't take credit for, because that was all Wikipedia). Rather than the user having to explicitly specify that, for each row have a separate parameter for subgroups than the one used for lists, and use the nonempty presence of that parameter as an implied |listN-is-subgroup=yes.

In other words, if the user writes:

{{Navbox
|title = My box
|group1 = Things in it
|list1 = Some things
|group2 = Things not in it
|list2 = Other things
}}

...they get a normal navbox.

But if instead they write:

{{Navbox
|title = Things I own
|group1 = My clothes
|list1 = List of my clothes
|group2 = My box
|subgroup2 = {{Navbox subgroup|
  |group1 = Things in it
  |list1 = Some things
  |group2 = Things not in it
  |list2 = Other things
  }}
}}

They get a box with a subgroup.

It's basically the same code, just anywhere you test e.g. {{#if:{{yesno-no|{{{listN-is-subgroup|}}}}}|yes|...}} instead test {{#if:{{{subgroupN|}}}|...}} and also make the processing of {{{listN}}} conditional on its non-empty presence, same as the processing of {{{subgroupN}}}. Setting both |subgroupN= and |listN= for the same N is defined as invalid. (Though you can choose to write some protections against it or not, up to you.) -- FeRDNYC (talk) 14:20, 9 December 2018 (UTC)

I like that as a solution, I wasn't too happy about needing a separate parameter as a switch. I'll make the changes. -- Djonni (talk) 17:08, 9 December 2018 (UTC)

Centering test

Just pulling in two of the examples from the documentation page together so we can look at them right next to (or on top of) each other, since the centering seems a bit weird and I'm not sure why:

 Simple Navbox
Item • Item • Item • Item • Item
 
Example with text below 
Item • Item • Item • Item • Item
This text appears below the lists of items.

Hmmm... the centering is a little off on the title, I suppose I could make the navbar slightly wider, or put a small span next to it (come to think of it that's probably a much better idea) to shift the title slightly right. But it's really not that bad. I don't know why it struck me as so much farther off, seeing them not adjacent on the documentation page? Weird.

Oh, I see it now! Had to sit back a little. The centering is a tad off on the upper box, but more off on the lower box, because the right-hand replacement span is too wide. My fault, there, so I'll fix that too. -- FeRDNYC (talk) 21:51, 15 December 2018 (UTC)

Group-title nowrap on mobile

@GodDjonni : So, lately I've been making a point of paying more attention to how Navboxes format on mobile, especially with regards to width and the super-narrow columns issue. (A problem that plagues all tables across the entire Godwiki, when being viewed on small phone-sized displays — it's in no way unique to Navboxes. But Navboxes are some of our most visible tables, and they're by far the most visible that are "designed wide". (As opposed to designed-narrow, like Infoboxes, which makes them a much easier fit for mobile formatting — in theory, anyway, if not for whatever's going on with the site CSS here that's pushing things offscreen.)

Which has led me to one proposal, which I'll post... probably elsewhere, shortly. I'll point to it when it's done. But that's secondary for the moment.

In the leadup to that, I decided to try my hand at reimplementing one of the remaining infoboxes, since I'd never actually written one from scratch... well, at all, actually — but in particular (for the purposes of this discussion), with the new {{Navbox}} backend. So I went in and built a new {{Navbox pantheons}} right above the old one, so that I could compare the results. (Then I just the old table code once I was satisfied with my replacement.)

Well, that process was a breeze — it couldn't possibly have been more convenient and simple. In fact, if I'd let myself cheat and pull the code into a text editor so I could use search-and-replace to change all of the &nbsp;• into | , I probably could've been done in under 2 minutes. (I didn't cheat, though, and hand-edited the {{Navbox list}} arguments after copy-pasting them from the previous version's table-cells. Because I wanted to go through the process "by hand" to at least some extent.) Still, point is, kudos on all of the work you put into making that happen, as it most definitely paid off! The reimplementation came together like a dream, and looked identical to the old version right from the first time I hit "Show Preview".

...Well, almost identical. The one thing I noticed was that, as I narrowed the browser window, the old table-based version folded itself up into the narrow space better than the {{Navbox}}-based version. The reason why comes down to one thing: In the new version, the group-label cells don't wrap. That forces that column to be twice as wide as the table-based version, at the narrowest page widths. And on mobile, that can easily translate to the difference between eating up 20% of the screen width and 40% of the screen width, which leaves barely half of the screen for the actual data on the other side. So, (finally) getting to my point:

TL;DR: I think we need to lose the default nowrap styling on the |groupN= arguments, and really to move away from nowrap-by-default in general... #BecauseMobile.

Until that long-off, mythical day comes when we have robust CSS available that can make styling decisions based on screen size, so that nowrap is only forced when there's room for it to be effective instead of problematic, I think it's basically always a bad idea to force it on anything that'll end up having to fit on a mobile display. (With certain obvious exceptions, like keeping the output of {{god}} and etc. from wrapping.) Thoughts? -- FeRDNYC (talk) 13:33, 22 January 2019 (UTC)