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 articles
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]
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]
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]
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]
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]
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.
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]
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 (talk • contribs) 07:15, 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 (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]
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]
! --UnQuébécois (talk) 16:54, 22 June 2012 (UTC)
Figure 1
Figure 2
Moved from Template talk:Tree list/styles.css
Resolved