This is the 'autocollapse' option from bug 30352.

From a user experience perspective, it seems useful to be able to automatically collapse or trim content that is too long. E.g. based on the length of an individual container.

However I'm not sure under what circumstances it would be desirable to collapse any/all collapsible sections on a page based on the number of them. That would imply a relationship between the sections, which is often not the case.

Off the top of my head I can't imagine a valid use case for an "autocollapse" feature as described here. However I'm 100% convinced that there is an underlying use case for Wikipedia that is very much valid. Having an example of where this behaviour is currently used on en.wikipedia.org would help in trying to find how how this is best addressed.

Example from de.wikipedia:

The navigation bars at the end of https://de.wikipedia.org/wiki/Angela_Merkel are all collapsed (because there is more than one), while for example in https://de.wikipedia.org/wiki/Andrea_Riccardi there is only one navigation bar (which uses just the same code as in the article about Merkel) and is not collapsed.

The size of each navigation bar is quite small, but if all of them in the article about Merkel would be shown uncollapsed, it would look quite overwhelming.

I think Krinkle's concern is that if you were to move two totally unrelated collapsible thingies in front of https://de.wikipedia.org/wiki/Andrea_Riccardi (say with a maintenance template for instance), that it would then autocollapse as well. It's functionality is thus rather arbitrary and not structured or semantic.

Good usecases should help determine if there are other methodologies that could be followed.

In my opinion, the autocollapse code is the side effect of 'lazy authoring'. Basically we initially had collapsed and uncollapsed, then we made navboxes, and then we became too lazy to specify 'collapsed' or 'uncollapsed' per page, so we invented autocollapse (if more than '...' it's more likely we want something initially collapsed, then initially uncollapsed).

I think a good autocollapse, would at least require to be specific to a certain class of content. Specifying the "autocollapse-navbox" class might give the autocollapse behavior for all collapsable elements that have the class 'navbox' as well. Something like that. Anyway, perhaps we should consider if there is a way to 'hack' en.wp specific behavior on top of mw-collapsible, because it's not likely to disappear very soon I think.
I think the only requirement for such a hack on top of mw.collapse, would be firing an mw.hook forwarding the elements which should be collapsible after makeCollapsible has run.

In T72762#1293307, @TheDJ wrote:

I think Krinkle's concern is that if you were to move two totally unrelated collapsible thingies in front of https://de.wikipedia.org/wiki/Andrea_Riccardi (say with a maintenance template for instance), that it would then autocollapse as well. It's functionality is thus rather arbitrary and not structured or semantic.

Yes, that's the concern as I read it as well, and I see it as valid.

In my opinion, the autocollapse code is the side effect of 'lazy authoring'.

I think it's preferable to be lazy because the software should work for us, not against :).

I think a good autocollapse, would at least require to be specific to a certain class of content. Specifying the "autocollapse-navbox" class might give the autocollapse behavior for all collapsable elements that have the class 'navbox' as well.

Navbox would be the primary target of which I'm aware. En.WP has T:Multiple issues which takes care of collapsing a number of T:Ambox templates; T:WikiProject banner shell for collapsing WikiProject banners on talk pages; and the third most-common use case, which is collapsing content on e.g. WP:ANI/AE (usually for the "we don't want to see your disruptive editing here)". I know that sometimes infoboxes have used the autocollapse functionality on list pages (example: T:Infobox video game used to allow the editor to set the class to collapse, which would allow its use on video game lists articles without needing a large number of CSS clears at the bottom of the section).

Out of the above cases, T:Ambox might be the only odd one out for unsolved issues, since I know that there are some ambox templates which have some collapsing of content; I'm unsure if that defaults to collapsed or autocollapse and whether an editor can set the state.

mw.collapsible-navbox/mw.collapsible-footer (since navboxes are probably properly <footer> content) would make sense to me; deploy and see if anyone cries for additional use cases.

I think the only requirement for such a hack on top of mw.collapse, would be firing an mw.hook forwarding the elements which should be collapsible after makeCollapsible has run.

I think that this is rather important. If someone invests some proper time in this, I think it would easily be fixable with this strategy. But I simply don't have the time myself :(

Change 272600 had a related patch set uploaded (by TheDJ):
[WIP] Add a hook for collapsible content

https://gerrit.wikimedia.org/r/272600

Change 272600 abandoned by TheDJ:
[WIP] Add a hook for collapsible content

Reason:
For whoever wants to give this a go.

https://gerrit.wikimedia.org/r/272600

In T72762#2050894, @Izno wrote:

Navbox would be the primary target of which I'm aware. En.WP has T:Multiple issues which takes care of collapsing a number of T:Ambox templates; T:WikiProject banner shell for collapsing WikiProject banners on talk pages; and the third most-common use case, which is collapsing content on e.g. WP:ANI/AE (usually for the "we don't want to see your disruptive editing here)". I know that sometimes infoboxes have used the autocollapse functionality on list pages (example: T:Infobox video game used to allow the editor to set the class to collapse, which would allow its use on video game lists articles without needing a large number of CSS clears at the bottom of the section).

Out of the above cases, T:Ambox might be the only odd one out for unsolved issues, since I know that there are some ambox templates which have some collapsing of content; I'm unsure if that defaults to collapsed or autocollapse and whether an editor can set the state.

mw.collapsible-navbox/mw.collapsible-footer (since navboxes are probably properly <footer> content) would make sense to me; deploy and see if anyone cries for additional use cases.

I identified another case at Template:Track list. This is not a navbox nor any of the others--we want to collapse multiple instances of track lists also.

Change 272600 restored by TheDJ:
[WIP] Add a hook for collapsible content

Reason:
let's see if we can make this happen

https://gerrit.wikimedia.org/r/272600

Right, I spent a bit more time on this. The patch, icw the following blob of JS that the few wiki's that actually require autocollapse, innercollapse, outercollapse behavior could use, should make it feasible to replace the entire custom collapsible table and navframe code:

function mwCollapsibleSetup( $collapsibleContent ) {
	var $element,
		autoCollapseThreshold = 2;
	$.each( $collapsibleContent, function (index, element) {
		$element = $( element );
		if (index > autoCollapseThreshold && $element.hasClass( 'autocollapse' ) ) {
			$element.trigger( 'collapse' );
		} else if ( $element.hasClass ( 'innercollapse' ) ) {
			if( $element.parents( '.outercollapse' ).length > 0 ) {
				$element.trigger( 'collapse' );
			}
		}
	} );
}

mw.hook( 'wikipage.collapsibleContent' ).add( mwCollapsibleSetup );

This is the current en.wp behavior. We could of course easily make it so that there are thresholds for autocollapse that are more specific to the type of content being collapsed. We could have separate auto collapsible counters for navboxes and multiple issues templates for instance. That would then be a wiki decision.

Change 272600 merged by jenkins-bot:
Add a hook for collapsible content

https://gerrit.wikimedia.org/r/272600

Updated code snippet after some changes to the patch:

function mwCollapsibleSetup( $collapsibleContent ) {
	var $element,
		autoCollapseThreshold = 2;
	$.each( $collapsibleContent, function (index, element) {
		$element = $( element );
		if ( index > autoCollapseThreshold && $element.hasClass( 'autocollapse' ) ) {
			$element.data( 'mw-collapsible' ).collapse();
		} else if ( $element.hasClass( 'innercollapse' ) ) {
			if ( $element.parents( '.outercollapse' ).length > 0 ) {
				$element.data( 'mw-collapsible' ).collapse();
			}
		}
	} );
}

mw.hook( 'wikipage.collapsibleContent' ).add( mwCollapsibleSetup );