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.
This template is within the scope of WikiProject Lists, an attempt to structure and organize all list pages on Wikipedia. If you wish to help, please visit the project page, where you can join the project and/or contribute to the discussion.ListsWikipedia:WikiProject ListsTemplate:WikiProject ListsList
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 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 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
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
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
Latest comment: 14 years ago2 comments2 people in discussion
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
Latest comment: 11 years ago1 comment1 person in discussion
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
Latest comment: 8 years ago5 comments2 people in discussion
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 (talk • contribs) 10:41, 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
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.
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
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 (talk • contribs) 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
Latest comment: 4 years ago1 comment1 person in discussion
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
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 • {C•X})20:02, 14 June 2025 (UTC)Reply
/* 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
Latest comment: 3 months ago32 comments6 people in discussion
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
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
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
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
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
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
@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
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 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
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
Latest comment: 2 months ago3 comments2 people in discussion
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