MediaWiki talk:Common.js/Archive 23

Archive 20

Archive 21

Archive 22

Archive 23

autocollapse

@TheDJ, I just wonder what I'm missing - wouldn't something along the lines of

if ( $('.mw-collapsible').length > 1 ) { $('.autocollapse').addClass('mw-collapsed') }

be simpler? (if this is a stupid question I apologize in advance, I may well be overlooking something here) — Alexis Jazz (talk or ping me) 01:19, 5 September 2023 (UTC)

Not 100% sure, im on mobile for a while. There are many things going on with collapsible. This is the post init phase, so module state has already been initialized. While the css might work, possibly the internal state would go out of sync ? —TheDJ (talk • contribs) 06:07, 5 September 2023 (UTC)

TheDJ, I think you're right. What about:

if ( $('.mw-collapsible').length > 1 ) {
	els=$('.autocollapse:not(.mw-collapsed) button.mw-collapsible-toggle');
	for (var int = 0;int<els.length;int++) {
		els[int].click();
	}
}

? — Alexis Jazz (talk or ping me) 06:48, 5 September 2023 (UTC)

Collapsible elements can be nested, and this snippet would also click on nested collapsible elements' toggles, even if those elements weren't marked with autocollapse. You have to use .data( 'mw-collapsible' ).collapse() on the mw-collapsible element (not the toggle) to avoid that problem, like this script does currently. Matma Rex talk 23:48, 5 September 2023 (UTC)

Matma Rex, but the code here seems to do more than that, though I'm still figuring out what. Part is support for the deprecated "collapsed" class (couldn't a bot do a global replacement for that?) and part is innercollapse/outercollapse. I'm not sure innercollapse/outercollapse are widely used, an insource: search returns 149 and 175 results respectively (with overlap) and several of those results are sandboxes. But the results also include {{navbox}} and {{table}}, so it may be widely used through those templates. Oh well. And I'm not sure why it's changing CSS color.
This seems slightly simpler and more compact than the current code section:

if ( $('.mw-collapsible').length > 1 ) {
	els=$('.autocollapse:not(.mw-collapsed)');
	for (var int = 0;int<els.length;int++) {
		$(els[int]).data( 'mw-collapsible' ).collapse();
	}
}

I'm not interested in dying on this hill though but let me know if I can help somehow. — Alexis Jazz (talk or ping me) 02:39, 6 September 2023 (UTC)

Inner/outer is used by WPBS and/or (some specific?) WikiProject banner, with a few dozen uses in main space. Nixing inner/outer would definitely be nice, but someone has to spend time deleting/migrating uses to alternatives, or making some argument or another for removal in those places.

Autocollapse is most used by navbox and sidebar, but it also hits a few amboxes. I know The DJ has suggested previously to both restrict to and automate in the handful of classes where it really makes sense (e.g. navboxes indeed).

As for color changing, that's primarily for navboxes to ensure that the hide/show text will show up against colorful headings. (C.f. any sports navbox.)

As for support for collapsible class, that really is just someone standing up a bot and working through all the uses. One of the reasons I haven't contemplated it yet is that in the main space there is MOS:COLLAPSE, so whether those uses should even exist is a question I wanted to answer first and then simply remove the uses instead if some RFC agrees to the removal. But that's a high energy 30 days for what is currently only 2 lines or so in Common.js, and I'm not in the mood to spend social capital defending that bot.

Any which way, I think there are better wins elsewhere than this specific region of our JS load, unless you want to spend some significant time on sundry tasks. (See also my obligatory advertising of MediaWiki talk:Common.css/to do particularly the infobox migration, as well as phab:T340705.) Izno (talk) 04:10, 6 September 2023 (UTC)

Yeah in the past I’ve considered limiting auto collapse to navboxes indeed. But I haven’t analyzed it enough to be sure of the fallout (aka how many ppl might complain). “ there are better wins elsewhere” I think thats also a good point, there’s lots to win, but there are likely easier wins up for grabs ;) —TheDJ (talk • contribs) 07:30, 6 September 2023 (UTC)

Actually, the color changing could be replaced by Module:Navbox recognizing whether |titlestyle= contains color (this already happens in isIllegible()) and adding a class, which TemplateStyles uses to add the color:inherit rules, couldn’t it? (Assuming that it isn’t used outside of navboxes.) —Tacsipacsi (talk) 21:10, 6 September 2023 (UTC)

Navbox isn't the only place that uses collapsible anything, just the most common that I can point to that also has colors. Most templates these days that also collapse can have colors set on them. Izno (talk) 23:44, 6 September 2023 (UTC)

Then maybe those other templates should also implement the TemplateStyles-based solution. The current code makes an assumption that doesn’t necessarily hold in templates other than navboxes: it assumes that the font color is specified on the parent element of the [hide] button (the <th>/<td> of collapsible tables, or the <div> having the mw-collapsible class in case of collapsible <div>s). However, the color can be specified on any ancestor element; in case of <div>s, even on a descendant element that contains he [hide] button visually but not at the DOM level. Where the font color of a given collapsible template can be specified is specific to that template and thus better handled in template code. —Tacsipacsi (talk) 08:24, 7 September 2023 (UTC)