This is an archive of past discussions about Template:Navbox. 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.
For testing, I compared the output from {{navbox}} and {{navbox/sandbox}} for several cases—all good. Some other tests follow.
I made {{Beijing Subway Station/sandbox}} use {{Navbox/sandbox}} and previewed a couple of tests. They worked, and the striping was correct where it would previously fail to alternate correctly.
I previewed an edit to Module:Navbox with striping after changing it to use navbox/sandbox. Previewing with Angola showed that the navboxes at the bottom were unchanged.
When comparing results produced by the current navbox with those from the sandbox, it is seen that centering of the navbox title has changed. That is due to changes by Jc86035. The current navbox does some tricky padding to compensate for the V·T·E links but navbox/sandbox gives a better result IMHO.
The current navbox does some special processing for list1 which is mentioned in the template documentation as "For the image to display properly, the list1 parameter must be specified." Navbox/sandbox changes that so the special processing is done for the first listn which might not be list1. That seems more natural to me—if no image is wanted, it should not be included in the navbox.
I purged Template:Navbox/testcases and checked them. They all look good with some minor differences which are improvements:
At "Missing List1 Test", the current navbox starts with List2 having a gray background because 2 is even. However, navbox/sandbox starts with the normal white background because it does not use the list number to determine the color.
At "Missing List1 and List2 Test", the current navbox shows the two lists with white background because both numbers are odd, whereas navbox/sandbox applies the normal striping.
did not stripe the subgroup navbox and the page was in Category:Navbox orphans. Fixing the subgroup to be the following made the striping work and removed the category:
|list1 = {{Navbox/sandbox|subgroup|orphan=yes
An orphan navbox is a subgroup (child) navbox which is not contained in a normal navbox—that is, the child navbox does not have the correct parent. The category will need monitoring to detect any problems. Adding orphan=yes makes the child navbox work like a normal navbox as far as striping is concerned, and removes the category.
@Johnuniq: Obviously I'd like to have this implemented, though the header still requires some CSS changes (I think) and we need to update {{Navbar-collapsible}} from its sandbox version if any CSS changes. Jc86035 (talk) Use {{re|Jc86035}} to reply to me09:09, 11 March 2017 (UTC)
@Jc86035: I don't know anything about that so I'll leave it to you. However, do you want to do your changes first (before the module is changed)? If it looks like I'll have a few hours where I can monitor any disasters, I was thinking of switching the module sometime from 12 to 24 hours from now. Should that be delayed? Johnuniq (talk) 06:42, 12 March 2017 (UTC)
@Johnuniq: I think the CSS should be changed after the module, as the current padding is necessary for centring the title text. The sandbox version is fine with both sets of padding in use, although there will be some minor display changes for multi-line titles (but not worse than the current display). Jc86035 (talk) Use {{re|Jc86035}} to reply to me07:12, 12 March 2017 (UTC)
Ah, I was thinking of something in the module but of course you are referring to changes to the CSS for what the module outputs. Johnuniq (talk) 07:15, 12 March 2017 (UTC)
Alphabet#Types has a navbox as the caption to an image. The navbox uses {{Navbox with columns}} as {{Navbox with columns|child|...}}.
Farmer v. Brennan Copy the infobox ({{Infobox SCOTUS case}}) to a sandbox then preview. The preview shows the above hidden category. Searching the html source for "_ODDEVEN" shows the broken style for "Chief Justice" and "Associate Justices".
The good news is that the articles do not show any problems. Previewing the article with the old module gives an identical display on my system. Johnuniq (talk) 01:05, 13 March 2017 (UTC)
What can be done with the infobox {{Argentine state}}? Currently that page is displaying cached html from before Module:Navbox was updated and the page is not in the tracking category. Also, the headings such as "before 1500" are properly centered. However, my sandbox (permalink) is displaying the infobox using the updated module, and it is in the tracking category. That can be fixed but there is a problem: the headings are not properly centered. @Jc86035: Any thoughts about centering? Johnuniq (talk) 09:34, 13 March 2017 (UTC)
@Johnuniq: The headings are left-aligned, which obviously doesn't work very well with 4em padding on both sides. Maybe change it to use {{Sidebar with collapsible lists}}, which I think is a better fit (plus it renders on mobile). Not rendering on the mobile site could also be a problem for a lot more of these pages, so they would ideally use other templates. Jc86035 (talk) Use {{re|Jc86035}} to reply to me10:22, 13 March 2017 (UTC)
Following the recent change (above), several templates are, or will be, in Category:Navbox orphans and that puts around 140 articles in the category. There will be more as the job queue catches up. Templates with the problem are in the API list.
I need help to fix these since I'm just a Lua person!
@Llightex: It works for me. Try clearing your cache or purging the page (add ?action=purge to the end of the URL). What browser are you using, and do you have any scripts enabled? Jc86035 (talk) Use {{re|Jc86035}} to reply to me13:29, 16 May 2017 (UTC)
@Jc86035: You're right, it was due to a script. Thanks!
Alignment
Is it possible to fix cases like this so that |image= content is automatically aligned to the right, |imageleft= content to the left, and main content always centered? --Obsuser (talk) 05:35, 19 May 2017 (UTC)
Right image is not aligned "totally" right (what looks better and is more intuitive to expect), and bigger issue – main content (block of hlist items) is not centered but pushed to the left. /Win7, Chrome/
This is not noticed maybe when there is more links but in this case it is.
Image alignment can be fixed by adding either |imagestyle=text-align:right (|imageleftstyle=text-align:left) or |right (|left) in the [[File:]] syntax. But is is case with every image i.e. chance that someone added this is smaller than that one didn't (as in my example). Main content is not centered in any case. I played in sandbox with previewing modification of adding the same image on the left if right is defined and left is not (and same image on the right if left is defined and right is not) with visibility:hidden in order to center content but column tags got mixed and it did not work...--Obsuser (talk) 09:39, 19 May 2017 (UTC)
@Obsuser: the common fix for centering the list in that case is to use |liststyle=padding-left:50px to offset the 50px width of the image on the right. Frietjes (talk) 14:04, 20 May 2017 (UTC)
From the MfD, it is proposed that some features of the above module be merged into Module:Navbox. The proposal is that a new parameter be added. If the parameter is set to yes, each item in each list would be processed by the module to replace:
item
with:
<span class="nowrap">item</span>
The nowrap span would not be added if it is already present.
Module:Navbox with nowrap lists currently applies that processing to items in each listN parameter, and to parameters above and below (it would also process the seldom-used aboveclass + abovestyle + belowclass + belowstyle although I assume that is unwanted).
@Johnuniq: yes, yes, yes. note that this would allow for the merger of template:Team roster navbox / Module:Team roster navbox as well, and allow for the removal of explicit and {{nowrap}} markup from a large number of navboxes. I could see a case for |nowrapitems= for all items, and |nowraplistitems= for just the items in the lists parameters, but I think starting with just |nowrapitems= for all items would be a great start. Frietjes (talk) 13:19, 23 March 2017 (UTC)
Izno, the only potential problem is that we have gone so long now without nowrap for hlists, that turning it on by default could cause problems. I recall having to add {{allow wrap}} to long list items (e.g., footnotes) before the nowrap css was disabled. but, I wouldn't object if people feel that the good outweighs the potential problems. I think it would take longer to get nowrap for hlist back into MediaWiki:Common.css than it would to add something here. Frietjes (talk) 19:36, 23 March 2017 (UTC)
I'm skeptical. The principal objector in the previous case (and who was otherwise generally careful with site CSS, JS, and templates) is who-knows-where. I would guess that the majority of people here would be willing to sacrifice the offending browser(s). --Izno (talk) 19:46, 23 March 2017 (UTC)
How can this be moved forward? Would WP:VPT be the right place to ask about the technical issues such was whether restoring the nowrap CSS would be desirable, and which browsers might be affected, and whether that is a problem. First, it would be helpful to find a link to something specific about the "nowrap CSS" that I know nothing about. Hmm, perhaps 17 November 2013 is a diff showing Edokter removing the CSS that is now wanted. The edit summary was "hlist: removing default list item nowrap behaviour; it causes to many issues in IE, and each fix causes even more issues", and it was briefly discussed here. Johnuniq (talk) 03:04, 24 March 2017 (UTC)
I'd start at MT:Common.css and if no response, invite editors at VPT (as well as here, and perhaps TT:Sidebar). --Izno (talk) 14:23, 24 March 2017 (UTC)
and, the entire process has been torpedoed again, with the added bonus of having functionality removed this time (module was deleted with no solution added). I still don't understand why we can't just add something to this module as suggested above. Frietjes (talk) 14:40, 1 May 2017 (UTC)
@Frietjes: I will never understand what all the css stuff is doing and fortunately I do not need to. However, I see that class="nowraplinks..." is in the output of a navbox (see my sandbox2 or permalink). Very briefly and only if you happen to know, what is that about and what would be the effect of nowrapitems=yes at say Atlanta Braves#Current roster? Is that article the kind of thing aimed at? If not, what is? I would feel more comfortable if I knew what the module changes should achieve in a sandbox test, so if you have an example demonstrating the issue, you might like to edit my sandbox2 to replace its contents. Johnuniq (talk) 04:23, 2 May 2017 (UTC)
I updated sandbox2 to show a navbox with a list. I think that is the issue? That means the module needs to break each listN item into lines, and put the nowrap around each line, but if there is an asterisk at the start of the line, do not include it in the nowrap? LOL, it's all coming back to me now because I looked at it before. Johnuniq (talk) 05:07, 2 May 2017 (UTC)
I updated the sandbox module to handle nowrapitems=yes. I will examine the code in the next day or two because it was rather rushed and is untested. Please use {{navbox/sandbox}} to try it out. It would be good if a few simple tests could be put somewhere, possibly my sandbox2. Johnuniq (talk) 11:50, 2 May 2017 (UTC)
@Frietjes: I put a demo in my sandbox2 (permalink). Please carefully examine it, and preferably examine the html source, to check everything seems ok. If you confirm that it is ready, and no one sees any problems, I will update the main module. — Preceding unsigned comment added by Johnuniq (talk • contribs)
Johnuniq, thank you, looks great. I diffed the HTML source and the only change is the addition of the "span nowrap" tags, which is exactly what we want. I also diffed the output from the live and sandbox version, and there were no differences when nowrapitems was not equal to yes. so, I would say it's ready to go. thank you again. Frietjes (talk) 13:11, 3 May 2017 (UTC)
The above is four physical lines. The last three lines start with "#" and the module (when nowrapitems=yes is used) interprets them as forming a numbered list, so the module inserts the nowrap span around the rest of the physical line that follows each "#". I guess that MOSMETRO-bull should be fixed so it does not produce separate lines. Is that reasonably achievable? Johnuniq (talk) 22:49, 4 May 2017 (UTC)
looks like that fixed it, so the lesson here is to look for constructs like {{#if: ... | #00AABB }} since the parser inserts a newline before the # making it look like an ordered list item. Frietjes (talk) 13:50, 5 May 2017 (UTC)
Is there a way to stop separator middle dot from detaching from previous item? Sometimes it gets displayed at the very beginnig of the new line. It could be done in a similar way as external link icon is handled in CS1 modules. --Obsuser (talk) 15:43, 7 May 2017 (UTC)
Is this with the new nowrapitems=yes parameter, or is that irrelevant?
Navbox does not control middots in any way I can see. Given a list of three items, navbox outputs html for the list as follows:
@Matt Fitzpatrick: The padding between groups and lists seems to too wide (especially for the odd-numbered/grey rows). The border-spacing might work better at 0.15em instead of 0.2em, although it doesn't fix the aforementioned issue. (Firefox 53.0.2.) Jc86035 (talk) Use {{re|Jc86035}} to reply to me06:29, 17 May 2017 (UTC)
@Jc86035: Phew! After much trial and error, it looks like the best solution might be to go back to basics. This sandbox diff just strips the gutter rows, nothing fancy. This CSS, once merged into the sitewide CSS, applies the new borders. :first-child is CSS 2.1, so this should work all the way back to IE 6. Matt Fitzpatrick (talk) 12:13, 17 May 2017 (UTC)
Got it down to one new CSS rule instead of two (diff). Tested on IE7 and 8, seems okay. Will put in a common.css edit request in a few days if no problems come up. Matt Fitzpatrick (talk) 06:32, 27 May 2017 (UTC)
@Jc86035 and Matt Fitzpatrick: it would be possible to automatically transform inside of navbox, but that might be a bit much. so, for now, I created Template:Box-shadow border to simplify the syntax. let me know if you see any problems with the implementation, or would like to change the parameter order, etc. thank you. Frietjes (talk) 14:49, 25 June 2017 (UTC)
@Frietjes: Works well; thanks for creating the template. I've fixed a few more templates, although they may need to be gone through again because many of the ones I've fixed are international sports navboxes which are supposed to use consistent colours across the series for each continent but don't due to arbitrary ordering of groups. Jc86035 (talk) Use {{re|Jc86035}} to reply to me16:10, 25 June 2017 (UTC)
@Jc86035 and Matt Fitzpatrick: in renderNavBar we have 'border:none' to stop the V-T-E links from inheriting border styling from the titlestyle / basestyle. if we are going to use box-shadow for the borders in the basestyle or titlestyle, we probably want to add something similar for 'box-shadow', '-moz-box-shadow', '-webkit-box-shadow'? I had to execute this revert since it was adding box-shadows to the V-T-E links. Frietjes (talk) 23:00, 28 June 2017 (UTC)
Matt Fitzpatrick, thank you. if you look at the extractstyle function in Module:Team roster navbox, I pull out only the color and background from the style to pass on to the span inside the links. that module could probably be merged with this one at some point. the only thing that it does that the standard navbox module doesn't do is automatically color links. Frietjes (talk) 13:35, 29 June 2017 (UTC)
Padding for images and width for Authority control cell
Could someone review and add these edits: 5px padding for images and removal of width:auto in Authority control template so that this cell does not get too wide? --Obsuser (talk) 17:25, 9 July 2017 (UTC)
In the documentation, it states that It is recommended that one use {{Navbox subgroup}}, but the same result can be reached by using {{Navbox}} with border = child or the first unnamed parameter set to child.. can someone explain why it's recommended to use {{navbox subgroup}} instead of {{navbox|subgroup}}? I would think the recommendation would be the reverse since (1) using {{navbox subgroup}} is less efficient due to the additional wrapper later, and (2) {{navbox subgroup}} cannot support more than 20 groups/lists. I am guessing that this recommendation (which was added by CapitalR in this edit) was true in the past, but is no longer true? Frietjes (talk) 21:18, 14 July 2017 (UTC)
While working on Module:Navbox last March I wondered about {{Navbox subgroup}} but ended up ignoring it as what I was doing was already complex. A very quick look at the wikitext in {{Navbox subgroup}} suggests that it tries to pass all parameters to {{Navbox}} except that grouppadding defaults to 0em 0.75em;. Is {{Navbox subgroup}} useful? I have not followed the work done on the module recently regarding using css, but presumably any default padding should be set there. Johnuniq (talk) 23:24, 14 July 2017 (UTC)
I agree that we should be setting any padding for subgroups in MediaWiki:Common.css, and to avoid confusion we should have the same group padding for both {{navbox subgroup}} and {{navbox|subgroup}}. checking the current MediaWiki:Common.css I see padding: 0.25em 1em which is close to the 0em 0.75em value. if we really want to have less padding for groups in subgroups, I believe we can handle that in MediaWiki:Common.css as well. It would be great if {{navbox subgroup}} were a very thin frontend that was functionally equivalent to {{navbox|subgroup}}. Frietjes (talk) 23:40, 14 July 2017 (UTC)
There are thousands of templates that link to Template:Navbox subgroup. Previewing what happens if the subgroup template is not used shows a very minor difference in spacing—if that difference is desirable, it should be in the main template. Any thoughts on how to proceed? The cautious approach would be to edit a couple of navboxes from the "what links here" list to replace {{navbox subgroup|...}} with {{navbox|subgroup|...}}
then see what happens. A faster strategy would be to replace {{navbox subgroup}} with a redirect to {{navbox}}. Johnuniq (talk) 04:34, 20 July 2017 (UTC)
That should be easy. I think the requirement is that the module should get the navbox parameters from the template, but use the border=... parameter if it is given in the module invoke. I'll ponder that later. Ping me if I go AWOL. Johnuniq (talk) 23:10, 17 August 2017 (UTC)
@Frietjes: I got distracted with some idiocy. I don't use Module:Arguments and so am not really aware of what's going on, but a quick look makes me think your {{#invoke:Navbox|navbox|border=...}} at Template:Navbox subgroup/sandbox (permalink) would have worked. That template is not listed as a "wrapper" so I would have thought the border parameter in the invoke would be accepted. Can you recall what made you decide it did not work? Johnuniq (talk) 11:36, 18 August 2017 (UTC)
@Frietjes: I don't understand what's going on. Previewing lots of debugging tests showed that the border parameter never made it into the module but I could not work out why. I decided to remove the wrappers stuff, and now it's working. I will return to ponder what's going on another time.
Johnuniq, as far as I can tell, that works. I don't know if there is any possibility of introducing new problems by not checking the invoking parent's name. I suppose we can always make the change and see if anything bad happens. Frietjes (talk) 13:47, 19 August 2017 (UTC)
Yes, I think you could put the sandbox code in the main module but when I get some time (soon!?) I plan to work out why the current code misses the parent border in the subgroups template. It shouldn't! What I'd really like to do is work out if Module:Arguments is doing anything needed by Module:Navbox because the arguments layer is obscuring what's going on. I probably won't do anything about that. Johnuniq (talk) 01:24, 20 August 2017 (UTC)
Bug report - Link to current page in a navbox not disabled when it is via a redirect.
Frietjes, thanks for your reply. I have fixed the link, but that does not address the bug when a redirect is inadvertently used. In the example given the redirect page is the correct format for the article, while the article title is one of those special cases often found for a subject which is the first of, or the only one of, in the known universe, that has an article in WP (rather strange for a fairly insignificant street, I know) Cheers, Downsize43 (talk) 22:05, 22 August 2017 (UTC)
This is not a bug which can be fixed save by fixing the link in the navbox, or removing the link in the navbox (if the target of the redirect is no longer appropriate for the navbox). --Izno (talk) 02:08, 23 August 2017 (UTC)
In theory, couldn't this be fixed by checking the redirectTarget of each linked page with the mw.title library? But it might not be desirable because it could use up too much of the expensive parser function quota on a page with a lot of navboxes. Toohool (talk) 02:42, 23 August 2017 (UTC)
Hello I always get an error when using templates that rely on Module:Navbox. I get always this error: Lua-Feeler in Modul:Navbox, Zeile 241: attempt to index local 'listText' (a nil value). How can this bug be fixed? --Soued031 (talk) 11:50, 6 September 2017 (UTC)
Throw template calling this module into maintenance category under certain conditions
Is it possible to do the following? If a page directly invokes Module:Navbox, if the value at name= does not equal {{BASEPAGENAME}}, can the invoking template (but not the pages that transclude the template) be placed in a maintenance category? Steel1943 (talk) 22:33, 18 September 2017 (UTC)
That might be possible but I would have to do some serious thinking which won't happen for a while as I'm doing stuff at Commons. If no one else has ideas, consider pinging me in a week or two. You might mention an example of where the category would be useful, and briefly why. Any ideas on a category name (generic is best to allow re-use for something else)? Johnuniq (talk) 23:18, 18 September 2017 (UTC)
The database report does a monthly scan of the wikitext and generates warnings about problems it finds. It cannot and should not edit pages. My quick look of the report failed to find the page you mentioned—I don't have time to investigate. Adding tests to templates/modules causes the overhead to mount up and that expense is paid many, many times as affected pages are rendered in the future. There are over three thousand tracking categories so there are plenty of issues that need addressing. Johnuniq (talk) 22:34, 19 September 2017 (UTC)
Utterly disable category handling
I would like to have absolutely 100% control over all of the categories on my platform, but I cannot for the life of me prevent Navboxes from being automatically categorized. I have utilized |nocat=true, and while this has worked elsewhere, isn't doing a single thing to help on my created Navbox template. I would greatly appreciate any information on how to suppress these categories(or category handler altogether, if possible.)
2602:304:CF7D:A010:AC12:8F5E:4AC2:39B6 (talk) 02:16, 26 September 2017 (UTC)
Should there be e.g. |groupnlang= parameters? Are they necessary? I tried replacing an incorrect use of {{lang}} (which uses a span tag) in {{Irish names}} with |groupnstyle=" xml:lang="ga" lang="ga but it doesn't seem ideal. Jc86035 (talk) 14:24, 24 December 2017 (UTC)
Jc86035, creative, but it's the lists that are in Gaelic, not the group labels. couldn't you also fix it by using <div>...</div> instead of <span>...</span> with the lang tagging? Frietjes (talk) 14:37, 24 December 2017 (UTC)
Jc86035, yes, it appears tidy is distributing the spans to all of the list entries. this is nice, but since tidy is being replaced with lint, so who knows what will happen then. I have replaced it with divs for now. Frietjes (talk) 14:47, 24 December 2017 (UTC)
I think this is a limited-enough case that lang parameters for each list are unnecessary. I've also removed xml:lang since that is not conformant in HTML 5. The use of the div is how I would generally mark this up. --Izno (talk) 18:32, 24 December 2017 (UTC)
sure, and according to the link you provided, it's looks harmless since it has "no effect on language processing". but, if it has no effect, there is also no reason to add it. Frietjes (talk) 14:42, 25 December 2017 (UTC)
Color accessibility issue in V*T*E links on standard navbox title color
I don't use Module:Arguments enough to know whether a pipe would do anything useful. I would have thought that each string in the wrappers table had to be the name of a template. Johnuniq (talk) 23:38, 8 January 2018 (UTC)
Johnuniq, thanks for spotting the error. I had been replacing 'navbox subgroup' with 'navbox|subgroup' and forgot to turn off the script before editing the module. now corrected. by the way, if you have time to figure out how to make Template:Navbox subgroup/sandbox work with the getArgs, that would be great. you can probably experiment with "Navbox subgroup" directly since the transclusion count is low. Frietjes (talk) 00:34, 9 January 2018 (UTC)
@Frietjes: So the problem is that Template:Navbox subgroup/sandbox invokes Module:Navbox/sandbox and passes a border parameter. The expected behavior is that the border parameter from the template would be merged with the parameters from the parent, that is, from the wikitext in User:Johnuniq/sandbox2. The reason that is not happening is due to the use of wrappers in the module:
Edit the sandbox module and change the above line to:
args = getArgs(frame)
then paste User:Johnuniq/sandbox2 into the "preview page with this module" box and Show preview. The idea of Module:Arguments is to merge arguments from the invoking template and the parent wikitext, but that is usually unnecessary overhead. Therefore wrappers can be used to specify the templates which do not pass parameters (they merely wrap the module) and which therefore do not need merging. I can't understand the documentation for Module:Arguments so experiment would be needed to determine what would happen if a border parameter was passed in the parent wikitext as well as from the template. Johnuniq (talk) 02:30, 10 January 2018 (UTC)
Johnuniq, yes, I had experimented before with removing the wrappers parameter, and found that it worked. however, I have no idea why it doesn't work with the wrappers parameter. looking at Module:Arguments it should be looping over the entries in the table of wrappers and passing them to the "matchesTitle" function? assuming that part is working, then there must be a logic mismatch between the "wrapper" and "no wrappers" branches of the code. Frietjes (talk) 15:59, 10 January 2018 (UTC)
after reading the documentation for Module:Arguments some more, I see that if it is a wrapper, then it won't parse the parent args? so, if that is the case, we definitely don't want "navbox subgroup" to be listed as a wrapper. another option would be to have a separate "subgroup" entry point into the module, but that seems a little excessive considering how few transclusions there are of "navbox subgroup" at the moment. Frietjes (talk) 16:03, 10 January 2018 (UTC)
@Frietjes: We discussed this in July 2017 here. I forget all about that, but I see that my local copy of Module:Navbox had some code to get border from the template. I don't know if I ever tried that out last August, but I put it into Module:Navbox/sandbox just now. Does that work?
Re "if it is a wrapper, then it won't parse the parent args?": Module:Args always gets the parent args (that is, the arguments from User:Johnuniq/sandbox2 in our example). There may be a way to turn that off so "always" may be a bit strong, but the cases I have seen always involve getting the parent args. The purpose of wrappers is to avoid the overhead of merging arguments from the template—if it is a wrapper, then an argument in the wikitext of the template definition will be ignored. If the template might have various arguments that should be merged, you would omit the template from wrappers. In the case we are considering, the only template parameter is border so my edit checks for that only. It should work! Johnuniq (talk) 02:48, 11 January 2018 (UTC)
Johnuniq, looks good, I have updated the main template. by the way, I hope I didn't completely mangle Module:Football manager history. immediately after I turned on the tracking, pages using that module started popping up in the "uses basic css borders" tracking category, so I changed the borders to use the 'box-shadow borders'. unfortunately, the box-shadow borders (see {{box-shadow border}}) are more complicated, but without them you don't get the visual separation between the groups/above/below etc. please let me know (or correct it) if I screwed it up. Frietjes (talk) 13:14, 11 January 2018 (UTC)
In case it's not obvious, all I did in writing Module:Football manager history was emulate what the old template did. What you have done with the border is way over my head. Re the changes to the module, they look good. In addiflist it might be better to use ipairs for consistency—that's how a list should be iterated. Also, it would be a little more efficient to have addifsubst which takes a long string rather than a table. It would replace (substitute) each occurrence of %1 with item using gsub. However, your code is good and I am just mentioning my thoughts for completeness. By the way, your script might be doing more than wanted: check diff which changed "Carson–Newman" to "Carson to Newman". I might look at it more another time. There were quite a few problems when I converted a zillion articles using the system to the syntax preferred by {{Football manager history}}. I could see the template might be useful in other cases but I was exhausted by then. Johnuniq (talk) 06:53, 12 January 2018 (UTC)
I just had a look at my contributions. It was actually 1377 templates, not articles, OMG. I think I used a Python script to do the major edit (example), then manually checked if it had worked. Johnuniq (talk) 06:59, 12 January 2018 (UTC)
Johnuniq, the six or so conversions to Template:Football manager history were done by hand using search-replace, so it's not too shocking that I screwed one up. in any event, those changes were reverted, so it's not an issue at this point. the bigger idea would be to take the simplified colouring syntax from that module and make it generic. and, even better would be to take the automatic link colouring code from Module:Team roster navbox as well. Frietjes (talk) 13:24, 12 January 2018 (UTC)
The module changes are great, thanks. Later I could help with your "bigger idea" if wanted, and if I could see some simple examples of what is meant. Johnuniq (talk) 01:25, 13 January 2018 (UTC)
