User:This, that and the other/column templates

Benwing wrote at WT:RFDO#remove_lesser-used_column_templates:

I think there should only be three sets of templates: (1) auto-collapsing with items inside the template: {{col}}, {{col2}}, etc.; (2) auto-collapsing with items outside the template: {{ctop}}, {{ctop2}}, etc.; (3) non-collapsing with items outside the template: {{top2}}, etc..

Here are the three styles of column templates:

{{col2|en|fish|mammal|reptile|amphibian|bird<qq:technically reptile>|insect|arachnid|crustacean}}

{{der-top}}
* {{l|en|fish}}
* {{l|en|mammal}}
* {{l|en|reptile}}
* {{l|en|amphibian}}
* {{l|en|bird}} {{q|technically reptile}}
* {{l|en|insect}}
* {{l|en|arachnid}}
* {{l|en|crustacean}}
{{der-bottom}}

{{top3}}
* {{l|en|fish}}
* {{l|en|mammal}}
* {{l|en|reptile}}
* {{l|en|amphibian}}
* {{l|en|bird}} {{q|technically reptile}}
* {{l|en|insect}}
* {{l|en|arachnid}}
* {{l|en|crustacean}}
{{bottom}}

The biggest problem is arbitrary choice of the number of columns. It is down to personal editor preference. Three columns is the most favoured, but on large screens these columns still get spread across the screen in an ungainly manner.

Collapsible boxes are used even when there are very few items. See colloquial#Derived terms for an example.

Also, style 2 is relatively little used and there is no particular reason why it should coexist with style 1.

Here are my proposals:

1. Remove all variants of these templates that specify a predefined number of columns. Instead, the column width should be specified, perhaps as one of three options (normal, narrow, wide). Or Lua code could even keep track of the longest entry and automatically pick a column width.
   • An algorithm to be developed.
2. Consider using a regular list where there are few items. For example, a future state of the style 1 template, e.g. {{term list}} (or whatever we call it), could just generate an ordinary, single-column bulleted list when three or four items are provided, but it would generate the multi-column list when the number of items is longer.
   •  Done already in Module:term list, which is used by {{derived terms}}.
3. Retire style 2 (auto-collapsing with items outside the template) from most places where it is used. There are likely to be some complex situations that need manual effort, but in most cases, {{col2}} would be a suitable replacement. Note that {{col2}} does not require a title – this should be redundant to the L3 header ("Derived terms") in most cases anyway.
   • Note that there may still be a need for a style ("Style 1b"?) where the items are kept outside the template, to allow for complex nested lists etc. However, this style should be implemented to match the look of style 1 instead of using NavFrame.
   • To take one of the many style 2 templates: 1876 instances of {{der-top}} across 1675 entries could be converted to {{derived terms}} without any loss of info. A further 219 instances would require manual attention, and only a handful of these do things that are unsupported by {{derived terms}}. (This analysis excludes 1559 entries that use {{der-top}} with a custom title; many of these titles can simply be removed, as they add no additional info.)

A list with few items:

{{term list|en|reptile|fish|mammal}}

• fish
• mammal
• reptile

A list with many items (you can see that the JavaScript "show more/show less" toggle would need repairs to work properly on narrow screens - not terribly difficult):

{{term list|en|fish|mammal|reptile|amphibian|bird<qq:technically reptile>|insect|arachnid|crustacean|hydra|fungi|eukaryote|prokaryote|worm}}

For style 1 templates, we want to be able to decide how many columns to use, based on the width of the items in the list.

Challenges:

• Because we're doing this from Lua code, we can't work out the actual width of text. We have to use some heuristic.
  • Initially I am proposing to simply use the raw number of characters in each line of output, including any (auto or manual) transliterations, glosses etc, but not including wiki syntax characters. Hopefully the Lua code has access to this!!
• Some lists contain a variety of very small and very wide items. Characteristic of this are derived terms boxes like apple, pine (I think we should ultimately move the "common names of of apple/pine species" out into a separate box, but that's tangential)
  • We exclude the few longest names from the heuristic - use the 90th percentile length if < 60 items, or the length of the fifth-longest item if >= 60 items

Proof of concept JS code (paste this into your browser's JS console to see the results):

$$('.list-switcher').forEach(el => {
let columnCountUl = el.querySelector('.term-list > ul');
let lengths = Array.from(el.querySelectorAll('li')).map(li => li.textContent.length);

// Sort lengths from smallest to largest and pick out the 90th percentile length
lengths.sort((a,b) => a - b);
let index = (lengths.length * 0.9);
let value = 0.5 * (lengths + lengths);

// To fit two columns in Vector 2022 standard width, the maximum column width
// seems to be around 27.8em. Only revert to a single column if really necessary
let desiredColumnWidth = (0.336 * value + 6.2);
if (desiredColumnWidth > 27.8  && desiredColumnWidth < 32) {
	desiredColumnWidth = 27.8;
}
columnCountUl.style.columnCount = 'auto';
columnCountUl.style.columnWidth = desiredColumnWidth + 'em';

// demo purposes only: show the column width by drawing a line
let box = document.createElement('div');
box.setAttribute('style', 'position: absolute; top: 0; bottom: 0; width: calc(' + desiredColumnWidth + 'em + 1.6em); border-right: 1px red solid;');
columnCountUl.parentNode.insertBefore(box, columnCountUl);
});

Then resize your window to various widths and view the effect. Note that very few users will actually see the columns as narrow as the red line would suggest - remember this is the minimum column width, and the columns will normally be wider than this.

Obviously this code needs to be translated into Lua! I guess we could do column sizing from a default JS gadget, but it would be preferable not to, as the sizing would only happen after the page is loaded, causing things to jump around.