Page MenuHomePhabricator

[makeCollapsible.js] Provide an option to let the initial state depend on the number of collapsible elements
Closed, ResolvedPublic

Description

Many wikis have some code in their MediaWiki:Common.js to make elements collapsible with an additional feature that jquery.makeCollapsible doesn't have: Whether an element is initially collapsed or not depends on the number of such elements, if there are many either all or all but the first few are collapsed, if there are only a few they are initially uncollapsed. Just three examples:

It would be nice if jquery.makeCollapsible supported this feature natively. The number how many elements are "few" should be user-configurable, a hidden user option prefixed with "userjs-" is probably enough (can be set permanently via API or just on client side per User:/common.js). I'm not sure whether all elements should be collapsed or just all but the first few (as implemented in en.wikipedia), or perhaps even both (of course I have a personal opinion on that, but as I'm German and like to play nethack I'm a bit biased).

See also

Details

Reference
bz70762
Related Gerrit Patches:
mediawiki/core : masterAdd a hook for collapsible content

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:55 AM
bzimport added a project: MediaWiki-JavaScript.
bzimport set Reference to bz70762.
bzimport added a subscriber: Unknown Object (MLST).
Schnark created this task.Sep 12 2014, 9:39 AM

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.

TheDJ added a subscriber: TheDJ.EditedMay 18 2015, 12:13 PM

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.

He7d3r added a subscriber: He7d3r.Jul 5 2015, 5:49 PM
GOIII added a subscriber: GOIII.Jul 6 2015, 11:52 PM
Izno added a subscriber: Izno.Feb 22 2016, 1:26 PM

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.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 22 2016, 1:26 PM
TheDJ added a comment.Feb 22 2016, 2:01 PM

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

Izno added a comment.Mar 17 2016, 12:57 PM

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

TheDJ added a comment.EditedMar 21 2016, 1:28 PM

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 );
matmarex closed this task as Resolved.Apr 6 2016, 5:06 PM
matmarex assigned this task to TheDJ.
matmarex removed a project: Patch-For-Review.