Edge Rewrite
// HTMLRewriter · presentation

This page was redesigned at the edge.

Cloudflare fetched the original article and streamed it through HTMLRewriter to apply an entirely new visual system without rebuilding the source page.

// request.cf · coarse context

A page that knows where it met you.

Only coarse request metadata is shown. This demo does not display or persist visitor IP addresses.

Country
US
Cloudflare location
CMH
Connection
HTTP/2
Language
Not provided

Ray ID: a235b021ad60f41a

Jump to content

Template talk:Tree list

Page contents not supported in other languages.
Add topic
From Wikipedia, the free encyclopedia
Latest comment: 2 months ago by Arctic Circle System in topic Tree list breaks clicking links in infoboxes

Names of templates

[edit]

I wasn't too sure about the names for /branching and /final branching. Are there any better alternatives?  Martin (MSGJ · talk) 15:01, 22 June 2012 (UTC)Reply

Hi, yes we were just discussing the same type of naming "issue". embanchement is branching, and branche is branch! I tried {{TreeList start}}, {{TreeList end}}, {{TreeList/branch}}, {{TreeList/branch end}}, and {{TreeList/treminal branch}} . We were discussing on the succession talk page. I must be one of those "strange" programmers that embraced "CamelCase" a long time ago, I am not overly committed to keeping the CamelCase, but would prefer we use "Tree list" as it is more descriptive of what the template does. ‎Martinvl (talk · contribs) and I had started the work on importing and translating, perhaps we should include all parties in the discussion?--UnQuébécois (talk) 15:38, 22 June 2012 (UTC)Reply
I went with "tree view" because this is what UnQuébécois called it on his post to Mediawiki talk:Common.css. If you are sure "list" is better then I will not oppose Template:Tree list (with space and without Camel!) UnQuébécois: what is your opinion?  Martin (MSGJ · talk) 16:04, 22 June 2012 (UTC)Reply
I copied the class directly as is, it was already called Treeview, and wanted to keep consistency across the wikis, however I also specifically referred to it as a list in the request, and all references to the templates spoke of a list! Like I said, I would prefer "Tree list" to "Tree view" for the templates, and I can capitulate to not using CamelCase! I do think we need to revisit the branching names, to avoid confusion for the "luddites" ! --UnQuébécois (talk) 16:54, 22 June 2012 (UTC)Reply
Okay moved. Sorry for the confusion above - I saw ‎Martinvl's name and I thought that was his post not yours! Think I need some more coffee.  Martin (MSGJ · talk) 17:08, 22 June 2012 (UTC)Reply

/end

[edit]

I don't see /end as being particularly necessary. The same could be accomplished with a slight tweak to template:tree list (the addition of a parameter and the closing tags in /end), from what I can tell, in much the same way we would apply Template:Plainlist or Template:Flatlist. --Izno (talk) 20:11, 23 June 2012 (UTC)Reply

/end is the same thing as {{endplainlist}}, with the different branching levels, I'm not sure how you would implement the branching templates inside the outer template easily. The template was created in another language wiki, and was imported as is, except for the strange branching names. --Education does not equal common sense. (talk) 23:25, 25 June 2012 (UTC)Reply
I don't see it being implemented any differently than with plainlist. Why do you think there would be a problem?
As for endplainlist, I didn't even know that existed, nor do would I personally condone its use. Templates with only a </div> (or another closing tag) seem like bad template editing to me. /shrug
I'm well aware it was imported as is. I'm suggesting that it shouldn't be used, "as is", since en has a chance to improve upon the case, I believe.
On another note, is it just me or should {{Tree list/final branch}} be coded as a <span> rather than as an <li> and then closed (</span>) rather than left to hang open? the same question for /finalbranching... --Izno (talk) 23:42, 25 June 2012 (UTC)Reply
As it's a list, it implements list items, instead of numbering, or a,b,c or squares or dots. there are branches that link back up, it denotes that it is the last item in the list, at that level. --Education does not equal common sense. (talk) 00:03, 26 June 2012 (UTC)Reply
Yes, but there's already an <li> at the appropriate level. We're just opening another li and doing... what with it? I'm almost positive that should be a span and not an li. --IznoRepeat (talk) 00:18, 26 June 2012 (UTC)Reply
Perhaps try it in the sandbox and make sure it works as intended?  Martin (MSGJ · talk) 11:24, 26 June 2012 (UTC)Reply
Keeping the syntax similar to the other list formatting templates is probably a good idea, so if you are willing to update the usages and documentation I would be happy to go along with that.  Martin (MSGJ · talk) 11:23, 26 June 2012 (UTC)Reply

Sub template names

[edit]

Before this template gets widely used, can we come up with better names for the branching functionality? "final branch", "branching", "final branching", I know what the template does and these names are confusing to me. I had originally considered names like: "branch" - "last branch" - "terminal branch", or something more descriptive. --Education does not equal common sense. (talk) 20:20, 26 June 2012 (UTC)Reply

No strong opinions on this one. If you can think of names which make sense to you, then please go ahead ;)  Martin (MSGJ · talk) 20:48, 26 June 2012 (UTC)Reply

How to get this working on a self hosted wiki?

[edit]

How do you get this working on a self hosted wiki? Do you just need to be on the latest version of the software? Is a plug-in of some kind needed?  Preceding unsigned comment added by 80.175.162.2 (talk) 12:50, 11 June 2015 (UTC)Reply

Mobile

[edit]

This doesn't display as intended on mobile. You just get normal bullets. Hairy Dude (talk) 01:59, 8 December 2015 (UTC)Reply

First branch for second level?

[edit]

Is there a way to have the first branch start at the second level and render like an upside down version of Template:tree list/final branch? Ergo Sum 05:29, 9 July 2017 (UTC)Reply

No see Wikipedia:Village pump (technical)/Archive 160#Mirror of template:Tree list/final branch -- PBS (talk) 20:27, 17 November 2017 (UTC)Reply

Tree list will break

[edit]

An uncommon but valid way to use the tree table is to have multiple nested empty branches, e.g.

  • Een tak op het eerste niveau
        • Een tak op het vierde niveau (hiervoor gaat het fout)
        • Nog een tak op het vierde niveau
      • Nog een tak op het derde niveau
      • De laatste tak op het derde niveau
    • Een tak op het tweede niveau
        • Een tak op het vierde niveau (hiervoor gaat het fout)
        • De laatste tak op het vierde niveau
      • De laatste tak op het derde niveau

However, this breaks under the new parser. See here. The problem is that asterisks are handled differently: Remex insert extraneous invisible empty <li>-elements which match the first-child CSS selector. Is this something that can be solved in CSS and/or wikicode? --bdijkstra (talk) 10:43, 28 March 2018 (UTC)Reply

Hmm, this is going to be a bit difficult.. Not sure if this is fixable while maintaining the current template structure. I created sandbox versions and testcases, to experiment but couldn't immediately figure something out. —TheDJ (talkcontribs) 10:41, 6 April 2018 (UTC)Reply
Well hopefully this crazy magic can save us.. Testcases with parser migration toolTheDJ (talkcontribs) 11:20, 6 April 2018 (UTC)Reply
Thanks! I've deployed this without ".mw-parsermigration-right" on nlwiki, where Remex is already active, and there it works fine (after a browser cache refresh). --bdijkstra (talk) 15:30, 6 April 2018 (UTC)Reply
Also live on en.wp now. —TheDJ (talkcontribs) 12:20, 10 July 2018 (UTC)Reply

A problem with long Tree list

[edit]

When there are more than 133 lines in one of the tree branches, the connecting line is disconnected.

Look at User:RimerMoshe/Tree list Template.

Is it possible to increase the number of rows to as many as possible? RimerMoshe (talk) 13:38, 28 December 2018 (UTC)Reply

Looks OK to me. --Redrose64 🌹 (talk) 22:48, 28 December 2018 (UTC)Reply
Redrose64, Please look for the line with the word "A problem" in User:RimerMoshe/Tree list Template. RimerMoshe (talk) 16:50, 30 December 2018 (UTC)Reply
I did. There is no problem there. --Redrose64 🌹 (talk) 23:35, 30 December 2018 (UTC)Reply
Redrose64, I see what appears in Figure 1. Do you see anything different? The line of the tree chart is broken in a place marked with a green circle in Figure 2. I expect the line to continue as indicated in red.
Thank you. RimerMoshe (talk) 08:20, 31 December 2018 (UTC)Reply
It might be a problem with your browser; mine is Opera 36. BTW I used a PNG file, not a JPG, per WP:WPSHOT - it's much smaller, 3 KB rather than 50 KB or larger. --Redrose64 🌹 (talk) 09:02, 31 December 2018 (UTC)Reply
Redrose64, My browser is Internet Explorer 11. RimerMoshe (talk) 11:19, 31 December 2018 (UTC)Reply
Microsoft. They always get it wrong. I've dropped a note at Wikipedia:Village pump (technical)#Experts of CSS handling in IE11 please. --Redrose64 🌹 (talk) 22:13, 31 December 2018 (UTC)Reply
FWIW: It looks fine to me in Firefox for Mac (logged in or logged out), but it is broken in Safari for Mac and Chrome for Mac (both logged out of WP). In the latter two, the line hooks right at "006", two lines below the "004 A problem" line, then resumes its vertical path just above "A second level branch", as in the screen shots above. – Jonesey95 (talk) 22:49, 31 December 2018 (UTC)Reply

I think the problem may be with the file "upload.wikimedia.org/wikipedia/commons/f/f2/Treeview-grey-line.png" that is used to draw the line. It is 5983 pixels long. One resolution to this problem may be to make this line longer, and then update Template:Tree list/styles.css with the new length. – Jonesey95 (talk) 23:07, 31 December 2018 (UTC)Reply

Jonesey95, we can also just document that the limit is about 130 entries. Especially since this seems a theoretical problem and not an article problem. —TheDJ (talkcontribs) 07:15, 2 January 2019 (UTC)Reply
TheDJ, This is not a theoretical question. See he:פורטל:דואר ובולאות/מילון מונחים/לפי נושא in the Hebrew Wikipedia (Still under construction). RimerMoshe (talk) 09:33, 2 January 2019 (UTC)Reply
RimerMoshe, We cannot endlessly make that image bigger. There will always be limits. Some lists will simply be too big. I also highly question the usability of that tree there. If I need to scroll so much, I have lost my sense of indentation anyways, so I don't see the value of using the tree for that specific example.
If anything, someone might try to rework the complete implementation of the template to not require an image as a single continuous line for multiple entries. (or preferably, avoid images all together and make the thing accessible to the blind at the same time... ), but that is a different endeavour. —TheDJ (talkcontribs) 09:42, 2 January 2019 (UTC)Reply
TheDJ, Thank you for the answer. I understand that there must be a limit, but I would be happy if the bar could be raised to a higher number of lines, such as 250 or 300 instead of 133. If this is not possible, of course I will have to adjust accordingly and change my list structure. RimerMoshe (talk) 09:55, 2 January 2019 (UTC)Reply

Untitled

[edit]
Nardog (talk) 13:34, 21 February 2020 (UTC)

background: url("//upload.wikimedia.org/wikipedia/commons/f/f2/Treeview-grey-line.png") no-repeat 0 -2981px;

Is not valid css.  Preceding unsigned comment added by 213.146.6.1 (talk) 13:09, 16 July 2019 (UTC)Reply

Could you provide a use case that will fail in the W3C CSS Validator? --bdijkstra (talk) 13:43, 21 February 2020 (UTC)Reply

Option to disable list items text wrapping

[edit]

The template does not seem to allow disabling of text wrapping for the list contents. The tree view, when its list items are text-wrapped, can sometimes look cluttered and/or confusing when list items contain dashes, which can make the dash look like a branch of the tree in small screens. I tried using {{nowrap}} and nbsp characters but the list items remain text-wrapped. Perhaps allowing an option/parameter to disable text wrapping might help? Sanglahi86 (talk) 20:55, 16 July 2022 (UTC)Reply

Collapsing

[edit]

Is it possible to add an element which can collapse one branch? BluesD (talk) 09:08, 28 April 2023 (UTC)Reply

Resolved
Just use the {{hidden begin}} on the branch. BluesD (talk) 09:39, 28 April 2023 (UTC)Reply
How exactly did you do it? {{hidden end}} seems to break one level of <ul> to me. The code
{{tree list}}
*Grampa
**Dad{{hidden begin}}
***Brother
***Sister
****Nephew
***Subject{{hidden end}}
**Uncle
**Aunt
{{tree list/end}}
Results in:
  • Grampa
    • Dad
      • Brother
      • Sister
        • Nephew
      • Subject
  • Uncle
  • Aunt


Makes aunt and uncle siblings to their father. I need an additional * to get what I want, i.e. grampa's children:
{{tree list}}
*Grampa
**Dad{{hidden begin}}
***Brother
***Sister
****Nephew
***Subject{{hidden end}}
***Uncle
***Aunt
{{tree list/end}}
  • Grampa
    • Dad
      • Brother
      • Sister
        • Nephew
      • Subject
    • Uncle
    • Aunt
Cato censor (talk) 14:43, 19 July 2024 (UTC)Reply
It turns out you only need {{hidden begin}}, not {{hidden end}}, but I'm afraid it could result in ill-formed HTML not rendering correctly in every browser. Any ideas? Cato censor (talk) 16:12, 19 July 2024 (UTC)Reply
  • Grampa
    • Dad
      • Brother
      • Sister
        • Nephew
      • Subject
  • Uncle
    • Cousin
  • Aunt
  • Tree list template breaks when used within another list that has "bodyclass = hlist" set

    [edit]

    When this template is nested below another list that specifies "bodyclass = hlist" it breaks this one completely.

    Broken example:

    Agowa (talk) 19:52, 29 March 2025 (UTC)Reply

    Why would you want hlist here? Simply omit it, and it works. --Redrose64 🌹 (talk) 20:20, 29 March 2025 (UTC)Reply

    Suggestion to switch from a huge image to CSS

    [edit]

    Since "image" approach breaks on big lists, maybe it would be nice to switch to CSS-only solution?

    For example, the solution below uses "::before", but nowadays almost everything supports it https://caniuse.com/css-gencontent


    .treeview li {
      display: block;
      position: relative;
      margin: 0;
      padding-left: 0.8rem;
      list-style-type: none;
      list-style-image: none;
      
    }
    
    .treeview ul {
      margin: 0;
      padding-left: 0;
    }
    
    .treeview ul li {
      border-left: 2px solid #ccc;
    }
    
    .treeview ul li:last-child {
      border-color: transparent;
    }
    
    .treeview ul li::before {
      content: '';
      display: block;
      position: absolute;
      top: -0.25rem;
      left: -2px;
      width: 0.7rem;
      height: 0.8rem;
      border: solid #ccc;
      border-width: 0 0 2px 2px;
    }
    
    .treeview > ul >li::before {
      border-color: transparent;
    }
    
    .treeview > ul >li {
      border-color: transparent;
    }
    

    Offsets might be different from current solution, but it should illustrate the idea. Urfiner (talk) 15:38, 8 May 2025 (UTC)Reply

    Template only extends down to 145 entries?

    [edit]

    At Semitic languages#Detailed list, I have noticed that the tree lines under "Semitic" & "East Semitic" only extend down 145 lines, and doesn't reach the full depth that it should go to. Anyone knows how to fix that? CX Zoom[he/him] (let's talk • {CX}) 17:30, 6 June 2025 (UTC)Reply

    @CX Zoom: I think that it's restricted by the vertical height of c:File:Treeview-grey-line.png. See #A problem with long Tree list above. --Redrose64 🌹 (talk) 12:34, 7 June 2025 (UTC)Reply
    Thanks. Does Urfiner's CSS solution work on long lists? I think a pure CSS solution would be preferable over images anyway, because images are typically heavier to load however small in size it might be. CX Zoom[he/him] (let's talk • {CX}) 20:02, 14 June 2025 (UTC)Reply
    It works on long lists on my private wiki, I would be glad to polish it for Wikipedia if any issue appear. Urfiner (talk) 11:57, 11 July 2025 (UTC)Reply
    It gets the job done (line extends all the way down) but the "L" shapes don't align properly with the "|" lines, see Special:Diff/1300001109#Detailed list. CX Zoom[he/him] (let's talk • {CX}) 18:20, 11 July 2025 (UTC)Reply

    Template-protected edit request on 14 September 2025

    [edit]

    Change the comment

    
    /* first line here deals with new situation after RemexHTML switch,
     * where emptyline cause the first child to become the 2nd child. Such a mess
     */

    to

    
    /* the 1st line here deals with a new situation after the RemexHTML switch,
     * wherein li.emptyline inserts an additional .mw-empty-elt element before
     * the .emptyline element, causing the 1st child to become the 2nd child
     */

    and add the following comment at the end:

    /* the dimensions of the image at the url are 21px by 5983px
     * the amount of the image that is visible adjacent to any single line is 21px by 21px
     ** positioning the image at x = 0px shows the full width of the image from 0px to 21px
     ** positioning the image at y = 9px shows the portion of the image from a height of -9px to 12px, i.e. 9 empty pixels and the first 12 image pixels
     ** positioning the image at y = -2981px shows the portion of the image from a height of 2981px to 3002px, the middle 21 pixels of the image
     ** positioning the image at y = -5971px shows the portion of the image from a height of 5971px to height+9px, i.e. the last 12 image pixels and 9 empty pixels
    
    • /

    I edited the sandbox version of this page to have the above comments at this permalink, so you could also just replace the entire content of the page with the content of the sandbox version I linked. Indigopari (talk) 00:33, 14 September 2025 (UTC)Reply

    The point of these changes is to improve the on-page documentation, especially for how the specified pixel coordinate numbers were calculated and what they mean. Indigopari (talk) 00:34, 14 September 2025 (UTC)Reply
     Done Sohom (talk) 16:48, 29 November 2025 (UTC)Reply

    The issue with long lists

    [edit]

    As previous discussions have mentioned there is a highly noticeable issue with this template when it is used together with lists that exceed a certain length. This issue is present on multiple mainspace articles and there doesn't seem to be any way for users to fix this. I have noticed however that the template is fully capable of displaying a line that is longer than the lines it starts cutting off prematurely in long lists (see Template:Tree list/testcases), and it does this only with the lowest tier that a line is currently running for, if that makes sense. For example, if there is a level three entry that exceeds the limit the level two and level one lines will get prematurely cut off but the level three line will continue as usual past the length at which the higher level lines got cut off.

    I've got no idea how to create a fix for this myself as it involves messing about with the .css so I'm requesting some assistance in solving this one and for all. Because man do I really not want to rework the entire 2026 Iran war order of battle article because a single tree lines is a bit too long for the template to handle.
    Maltazarian parleyinvestigate 19:26, 29 March 2026 (UTC)Reply

    I don't see any display issues with the "Really long demonstration tree" test case that you have added. Please be more specific about the problem. I suggest changing the text on the line or lines where problems exist so that they are easy to pick out. – Jonesey95 (talk) 22:44, 29 March 2026 (UTC)Reply
    I've done so now. They are near the very bottom of the tree. The issue has to do with the lines that run along the left side of the entries in the tree.
    Maltazarian parleyinvestigate 22:51, 29 March 2026 (UTC)Reply
    This is #Template only extends down to 145 entries? and previous threads. --Redrose64 🌹 (talk) 08:23, 30 March 2026 (UTC)Reply
    Yes, I read those threads before creating this one. They are the previous discussions referred to in the first sentence of my original post. I guess I could have responded to one of them? But I'd rather just make a new one for visibility's sake. ⹃Maltazarian parleyinvestigate 08:52, 30 March 2026 (UTC)Reply
    I don't see any breaks in the lines in Firefox for Mac OS when I am logged in, but I see it in Safari (Mac OS) when logged out or logged in, and in Brave (Mac OS) when logged out. It appears that nobody has addressed this problem in the sandbox yet. For what it's worth, the breaks do not happen at the bold lines in the test cases; they happen for me at a different height in each browser. – Jonesey95 (talk) 13:07, 30 March 2026 (UTC)Reply
    I think there was an attempt to address the problem by @Urfiner a little under a year ago. As for the bolded text well that's unfortunate, I suppose I will get rid of it.
    Maltazarian parleyinvestigate 17:49, 30 March 2026 (UTC)Reply
    To clarify the issue, very long vertical grey lines can be cut off like the left line in File:Tree list problem temp 02.jpg. The cutoff point depends on how many pixels a given browser uses per text line. The vertical lines are made with File:Treeview-grey-line.png which is 21 × 5,983 pixels (width × height), but only 216 bytes. Template:Tree list/styles.css uses the original upload https://upload.wikimedia.org/wikipedia/commons/f/f2/Treeview-grey-line.png directly, so we don't rely on MediaWiki ability to resize large images. Is there a problem in just making it much taller? If 216 bytes increases a little then it's still practically nothing. If there is a potential problem for a limited number of readers (is there?) then we could add a |long=yes parameter to {{Tree list}} and pick another CSS file with another image in that case, so it works as now on normal lists and only uses the taller "problem" image on long lists. PrimeHunter (talk) 16:06, 27 April 2026 (UTC)Reply
    I was considering straight up doing that, but when I went through the previous discussions there was some opposition to the idea. I'm not too familiar with these kinds of things so I don't know if there would be an issue or not, but I can't see why there would be. The examples of lists breaking that I've seen don't do so by much, so making it longer might just solve the issue in practice for now. ⹃Maltazarian parleyinvestigate 20:12, 27 April 2026 (UTC)Reply
    I attempted a CSS-only solution that doesn't rely on a fixed-height image at Template:Tree list/sandbox/styles.css. It's a bit more faithful to the current template's appearance than Urfiner's version above, but like theirs skipping directly from a first-level to a third-level item using {{Tree list/branching}} doesn't work and I'm not sure how to solve that. --Ahecht (TALK
    PAGE
    )
    16:26, 27 April 2026 (UTC)Reply
    @Jonesey95, Maltazarian, PrimeHunter, Redrose64: I think I cracked it. Please check out the suite of /sandbox templates and let me know if there are any corner cases that I missed. --Ahecht (TALK
    PAGE
    )
    13:34, 28 April 2026 (UTC)Reply
    Praise be! I can see it at Template:Tree list/testcases and it does appear to be working. There are some tiny artifacts I can see; some of the lines have slightly greater thickness than others, and near the very end of a vertical line, presumably at the point it connects to the final horizontal line it is connected to, there is a near imperceptible white line cutting across it. I only barely noticed the latter at the bottom of the first branch and had to take a screenshot and zoom in to make sure I wasn't seeing things. I took screenshots of lower level branches and did the same and it appears they also have it. These are minor details though (but the thickness thing should be addressed) and the important thing is that you've got the mechanics of it working. ⹃Maltazarian parleyinvestigate 13:48, 28 April 2026 (UTC)Reply
    @Maltazarian Could you put the screenshot up on Commons? I don't see anything like that on my end, so it may be browser dependent. --Ahecht (TALK
    PAGE
    )
    15:10, 28 April 2026 (UTC)Reply
    Yeah give me a moment. ⹃Maltazarian parleyinvestigate 15:37, 28 April 2026 (UTC)Reply
    Ah no I just tried to do that and noticed at first hey there aren't any issues here, so I took a screenshot of it and zoomed in and... nothing. Then I zoomed in on the browser and took a screenshot, and there it was. It's got to do with the way it gets scaled up. Try that and see if you can see it. ⹃Maltazarian parleyinvestigate 15:50, 28 April 2026 (UTC)Reply
    @Maltazarian I'm still unable to replicate that using browser zoom in both Chrome and Firefox on Windows. What browser/OS are you seeing this in? --Ahecht (TALK
    PAGE
    )
    03:35, 29 April 2026 (UTC)Reply
    I just went to look again and it's not doing it anymore. Thought your small edit to the sandbox template might have done something but I tested and nope. I genuinely have no idea what was going on. Like it looks perfectly fine for me right now. I guess I have to chalk it up to strangeness on my end. Either way, this is starting to feel like I'm chasing ghosts, so I don't think there is anything to worry about. I think you can go ahead and make the sandbox version the live version of the template. ⹃Maltazarian parleyinvestigate 13:24, 29 April 2026 (UTC)Reply
     Done --Ahecht (TALK
    PAGE
    )
    17:48, 29 April 2026 (UTC)Reply
    @Ahecht: Your edit broke the military conflict boxes as they now have a dot with associated countries outside the infobox. I would highly advise reverting this as this affects hundreds of pages relating to war and military conflict. MarioProtIV (talk/contribs) 21:27, 29 April 2026 (UTC)Reply
    uh oh ⹃Maltazarian parleyinvestigate 21:37, 29 April 2026 (UTC)Reply
    @MarioProtIV Looks like I have a few more testcases to add. I'll revert shortly. --Ahecht (TALK
    PAGE
    )
    21:37, 29 April 2026 (UTC)Reply
    @MarioProtIV Reverted. Can you give me an example of a page that misbehaved with the new CSS? --Ahecht (TALK
    PAGE
    )
    21:40, 29 April 2026 (UTC)Reply
    2026 Iran war is the most immediate example given how it’s currently ongoing and uses the template. MarioProtIV (talk/contribs) 21:43, 29 April 2026 (UTC)Reply
    That's funny. The entire reason I requested this fix in the first place is due to 2026 Iran war order of battle. ⹃Maltazarian parleyinvestigate 21:44, 29 April 2026 (UTC)Reply
    @MarioProtIV, Maltazarian 2026 Iran war was one of the pages I checked, and I didn't see anything amiss. I put the infoboxes from both 2026 Iran war and War of the Fifth Coalition at User:Ahecht/sandbox8, but modified to use {{tree list/sandbox}}. Do you see the issue there? If not, it may have been a caching problem. --Ahecht (TALK
    PAGE
    )
    21:51, 29 April 2026 (UTC)Reply
    Yes the issue is there. You changed it on the main template back to what it was before and that’s why it didn’t look like that to you. Hope that makes more sense. MarioProtIV (talk/contribs) 22:22, 29 April 2026 (UTC)Reply
    @MarioProtIV Can you upload a screenshot of the issue you're seeing on User:Ahecht/sandbox8 to Commons? I'm not seeing any difference between it and User:Ahecht/sandbox9 (which uses the main tree list template which, as you said, was changed back to the old version). --Ahecht (TALK
    PAGE
    )
    13:29, 30 April 2026 (UTC)Reply
    @Ahecht: here's proof of the issue with yours at the moment: File:Tree list infobox issue.png - and on mobile its even more noticable with the bullet even more on the outside. MarioProtIV (talk/contribs) 18:17, 30 April 2026 (UTC)Reply
    @MarioProtIV Ahh, I see the problem. Those stray bullets don't show up when using the default Vector 2022 and Minerva Neue skins, only in older skins such as legacy Vector or Monobook. Check my latest version at User:Ahecht/sandbox8, which should fix the issue. --Ahecht (TALK
    PAGE
    )
    19:45, 30 April 2026 (UTC)Reply
    Much better, thank you. MarioProtIV (talk/contribs) 19:47, 30 April 2026 (UTC)Reply
    War of the Fifth Coalition should be an example. ⹃Maltazarian parleyinvestigate 21:43, 29 April 2026 (UTC)Reply
     Done I've re-implemented the CSS-only version with some bug fixes. I probably won't have much time for Wikipedia in the next 10 days or so, so if any more corner-cases come up where this change has broken something, any admin or template editor has my permission to go ahead and unconditionally revert. --Ahecht (TALK
    PAGE
    )
    20:42, 30 April 2026 (UTC)Reply
    [edit]

    Tree lists which happen to be placed next to infoboxes, as is the case in Mbam languages, seem to break the ability to click links within the infobox that happen to be on the same lines as part of the tree list. Arctic Circle System (talk) 07:31, 25 May 2026 (UTC)Reply

    @Arctic Circle System: This edit will fix it in modern browsers, i.e. those that support the max-content value on the width: property. See compatibility chart. --Redrose64 🌹 (talk) 17:16, 25 May 2026 (UTC)Reply
    Thank you. I will check it on desktop Firefox later and get back to you. Arctic Circle System (talk) 18:44, 25 May 2026 (UTC)Reply