This is the talk page for discussing Clade and anything related to its purposes and tasks.

Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: 1Auto-archiving period: 3 months

	This template does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:
Tree of Life This template is within the scope of WikiProject Tree of Life, a collaborative effort to improve the coverage of taxonomy and the phylogenetic tree of life on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Tree of LifeWikipedia:WikiProject Tree of LifeTemplate:WikiProject Tree of Lifetaxonomic

This template was considered for merging with Template:Cladogram on 2018 April 24. The result of the discussion was "do not merge".

Documentation is at Template:Clade/doc. Please check Template:Clade/doc#Limitations before raising a problem here.

---

I've noticed several clade diagrams have HTML entities like &nbsp and &emsp at the beginning and end of labels to prevent the vertical lines from being too close to the words. I've been removing them on the theory that taking up less horizontal space is better, but this was reverted in at least one case Special:diff/1258412212 by Cougroyalty. If this space is desirable, I think it would be a lot cleaner and more consistent if it was added by the module rather than having to add it on every page that uses the module. -- Beland (talk) 17:19, 19 November 2024 (UTC)[reply]

I agreeing doing it through the template would be better for consistency. The template uses WP:TemplateStyles and does add a small amount of CSS padding (0.15em) on the label. More padding would be desirable on many simple cladograms, but the problem is that it's not always desirable. There are many large cladograms where horizontal spreading is an issue due to long taxon names, especially with the new skins where overflow into the margins is problematic. In many cases the HTML space entities will have been added before the CSS styling was added through TemplateStyles so adding more automatic spacing would add to that already there. We have to consider backward compatibility. I'll try and do a few tests and look at a bit more automatic padding. A search to find how often these spaces entities are used might also be helpful.  —  Jts1882 | talk  18:12, 19 November 2024 (UTC)[reply]

I wouldn't worry about backward compatibility; I can run a script to semi-automatically remove HTML entities if we're increasing the CSS padding. I've just kicked off a database scan to see how often this happens. Do you have an example of a large diagram that has problematically long names? We could make those multi-line if there's room. -- Beland (talk) 00:09, 20 November 2024 (UTC)[reply]

It looks like there are about 1570 articles using {{clade}} with HTML entities in at least one label value (including the articles I've just removed the entities from). That should be feasible to clean up in a day or two, if we decide to go ahead with that. I can share the list of articles if anyone finds that useful. -- Beland (talk) 00:24, 20 November 2024 (UTC)[reply]

@Cougroyalty:. How much space at the ends of the label do you think is necessary? I think the em-space (" ") in the Crocodilia is excessive. Incidentally, if you want to set the length of the labels for alignment, there is a |length= parameter.  —  Jts1882 | talk  11:49, 20 November 2024 (UTC)[reply]

OK, I did some testing with some spaces. I agree that the em-space (" ") is a bit excessive, but can be nice in a small simple cladogram. I tried with a single nb-space (" "), and I think that looked fine. I think a good example of the spacing issue is if you compare diffs at Crocodilia, and in the cladogram specifically look at Alligatoridae and Longirostres. Without the spaces, they just look so cramped. Also, if you look at the unnamed subclades within Crocodylidae, they also look cramped without any spaces. You can even see in the cladogram example directly above this section of the talk page, they added nb-spaces (" "). Maybe there is a way this clade template can just automatically add a single leading and ending space for each line? Cougroyalty (talk) 16:23, 20 November 2024 (UTC)[reply]

I believe a non-breaking space is one en wide, so adding that would be the equivalent of adding .5 em in CSS instead of or in addition to the current .15 em. -- Beland (talk) 18:46, 20 November 2024 (UTC)[reply]

I think the non-breaking space is too large for the default. I've increased the padding to 0.25, which I think gives adequate spacing without stretching some of the larger cladograms. Is this sufficient or should it be increased a bit more?

As an alternative to using lots of spaces, the |length= parameter can be used to increase the spacing and to align labels and terminal taxa. As an example, I edited Crocodilia with Special:diff/1258741340. I've reverted the change as it was for discussion purposes.  —  Jts1882 | talk  10:38, 21 November 2024 (UTC)[reply]

I've started removing &nbsp and &emsp from the articles using this template, on the assumption that the built-in padding is now adequate (or could be increased in the future if anyone wants) and that consistent appearance is desirable. -- Beland (talk) 23:37, 30 November 2024 (UTC)[reply]

I'm also removing nbsps between words and the advice to use them; this should be taken care of by "nowrap" CSS added as noted in the #Non-breaking hyphens thread. -- Beland (talk) 03:27, 5 December 2024 (UTC)[reply]

I have finally completed this task. If anyone notices any new or remaining systematic problems, feel free to ping me; I can do another database scan. -- Beland (talk) 11:28, 7 February 2025 (UTC)[reply]

Maybe it is just me, but I think some cladograms are a bit worse off - especially the cladograms that have a lot of nested unnamed clades, causing the vertical lines to stack close together making it harder for the eye to follow. Example: the cladogram I added to a lot of the Erythrolamprus vine snakes, such as at Erythrolamprus aesculapii. Comparing the 'before' and 'after', I think the previous version looks better. This is a vertically tall cladogram that benefits from some extra horizontal space. I just think that sometimes an extra space is helpful, and I'm wondering why we are trying to get rid of all of them. I'm curious if anyone shares this opinion, or if I am alone in this. Thanks. Cougroyalty (talk) 17:30, 7 February 2025 (UTC)[reply]

@Cougroyalty: I certainly agree that the 'before' is better than the 'after'. Peter coxhead (talk) 19:56, 7 February 2025 (UTC)[reply]

Are you looking at these on a wide desktop monitor or on a mobile phone? Over half of readers are on mobile these days. Looking at that example, in the "before" version some of the names wrap to four lines on my phone, and in the "after" they only wrap to two. As to which looks better, I have to shrug. Perhaps if you're used to them being a certain way, you come to prefer that way, so it might be useful to get opinions from fresh eyes.

The intention behind removing nbsps was to allow buffer space to be controlled by CSS, which is consider better because that separates content from presentation. That can be important when there is a diversity of media that content is being presented through; CSS can make diagrams look different on different screens (and on paper) as needed. It also makes the wikitext a lot easier to read, and easier to maintain since page editors shouldn't have to worry about whitespace considerations.

If there's a consensus that the current state of the template results in overly-crowded lines, I would recommend adjusting the buffer space in CSS so there's a consistent look across articles. But carefully - putting in too much horizontal space can cause horizontal scrolling on narrow screens, which is quite a bad experience. Conversion to vertical text can mitigate that for very wide diagrams, as with {{vert-label}} on Diapsid#Relationships. That's also a good example to look at when deciding how much buffer space to add. -- Beland (talk) 20:35, 7 February 2025 (UTC)[reply]

@Cougroyalty: Agreed that example of yours is too scrunched up. You can use |length= to set the width of the labels, e.g. |length=0.7em. I think the current default is 0.2em.  —  Jts1882 | talk  13:09, 8 February 2025 (UTC)[reply]

Template:Clade/doc#Adding vertical bars and brackets recommends using a non-breaking space to avoid text colliding with vertical bars. This should just be done in CSS to make the template call easier to read, and so this spacing can't be forgotten. I'm removing non-breaking spaces from all using articles at the moment (to avoid double-padding as mentioned in the thread above). It's difficult to systematically distinguish between padding that would be extra vs. needed, so the padding that's currently needed (but shouldn't be) is going away.

While we're adding padding to the right of leaf note labels, it might be nice to add some to the left as well, as they are awfully close to the horizontal lines that lead to them. -- Beland (talk) 03:18, 5 December 2024 (UTC)[reply]

Unfortunately I don't see how adding space before the vertical bars can be done in CSS. The obvious thing is to add similar padding to that used for the labels to the terminal text. However, because of the way the system uses nested tables to build the cladogram lines, this padding would separate the tables and add gaps in the cladogram lines.

On the labels, the same padding (0.25em) is added to the left and right of the labels. Edit. Oh, I think I misunderstood, you mean to the left of terminals. This is the same answer as above to separate the vertical bar. It will add gaps to the cladogram structure. We need a soution where the padding is only added to terminals and not when another clade template, i.e. when |1=taxon name and not |1={{clade ...}}.  —  Jts1882 | talk  08:03, 5 December 2024 (UTC)[reply]

I found a solution and implemented it - add padding to the p element under classes clade-leaf and clade-leafR. -- Beland (talk) 09:16, 5 December 2024 (UTC)[reply]

That looks a good solution. I was looking for a way to distinguish terminals and nested templates. That p element is added by the Wikimedia software when a table cell has plain text. I checked the other skins and mobile and they all behave the same way.  —  Jts1882 | talk  09:51, 5 December 2024 (UTC)[reply]

I was thinking some vertical text might help narrow some wide clade diagrams. I have created {{vert-label}} to use for this purpose. As an example, I've used it on the last clade diagram on Diapsid#Relationships.

BTW, another solution to prevent horizontal scrolling in a lot of cases might be to draw the diagrams from top to bottom instead of left to right. -- Beland (talk) 08:32, 5 December 2024 (UTC)[reply]

Not sure I understand. The labels would still have the same width, regardless of the order. Also the output when doing the cladograms top to bottom is supposed to be very ugly on Apple devices.  —  Jts1882 | talk  11:22, 5 December 2024 (UTC)[reply]

Just because the words have the same width doesn't mean the overall diagram has the same width, because they are arranged differently. For example, below, A is wider than B:

A.)
                  --- Species number one
Clade number one  |
------------------|                  --- Species number two
                  | Clade number two |
                  -------------------|                    --- Species number three
                                     | Clade number three |
                                     ---------------------|
                                                          |
                                                          --- Species number four
B.)
              | Clade number one
        -------------
        |           |
Species number one  | Clade number two
                    |
           ---------------
           |             |
 Species number two      | Clade number three
                         |
                      -----------------------
                      |                     |
            Species number three   Species number four

Not sure what you mean by "supposed to be ugly", but the appearance should be more or less the same across browsers if CSS is used correctly. -- Beland (talk) 17:09, 5 December 2024 (UTC)[reply]

Some of the examples in Template:Clade/doc would look better if {{clade example}} set "white-space: revert;" on the "pre" tag it's wrapping code in, but this is hidden in the guts of a Lua module and I'm not sure how to do that. I'm also not sure if the "pre" is really needed if there's a "syntaxhighlight" there. -- Beland (talk) 09:35, 5 December 2024 (UTC)[reply]

I'm note familiar with "white-space: revert;". What does it do? I tried adding it to the table cell CSS and saw no difference. Where should I use it?

@Jts1882: "revert" is explained (supposedly) here, but it's beyond my understanding of CSS. Peter coxhead (talk) 16:59, 5 December 2024 (UTC)[reply]

The syntaxhighlight was added to some of the examples relatively recently. The "pre" is needed for older uses. I did try using syntaxhighlight instead of pre in the module. I can't remember what happened, but commented out the change which suggests it didn't work and that I planned to revisit it.  —  Jts1882 | talk  11:34, 5 December 2024 (UTC)[reply]

From what I can tell, Mediawiki turns "syntaxhighlight" into an outer "div" and "pre", so adding another "pre" would be weird. -- Beland (talk) 17:12, 5 December 2024 (UTC)[reply]

Ah, looks like I forgot to save some of my changes. I'm looking at the example that uses "bar1=midnightblue". After I removed the spurious divs and set the font size back to 100%, the code in the left column is wrapping awkwardly. Setting "white-space: pre;" on the "pre" tag also works. I guess this is actually the one created by syntaxhighlight? I think adding something this to the right .css file should do that:

.mw-lang-highlight-wikitext pre {
  white-space: pre;
}

Though I would add a class to the {{clade example}} table so that change is more narrowly scoped and doesn't interfere with other "pre" elements elsewhere on the site. -- Beland (talk) 18:42, 5 December 2024 (UTC)[reply]

For clarification, with {{clade example}} the pre tag was only used when |codeN= contained the clade code wrapped in nowiki tags. This avoided duplication and allowed the clade code be reused, wrapped in the pre tag to display the code, and rendered to display the cladogram. In the documentation, only example 5 used this method. All the other examples displayed the code and output as given in the respective |codeN= and |outputN= parameters, using pre or syntaxhighlight as supplied to the parameters.

I've changed the reuse option (i.e. |codeN=<nowiki> code </nowiki>) to display the code with syntaxhighlight instead of pre.  —  Jts1882 | talk  08:10, 6 December 2024 (UTC)[reply]

I should add that none of the examples used in Template:Clade/doc use this nowiki method for reusing the code, so the module is not wrapping any of the code examples with pre or syntaxhighlight.

@Beland: I also edited the midnight blue example to avoid squeezing the output column. I've since noticed that this effectively reverted one of your edits. I think it looks better with the padding.  —  Jts1882 | talk  08:37, 6 December 2024 (UTC)[reply]