Module talk:Clade

Problem in Firefox

@Peter coxhead and TheDJ: There is an issue in cladograms made with clade when using Firefox. The bottom branch of a set of child nodes is sometimes missing the vertical line, but not always. For example, see Canidae#Phylogenetic relationships, where a clade of jackals and some foxes are left marooned from the tree. The cladogram appears fine in Chrome and Edge.

The issue seems to arise from a change made to the CSS styling in July, which replaced the deprecated margin and cellspacing parameters.
The cladogram can be fixed by using the prototype cladeN (which still uses cellspacing and margin) on the relevant nodes, so it is not due to a change in how Firefox renders the table HTML.
If I change the line thickness to 2 the line missing line appears as single thickness while the others are double thickness as expected.

I don't want to revert the change to use the deprecated code as this would be a retrograde step, but I am at a loss as to how to fix the problem. Any ideas? Jts1882 | talk 10:45, 25 November 2017 (UTC)[reply]

It looks like the addition of "border-collapse:collapse;" to the table is the cause. Removing it restores the line using Inspect Element in the browser. I assume this means that the cell border, which draws the line, is collapsed with the row border that has zero thickness. Jts1882 | talk 11:37, 25 November 2017 (UTC)[reply]

We had an edit clash.

Using Firefox on a Mac, the lines don't disappear, but they are extra thin.

CSS border-collapse was known not to work properly in Firefox in the past (see e.g. here) but I thought this was fixed. It appears that in some cases it isn't. Peter coxhead (talk) 11:49, 25 November 2017 (UTC)[reply]

Yes, that fixes it. Clearly Firefox still has a problem with border-collapse. Good work! Peter coxhead (talk) 12:38, 25 November 2017 (UTC)[reply]

Templatestyles and other changes

WP:TemplateStyles was enabled today. This allows custom CSS styling to be used with templates. I have implemented this on the {{cladeN}} and {{cladeNx}} templates. The latter implements {{cladex}} using the Lua module. The advantages seem to be:

Cleaner and easier to read styling code. Only the borders are used in the inline styles now
Possibility of custom styling for mobile view.
- The broken bar brackets in {{cladex}} cladograms in the mobile view behave differently in the module version ({{cladeNx}}). The spaces between the bars are no longer there, but the vertical alignment is slightly off in some views. Reduce the size (with Ctrl-minus) and they realign. This is due to border-collapse (alignment is restored when removed with the Inspect Element tool). Jts1882 | talk 10:26, 20 July 2018 (UTC)[reply]
Potential to modify for different skins (this is a planned update for templatestyles).
Smaller transclusion size. It looks like the size for large templates is reduced 25-33%

Examples can be found here:

I should add that I have been testing this using my custom.css, anticipating it's introduction today. It looks very promising although a few minor issues with the CSS need fixing. The alignment of dummy clades (those with a single element) is one issue.

I have also made a few other changes to the module code. It now runs a preprocessing loop to get the number of child branches. This means the final cell (containing the sublabel) can be place at the end of each child element rather than at the beginning of the next one or the end of the main loop as before. I've also cleaned up the module code of a lot of redundant commented out code that I left to show how things had changed from the old template language version. Now I understand what is going on I have replaced this with more informative comments.

Any comments or suggestions would be welcomed. Jts1882 | talk 12:31, 19 July 2018 (UTC)[reply]

TemplateStyles, the nowiki tag and extra whitespace lines

The insertion of TemplateStyles in the template caused a small downward shift of branches. This was immediatedly apparent on dummy clades (a clade with one branch introduced for format the horizontal spread) (see top branch in User:Jts1882/sandbox/test/Passeriformes). The properties were as follows:

Adding the TemplateStyles tag introduces a downward shift of about 0.3em. This is not very obvious in the clades with two or more branches.
It doesn't occur if the nowiki statement is removed from the template.
The nowiki statement introduces the following before the clade table. The class sets style display:none.

<p class="mw-empty-elt"></p>

Templatestyles inserts a link element in this paragraph tag (see below), but crucially removes the no display class.

<p><link rel="mw-deduplicated-inline-style" href="mw-data:TemplateStyles:r850993194"></p>

Thus it appears that the display of this paragraph causes the shift. If the "mw-empty-elt" class is added using the browser Inspect Element tool the shift is removed.

The solution might be using the module to add the equivalent of what is added by the nowiki tag. Jts1882 | talk 15:41, 19 July 2018 (UTC)[reply]

Adding a p tag with the "mw-empty-elt" class inside the module appears to fix the issue. Now need to recreate the extra line problem that required the nowiki tag addition, to see if this is an appropriate solution.

Conclusion The nowiki tag in the template is not necessary when using TemplateStyles. It turns out that prefixing the invoke with TemplateStyles has the same effect as the nowiki tag and prevents the insertion of the unexpected whitespace. Jts1882 | talk 06:55, 20 July 2018 (UTC) .[reply]

The future of cladex

Technical discussion between two editors about merging the functionality of {{Clade}} and {{Cladex}}, now done.

I have implemented a module version of {{cladex}} in {{cladeNx}}. This had the benefit of fixing the breaks in the right hand bars in the mobile view. Some examples and links to the originals can be found in User:Jts1882/sandbox/test/cladex.

The crucial difference in cladex was including the width:100%; style. This meant that it would stretch the cladogram across the page unless used in container (e.g. {{cladogram}}, {{bar label}}). The mixing of the {{clade}} and {{cladex}} templates was often a cause of confusion.

One solution was to use width:100%; in both and just add width:auto; the outer clade element. This works well enough as the outer element usually had some styling for line-height and font-size. The problem is that this would widen all the exisiting cladograms to fill the page.

TemplateStyles allows a CSS solution. It allows width:auto; to be set for the outer clade only. The CSS selector can set width:100%; on all table.clade elements contained in a table.clade element. Using this approach clade behaves like cladex except for the outer clade element. I think this is the desired solution. Jts1882 | talk 13:34, 21 July 2018 (UTC)[reply]

@Peter coxhead:. Can you please have a look at this and confirm that it works as I've stated. I've tested the new versions in Firefox, Chrome and Edge in Windows 10, but don't have any Apple devices. Jts1882 | talk 15:59, 21 July 2018 (UTC)[reply]

@Jts1882: I've discovered to my cost in the past that testing {{clade}}, {{tl|cladex}] and {{barlabel}} is tricky: they work on all the examples you try and then someone finds a new case where they don't!

I globally changed "cladex" to "cladeNx" at User:Peter coxhead/Test/Clade. Using Firefox, with one exception, {{cladeNx}} appears to work correctly where I would expect it to. I put back the one example where there's an issue. Compare User:Peter coxhead/Test/Clade#Petter's Example with cladex and User:Peter coxhead/Test/Clade#Petter's Example with cladeNx.

{{cladeNx}} cures the extra blank line between the terminals "Medoevia" and "Koharolepis".
However, it aligns the four terminals starting with "Jarvikina" wrongly – it looks as if it centres them rather than left-aligning them.

This is because it is mixing {{cladeNx}} and {{clade}} (which doesn't use TemplateStyles). If you use {{cladeN}} instead of {{clade}} (i.e. both using TemplateStyles) this works. In particular the table cell with Jarvikina inherits the CSS styling from table.clade td rather than using the default left align expected when using {{clade}}. This mixing caused a number of strange formatting effects, but as long as everything uses TemplateStyles it seems to work. Jts1882 | talk 08:57, 22 July 2018 (UTC)[reply]

Given that the aim has to be to get rid of the need to use both {{clade}} and {{cladex}}/{{cladeNx}} and just use {{clade}}, I tried replacing {{clade}} by {{cladeNx}} everywhere on the page. The only problem was at examples like the one I've left at User:Peter coxhead/Test/Clade#Example 0. When I mix {{clade}} and {{cladeNx}}, it works fine, but when I use only {{cladeNx}}, the vertical bar is in the wrong place.

This is because {{cladeNx}} adds the width:100% and forces the {{cladex}} behaviour, which was why it needed to be used in a container or with an outer {{clade}} element. If you use {{cladeN}} for all elements the bar is in the right place as it will use width:auto for the outer element and width:100% for the rest, whick mimics the effect of a cladogram using {{clade}} for the first element and {{cladex}} for the rest. I think this is the correct behaviour for backward compatibity. {{cladeNx}} will provide backward compatibility with {{cladex}} and cladograms using only {{cladex}} will be stretched, i.e. existing cladograms using {{cladex}} should appear the same way. The difference comes when {{cladeN}} is used in place of {{clade}} as now the bars are correctly placed and there should be no need to use mix templates. Jts1882 | talk 08:57, 22 July 2018 (UTC)[reply]

Browser tests (latest MacOS versions in each case)

The comments above apply to Firefox.
Chrome: at User:Peter coxhead/Test/Clade#Petter's Example with cladeNx, there's a very slight break in the right hand bar between the terminals "Medoevia" and "Koharolepis", otherwise it appears to be the same as Firefox (including the same alignment issue).
Opera: at User:Peter coxhead/Test/Clade#Petter's Example with cladeNx, it introduces another (i.e. extra) slight break in the right hand bar between the terminals "Osteolepis" and "Megalichthys"
Safari: as is well known, it belongs to the group of browsers discussed at Template:Clade#Browser differences that lay out tables with a different algorithm. Except for this, it has only the same issue as Firefox.

If you don't see the issues I've noted above with your system and browsers, let me know and I'll upload screen shots. Peter coxhead (talk) 08:16, 22 July 2018 (UTC)[reply]

@Peter coxhead: See two comments above addressing non-MacOS cases. I cannot test these MacOS examples, but I think the problems you see in those examples are due to mixing {{cladeNx}} and {{clade}}. Hopefully the issues will be fixed if you use {{cladeN}} instead of {{clade}} so all elements use TemplateStyles. Jts1882 | talk 08:57, 22 July 2018 (UTC)[reply]

@Jts1882: Yes – User:Peter coxhead/Test/CladeN uses only {{cladeN}} and works fine under MacOS in Firefox, Safari, Opera and Chrome. Great!

So, what's the next move? Why not redirect {{clade}} and {{cladex}} to {{cladeN}}, given that two variants aren't needed now? Peter coxhead (talk) 05:54, 23 July 2018 (UTC)[reply]

@Peter coxhead: I think {{clade}} and {{cladex}} should be changed to use the code in {{cladeN}} and {{cladeNx}}. The redirects would add to the translusion depth and the cladeN template/module complex is useful for development and testing. I can make all the changes except to {{clade}}, which requires template editor rights. To avoid any transitional effects (with the module template mismatches), I'd suggest the following:

Update {{clade}} and {{cladex}} to use the exact code in {{cladeN}} and {{cladeNx}} (they would temporarily be using the sandbox module).
Update Module:clade to the new code in the sandbox module.
Change {{clade}} and {{cladex}} to use the main module.
Create the stylesheet for {{clade}} and update the two templates. When I created the stylesheet before using TemplateStyles there was content-style problem that blocked editing. This might have been resolved, but I'm not sure.

This should make the change seamless. Then I can have a go at updating the documentation. Jts1882 | talk 06:57, 23 July 2018 (UTC)[reply]

@Jts1882: what is the point of retaining two templates, {{clade}} and {{cladex}}? I created the latter solely because of the template depth issue – adding any extra features to the then version of {{clade}} caused it to fail on some existing very deep cladograms. There's no need for two templates now, surely? Peter coxhead (talk) 11:12, 23 July 2018 (UTC)[reply]

@Peter coxhead: I was thinking solely of backward compatibility as there is extensive legacy use of {{cladex}}. Some cladograms may deliberately use {{cladex}} on the outer clade to stretch the cladogram to full width. If you don't think this is necessary then {{cladex}} can redirect to an updated {{clade}} and then be gradually phased out. The extra transclusion level shouldn't matter as existing {{cladex}} cladograms won't be as deep as {{clade}} now allows. Jts1882 | talk 11:57, 23 July 2018 (UTC)[reply]

@Jts1882: as far as I know, {{cladex}} is only used to get the extra features that used not to be in {{clade}}. I hoped that it could have been removed once {{clade}} was converted to Lua, but the the problem was the alignment and blank line issues which you've now sorted out. I would go for complete conversion:

Update the code of {{clade}} to the current {{cladeN}}, including updating the Lua module.
Redirect {{cladex}} to {{clade}}.
Have {{cladeN}} and {{cladeNx}} deleted.

Peter coxhead (talk) 14:15, 23 July 2018 (UTC)[reply]

P.S. if any of this requires rights you don't have but I do, let me know. Peter coxhead (talk) 14:16, 23 July 2018 (UTC)[reply]

@Peter coxhead: Agreed, except for deletion of {{cladeN}}. I use the latter for testing the sandbox version of the module. It's not used in the main space.

I cannot edit the {{clade}} template as that requires template editor rights. I would suggest doing this in three steps so as not to disrupt main space articles during the change.

Copy the contents of thhe {{cladeN}} template over to {{clade}} template. The latter will temporarily uses the sandbox module and CSS styling. You will need to do this step because of the template protection. The {{cladex}} redirect should be made at the same time.
Update the module code and add the styling subpage for the clade template.
Edit the {{clade}} template to use the updated module and styling subpage. Again, you will need to do this.

I think this will allow the change without disrupting articles while the template expects different versions of the module functions. Jts1882 | talk 14:50, 23 July 2018 (UTC)[reply]

@Peter coxhead:. I'm not sure if you've seen my previous message or are just to busy. I'd like to make the changes myself, but unfortunately I don't have template editor rights so need some help with the changes. Jts1882 | talk 15:20, 31 July 2018 (UTC)[reply]

@Jts1882: I have been busy, but can you do (2)? If you confirm yes, I'll do (1) and then afterwards you do (2) and I'll do (3). Peter coxhead (talk) 17:42, 31 July 2018 (UTC)[reply]

@Peter coxhead: Yes I can do (2). I'll be offline soon so will do it in the morning. The change in (1) should be invisible to existing articles, but you are usually active early. Jts1882 | talk 19:09, 31 July 2018 (UTC)[reply]

Done step 1. Peter coxhead (talk) 19:34, 31 July 2018 (UTC)[reply]

@Jts1882: whoops, hadn't made {{Cladex}} a redirect; done now. Peter coxhead (talk) 06:48, 1 August 2018 (UTC)[reply]

@Peter coxhead: Step 2 done. Module:Clade updated to TemplateStyles version and Template:Clade/styles.css created. It passed the tests I made. So now if you change Template:Clade to use Module:Clade and Template:Clade/styles.css the update should be complete. Jts1882 | talk 06:52, 1 August 2018 (UTC)[reply]

@Jts1882: just to be absolutely clear, in {{Clade}}, please confirm that the new text should be:

<templatestyles src="Template:Clade/styles.css" /><noinclude>{{Clade
|label1=root
|1={{Clade
   |1=Leaf1
   |2=Leaf2
   }}
}}</noinclude>{{#invoke:Clade|main|style={{{style|}}} }}<noinclude> ...

Peter coxhead (talk) 06:59, 1 August 2018 (UTC)[reply]

@Peter coxhead: Yes. That should do it. Jts1882 | talk 07:02, 1 August 2018 (UTC)[reply]

Done Peter coxhead (talk) 07:07, 1 August 2018 (UTC)[reply]

Template-protected edit request on 10 April 2019

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Errors in inline text;

  --[[ Parse one level of Newick sting                                       (should be "string")
    This function recieves a Newick string, which has two components         (should be "receives")
     1. the right hand term is a clade label: |labelN=labelname
     2. the left hand term in parenthesis has common delimited child nodes, each of which can be
          i.  a taxon name which just needs:  |N=leafname 
          ii. a Newick string which needs further processing through reiteration

Neils51 (talk) 12:58, 10 April 2019 (UTC)[reply]

Done Jts1882 | talk 13:08, 10 April 2019 (UTC)[reply]

Linter error

@Jonesey95: I'm curious about the Linter error you were trying to fix with this edit. What was the error and what does using div with inline display do that span doesn't? If these labels are causing trouble could it be the content passed to the |label= parameter (variable nodeLabel) and would some error checking be in order here? Jts1882 | talk 09:38, 7 February 2020 (UTC)[reply]

The problem was showing up at Template:Clade label/doc. Expanding the second example at Special:ExpandTemplates shows this code:

|class="clade-slabel last" style="overflow:auto;"|<div style="display:inline;" class="nowrap"><div style="position:relative;"><div style="position:absolute;white-space:nowrap;right:0px;">long label that doesn't stretch the cladogram</div><br/></div></div>

Before my edit, the "class=nowrap" statement was in a <span>...</span> tag. When a span tag wraps div tags, Linter gets grumpy, since span is an inline tag and div is a block tag (or something HTML5-related). I have found that in almost all cases, div style="display:inline;" acts just like a span tag but without the Linter errors. Unless you are seeing a problem with the output, I don't think anything needs changing. – Jonesey95 (talk) 15:47, 7 February 2020 (UTC)[reply]

@Jonesey95: Thanks for explaining. The change seems fine and I will bear that in mind when thinking of using span tags that might inadvertantly wrap something else. Jts1882 | talk 16:19, 7 February 2020 (UTC)[reply]

Another option, if it is viable in all cases, is to move the "class=nowrap" statement into one of the inner div tags and remove the outer div tag (the one that used to be a span tag) entirely. That is more elegant, if it is applicable. – Jonesey95 (talk) 17:31, 7 February 2020 (UTC)[reply]

@Jonesey95: That's not viable here as the inner spans/divs depend on the HTML people put in the label parameter (there are always some surprises; I've just fixed a span tag closed with a small tag). I hope to get rid of that span (now div) tag soon. I've gradually being putting more of the styling into styles.css with templatestyles. The table cell containing the label now has white-space:nowrap; which should allow me to remove that nowrap. Jts1882 | talk 17:57, 7 February 2020 (UTC)[reply]

That sounds good to me. Fewer tags usually means more predictable/robust results. – Jonesey95 (talk) 18:04, 7 February 2020 (UTC)[reply]

Long cladograms cause layout issues on mobile devices when switching to the landscape mode

Some articles have too long cladograms which cause to appear a blank space with a horizontal scroll on the entire page. Is it possible to make some effort for improving the responsiveness of this module? Details: https://phabricator.wikimedia.org/T312667#8153295 VadimKovalenkoSNF (talk) 11:58, 15 August 2022 (UTC)[reply]

I don't see any scrolling problem in any of the examples given (Chlorophyta, Chordate or Bird), so it's hard to make any constructive comment. But perhaps I'm not looking at the right thing. I only have access to Windows at the moment and have checked in Firefox, Chrome and Edge.

I can make a general comment. These cladograms are just nested HTML tables and the appearance depends on how the browser renders the table. There has been a long-standing issue with different presentation using Safari. Chrome used to render as Safari, but now renders same as Firefox. (see Template_talk:Clade#Browser_differences_-_Chrome_vs._Firefox.

It might be possible to do something with the CSS in templatestyles, but there is nothing I can do without an example of the problem to test on. — Jts1882 | talk 16:15, 15 August 2022 (UTC)[reply]

I think I now can see issue under discussion. However, I don't think it has anything to do with the clade module. It is a general problem with the handling of elements such as tables or images that overflow the content width. Take a look at User:Jts1882/blank, a table with a long word that doesn't break.

With the window not maximized, gradually reduce the width. At some point the table overflows the paragraph width (at about 770px). The horizontal scroll bar appears at the bottom of the whole window and creates scrolling showing white space to the right of the paragraph. This is I believe a demonstration of the issue under discussion.

Now further reduce the width of the window. At a paragraph with of about 595px, the scroll bar switches to from the whole window to the table element. Would the correct behaviour would be to see the scroll bar on the table as soon as it overflowed?

— Jts1882 | talk 14:54, 16 August 2022 (UTC)[reply]

Why concacenate strings?

I note that it performs concacenation on strings in a loop, such as a loop that begins on Line No.625. That should not happen in Lua. It is better to use a list as a StringBuilder, or just use mw.html. SolidBlock (talk) 13:14, 4 November 2022 (UTC)[reply]

Non-responsiveness leads to overlap on width less than 1280x

There is a problem with narrow screens, discussed on Russian Wikipedia. The UI team is going to introduce the new theme Vector 2022 that adds a column on the right side. It makes code using this module overlapping with this column. Is there a change you make the display adaptive to the width? Nikolay Komarov (talk) 18:04, 22 February 2024 (UTC)[reply]

It looks like ru.WP is having Vector 2022 forced on it, despite your community pointing out obvious design flaws. The en.WP community went through the same process, and it resulted in some bugs being fixed. Maybe your community will be able to persuade the WMF to work on some of the old bugs that we have reported, as well as newer reports of problems created by ru.WP editors. As far as I know, the basic workaround for problems with this module's display has been to make CSS modifications to eliminate the excessive white space in Vector 2022. It is the only way Vector 2022 has become usable for me. Your community may decide to apply some version of these CSS changes at a site-wide level rather than the individual level. – Jonesey95 (talk) 19:18, 22 February 2024 (UTC)[reply]

Yes, there is one. @Jts1882, since you're pretty familiar with this module I think, is there an appropriate location to add a wrapper div which would be used to add an overflow-x: scroll so that this template does better with small spaces? Izno (talk) 02:56, 23 February 2024 (UTC)[reply]

The "cladograms" output using this template/module are an HTML table made from nested uses of the template, and the widths are determined by the HTML rendering by the browser. A div element with overflow would need to be on the whole structure, not on each instance of the template output. The inner calls of the template wouldn't want the wrapper div but these are transcluded first and don't know they are the inner parts of the whole. The best place to put the overflow is in one of the container templates (e.g. {{clade gallery}} or {{clade box}} or {{cladogram}}) but these are not used in most uses of the template. I have one idea, but I need to think about it.

Is Vector 2022 the default skin here on English Wikipedia? If so we need this fixed as well.

Incidentally, I'm getting some other skin forced on me at Module:Clade, which narrows the code window, despite being logged on. This also occurs on some other modules, but not all. — Jts1882 | talk 07:26, 23 February 2024 (UTC)[reply]

Yes, Vector 22 is our current default, but of course as you've observed above this module probably also doesn't work too well on mobile today.

Your "other skin" is probably Vector 22 based on a known bug with transcluding special pages causing the default skin (which is V22) to display whether you like it or not.

The best place to put the overflow is in one of the container templates (e.g. {{clade gallery}} or {{clade box}} or {{cladogram}}) but these are not used in most uses of the template. I was afraid of that, based on what I could see of what was happening in the module. Izno (talk) 08:20, 23 February 2024 (UTC)[reply]

I've added a parameter |overflow=yes to wrap a div with style="overflow:auto;". This works if added to the outer clade template (see Squamata. This alone doesn't help as it must be added to each cladogram. Adding it to every clade template is a mess as expected as scrollbars appear nested within the whole cladogram.

One ugly method that should work is to add a div element with appropriate CSS to all uses of the template and then delete the styling from all nested templates. This would leave an unstyled div on nested elements and only apply the scrolling to the outer table. It might be possible to remove the divs totally, but the "regex" for that will be difficult because people add all sorts of HTML elements to the labels and terminals. From experience, there's always something unaccounted for.

The CSS styling would be moved to templatestyles, so a class clade-overflow could be restricted to Vector 22 and narrow screens with the appropriate css. — Jts1882 | talk 09:40, 23 February 2024 (UTC)[reply]

appropriate CSS to all uses of the template and then delete the styling from all nested templates We have a few templates that do this (fmbox and navbox both do it off the cuff). I think it would just be:

.clade-container { overflow-x: scroll }
.clade-container .clade-container { overflow-x: initial }

? This would incidentally "fix" the fact it can overflow out of the page even on Vector and other "scroll-right infinitely" skins. Izno (talk) 18:47, 23 February 2024 (UTC)[reply]

Oops, I missed this response. That is much simpler than what I was trying to describe (and failing to). In fact the templatestyles for the clade template does something similar for the table width (auto for the outer table, and 100% for nested tables).

Another reason the appearance in mobile is poor is that it changes the line-heights and font sizes and seems to overide those set by the template. — Jts1882 | talk 17:47, 28 February 2024 (UTC)[reply]

I've added an outer div to all clade elements with a class for CSS styling. I use module code to delete the classes in the nested clade so the CSS only applies to the outer one clade element. I'm only applying the overflow to the Vector-2022 skin, as the overflow causes other problems. It causes the overflow when next to a floated right image or infobox and squeezes the cladogram in, whereas the default behaviour is to move the whole cladogram down and use the screen width. What is needed is an overflow that only happens when at the right edge of the screen and not when next to an infobox or image. I don't know if this is possible with CSS.

As for mobile that has a lot more issues. It sets a larger font size rather than use inherit, which meant thaat the labels (nodes in cladogram) and terminals had different font-sizes. This I think I have fixed. The mobile view also uses !important to block floating of tables (e.g. the responsive behaviour of {{clade gallery}}), so the panels appear vertically instead of horizontally. This can be fixed by using floating div elements or using !important (which I'd rather not) but there are some other mobile changes that make this more complicated (line spacing that affects the panel heights and some things I've yet to work out). — Jts1882 | talk 08:53, 29 March 2024 (UTC)[reply]

This change appears to have caused a few syntax errors in rare places where the newly modified elements were wrapped with span tags, since span tags generally can't wrap div tags. I have found and fixed all of the pages that turned up on Linter error reports, but a few more may trickle in. Generally, the fix is to replace the span-based wrapping elements with div-based elements. – Jonesey95 (talk) 04:24, 2 April 2024 (UTC)[reply]