Wikipedia talk:MakeMobileCollapsible

Code review

There are so many pages, I'm not sure where to post this, feel free to move it. I have some comments about this script ([1] / [2]), I hope you find them useful:

• .mw-parser-output .mw-collapsible-toggle a{color:#3366cc} – I think this is not needed any more, as the toggles are no longer <a> elements (they just look like that) since [3].
• Use the wikipage.content hook instead of the event.EditAttemptStep stuff to support other ways of updating content on the page (e.g. after preview in the mobile editor: [4]). You can replace lines 22-28 with this one line:

  mw.hook( 'wikipage.content' ).add( MMCollap.do );
  

  (you don't need to call MMCollap.do(); on load, since the wikipage.content hook will be fired, and you don't need the MMCollap.re function with extra checks)

I'm glad you're trying to push this through :) I am still hoping that the "normal" collapsible behavior will eventually be added to MediaWiki once people agree on how to style them on mobile. Matma Rex talk 12:32, 4 September 2023 (UTC)

Matma Rex, thank you so much, I've implemented your suggestions. :-) As you can tell I wrote the core of it quite some time ago when the toggles were still <a> elements.
Down from 911 bytes to 751. :-) — Alexis Jazz (talk or ping me) 13:57, 4 September 2023 (UTC)

Mobile styling

@Alexis Jazz Here's an idea for how to style these buttons to fit better with the mobile site and work better with fat fingers, without upsetting the existing layouts, and using standard components (Codex CSS-only buttons and the icons used for collapsible sections on the mobile site).

mw.loader.using( 'jquery.makeCollapsible' ).then( function () {
	$( '.mw-collapsible' ).makeCollapsible();
} );

// Run this block whenever an element is made collapsible (also in preview, etc.)
mw.hook( 'wikipage.collapsibleContent' ).add( function ( $elems ) {
	var $toggles = $elems.find( '.mw-collapsible-toggle-default' );

	// Swap CSS class on the toggles to remove the default link styling
	$toggles
		.removeClass( 'mw-collapsible-toggle-default' )
		.addClass( 'mw-collapsible-toggle-mobile' );

	// Add button styling and icons
	$toggles
		.addClass( 'cdx-button cdx-button--weight-quiet' )
		.prepend( '<span class="mf-icon mw-ui-icon-mf-expand mf-icon--small">' )
} );

// Flip the expand/collapse icon to match the button text
mw.util.addCSS( '.mw-collapsible-toggle-mobile.mw-collapsible-toggle-expanded .mw-ui-icon-mf-expand { transform: scaleY(-1); }' );

// Prevent the button from increasing the line height too much
mw.util.addCSS( '.mw-collapsible-toggle-mobile { margin-top: -0.25em; margin-bottom: -0.25em; }' );

// Change "show"/"hide" to "Show"/"Hide", the lowercase variants look weird with button styling
mw.util.addCSS( '.mw-collapsible-toggle-mobile .mw-collapsible-text { text-transform: capitalize; }' );

I took some screenshots in case you want to share this at the village pump (but if you like these styles yourself, I would suggest just sneaking it in).

	Before	MakeMobileCollapsible	Mobile styling
English language infobox (normal collapsible element, in a small space)
English language § Regional variation (collapsible table with caption)
Talk:Doctor Who → "Learn more about this page" (the "before" version is already made collapsible by DiscussionTools; some of the boxes look funny, this is the fault of the existing mobile site and local styles)

Thoughts? Matma Rex talk 01:57, 22 September 2023 (UTC)

Matma Rex, I see you put quite some work into this, I appreciate that. :-) Overall it seems to look nicer. I have a few concerns though. Most importantly: I feel it's less clear the button/link is an element that can be interacted with. Links are associated with blue text and buttons with having a border or sometimes being in a specific location. With the suggested styling, there's only an added icon and I'm unsure that sufficiently conveys the ability to interact with the element. The insertion of a span should generally be fine, but I'm unsure if this will really never cause issues. What happens if for example the toggle is customized to be a block or 100% width? Same for the negative margin. The capitalization works in English, but I generally aim to make scripts independent from the used language and I'm unsure about conventions in other languages. — Alexis Jazz (talk or ping me) 15:11, 22 September 2023 (UTC)

Most importantly: I feel it's less clear the button/link is an element that can be interacted with. Links are associated with blue text and buttons with having a border or sometimes being in a specific location. With the suggested styling, there's only an added icon and I'm unsure that sufficiently conveys the ability to interact with the element.

I'm hoping that the consistent location (along the right edge of the page… barring bugs), and the icon shared with the existing collapsing mechanism for sections, makes it clear enough.

It could easily have button styles (just remove cdx-button--weight-quiet), but the problem then is that it will start overlapping other elements, or it would need to have more space and would blow up the existing layouts.

If we want to make this better, I would focus not on the toggle, but on the caption/header of the collapsible element. As an example, the common navboxes (not shown on mobile, but this still applies to desktop) draw attention to themselves with a solid frame, which helps you notice the otherwise tiny [show] link. The templates in the talk page example do that as well (but there are so many of them and they are so attention-grabbing that it kinda stops working…). There's also something similar in the mobile apps (not mobile site), which collapse infoboxes, but add a grey background around a "Quick Facts" header (preview here: [5]). I'm afraid that this can't just be done with some universal CSS.

The insertion of a span should generally be fine, but I'm unsure if this will really never cause issues. What happens if for example the toggle is customized to be a block or 100% width? Same for the negative margin.

The changes apply only to default toggles generated by the script, not customized toggles, so it shouldn't cause issues unless the styling for the default toggle is overridden by something else at the same time.

There are actually a few overrides like that in TemplateStyles: [6] but they're all mild (tweaks to spacing and colors) and work with the changed styling just fine.

(There are more in user CSS: [7] and I'm not going to review them all, but the few I looked at were safe or wouldn't be loaded on mobile. I found that User:Chlod/Blender would be affected, which is terrible, and I'll make sure to remedy that if this goes live.)

The capitalization works in English, but I generally aim to make scripts independent from the used language and I'm unsure about conventions in other languages.

Yes, this part shouldn't be needed on most other wikis, because the lowercase text is actually an English Wikipedia customization. Compare [8] and [9]. I suppose it could also be removed, I'm not too sure about this part, but I really disliked the lowercase buttons when I saw them.

Matma Rex talk 18:20, 22 September 2023 (UTC)

Matma Rex, I'm hoping that the consistent location (along the right edge of the page… barring bugs)
This is not the case, see [10]. I don't know about the rest. I would be uncomfortable "sneaking this in", it should be more thoroughly tested and discussed.
If we want to make this better, I would focus not on the toggle, but on the caption/header of the collapsible element.
For navboxes and the like, turning the whole solid frame of the caption/header into a button has been suggested in the phab task I think, but it isn't a simple fix and doesn't universally apply.
Just brainstorming: what if by default for any collapsible element the collapsed state would show the content with an opacity gradient and restricted height like

mask: linear-gradient(#000, #0000);max-height:5em;

and the "Show"/"Expand" text would be centered below it, and the whole thing would be clickable to expand it. Navboxes could customize to not have the gradient, but I think this might work for text, graphs, tables, etc. Still, lots of ifs and buts here, just thinking out loud. — Alexis Jazz (talk or ping me) 19:32, 22 September 2023 (UTC)

Thanks for setting up that gadget. Hmm, you're right, narrow collapsible tables deviate from this pattern, but I think that in practice you're not going to make small tables collapsible; and also, on a narrow phone, even narrow tables are wide. (Collapsible lists too, but I've never seen those used in practice, since you can't make them using only wikitext markup.)

I suggested just doing it because, in my experience, most Wikipedians that dwell near village pumps don't use and don't care about fixing the mobile site (I mean, just look at all the stuff that doesn't work right), but they are always ready to shoot down any ideas for change if asked.

I like the ideas to make the whole header act as a toggle, or to show a fragment of the collapsed content, but they seem more difficult to pull off, especially without angering some naysayer. I'm going for the lowest common denominator here. Matma Rex talk 20:03, 22 September 2023 (UTC)

Matma Rex, it's not just about how wide the thing is, the toggle is within the table. I added some tables with more content [11] (added skin parameter just to flush the cache, action=purge didn't do the trick, I dunno if that's a bug) and you'll see the toggle in the caption is also not aligned to the right side. When the toggle is within the table, it's hard to tell apart from the cell content. It says "World v Collapse" which is either a doomsday scenario or a strange boxing match. Right next to that is the table sorting toggle which could also be confusing. Also consider RTL languages which I haven't tested.
I understand your sentiment about naysayers. But substantially changing the gadget while the proposal is still open with potentially controversial changes doesn't seem like a good idea. As the gadget merely loads jquery.makeCollapsible, you could simply improve how collapsible elements in Minerva are handled in mediawiki-core, no? Would also benefit DiscussionTools (assuming DT does the same thing) and WP:EditNoticesOnMobile. (which does the same thing) — Alexis Jazz (talk or ping me) 21:54, 22 September 2023 (UTC)

The "World v Collapse" example does look pretty bad. Anyway, I'm not insisting on any changes, this was your initiative after all, and it's an improvement no matter how the toggles look.

I would indeed like to simply improve how collapsible elements in Minerva are handled in MediaWiki, but that requires convincing the developers/designers of it that it's a good change, and that's no easier than convincing Wikipedians.  :) Matma Rex talk 22:19, 22 September 2023 (UTC)

Matma Rex, I'm open to uncontroversial improvements. After the RfC is over we could consider other improvements, but I do worry about substantially deviating from Mediawiki. I have no problem with addition and subtraction, but altering what's already there tends to result in headaches and more maintenance. Some day support for collapsible elements does get enabled in Minerva in MediaWiki, it would be nice if that doesn't result in any major visible change compared to the gadget.
We've already seen something like this with WP:EditNoticesOnMobile, the WMF finally made its own implementation of edit notices on mobile. But it's lacking several features when compared to ENOM, so until the implementation in Mediawiki achieves feature parity I doubt ENOM is going away. With ENOM, maybe there was no avoiding that. But with MakeMobileCollapsible, there is. — Alexis Jazz (talk or ping me) 23:35, 22 September 2023 (UTC)

Matma Rex, I like the ideas to make the whole header act as a toggle, or to show a fragment of the collapsed content, but they seem more difficult to pull off, especially without angering some naysayer.
This will never be part of MMC, but I'm curious about your opinion: [12] (source)
Uses a mask and makes the whole element clickable in collapsed state, so no more fat finger issues. (maybe to collapse it again, but I'd consider that less of an issue) — Alexis Jazz (talk or ping me) 06:08, 11 October 2023 (UTC)

@Alexis Jazz Neat, it works better than I expected. Moving the buttons to the footer of tables was surprising at first, but I got used to it after a few minutes. I like it.

Some thoughts on the code:

I was a bit confused by the singlerow/doublerow/multirow stuff, and then I noticed that you had to do that because max-height doesn't work on tbody – I never knew that, that's interesting (and probably super annoying). You might be able to simplify your code a bit if you instead add a class (just one) on the first 1/2/3 trs of the table, and use that class to keep them visible, instead of nth-child selectors. It would also give you some more flexibility (e.g. you could measure the height of rows in JS, and hide them up to the desired height instead of a hardcoded number of them).

Can you explain why the delay with setInterval is necessary? If you need to wait for something else to load, I could probably suggest a better way to do it. Matma Rex talk 13:04, 11 October 2023 (UTC)

Matma Rex, correct, https://stackoverflow.com/questions/8970362/setting-a-max-height-on-a-table basically says "no way Jose". (I'm not going to wrap al tables in another div, that would cause all kinds of other problems) So I figured I would hide all rows beyond the second row, or hide the second row when there are only two rows, or do nothing when there's only one row. I started with tables, then largely copied that for lists (which is why lists also get a "row" class) and finally did divs which turned out to be the simplest. I like your suggestions, the code could probably be simplified a bit.
The delay is indeed a hack: if ColMask runs before jquery.makeCollapsible it doesn't work quite right. Instead of figuring out why it doesn't work correctly before jquery.makeCollapsible has completed I'm just waiting for .mw-made-collapsible to make an appearance. There's probably a better way, but I couldn't read the documentation while I was writing the script so I went with the hack. — Alexis Jazz (talk or ping me) 14:29, 11 October 2023 (UTC)

@Alexis Jazz Try mw.hook( 'wikipage.collapsibleContent' ).add( ColMask ) (instead of the whole var DelayedColMask = setInterval( … ) block). (docs: [13] – if they work this time :) ) Matma Rex talk 16:43, 11 October 2023 (UTC)

+1 for the mobile styling in some form :) I think it's worthwhile to play around with the styling to address Alexis Jazz's concern of intuitiveness. — Frostly (talk) 03:53, 30 October 2023 (UTC)

I recently found some new ideas for styling of "inline buttons" on these tasks: T325553/T327426/T329963 – the tasks are messy, so just look at these two images: F37805501 F37805499. There are various variants proposed here, but I like almost all of them more than the current brackets, and more than what I proposed here earlier. I think it's still a work in progress and not implemented anywhere in the code, but maybe we could borrow one of these designs anyway. Matma Rex talk 18:33, 30 October 2023 (UTC)

Matma Rex, can you take another look at [14]? I've updated ColMask to apply similar things to divs and lists and use codex button styling. Accessibility and translations are broken because I had to replace jquery.makeCollapsible itself and didn't bother to flush out such details. I had to replace jquery.makeCollapsible because it wouldn't let me record the scroll position before collapsing/expanding. If there is a non-hackish way to do that I'm all ears. Hackish ways I already thought of: record the position on hover which probably fails on touch devices, lay a div with stopPropagation event over the original button which makes me hurl.
But ignoring that: what do you think about the UX? — Alexis Jazz (talk or ping me) 23:00, 3 November 2023 (UTC)

I find the scrolling thing distracting. Why does it jump me to the bottom of expanded content when I expand it? It's kind of cute to keep the button in the same position on screen, but this can't be a good experience for using actual collapsible content in articles or talk pages. Matma Rex talk 23:20, 3 November 2023 (UTC)

Matma Rex, hmm, I guess I should only do the scrolling thing when collapsing. Okay, done. It's doing the scrolling thing because collapsing is REALLY confusing otherwise, leaving you in what feels like a random spot somewhere far below the collapsible element. — Alexis Jazz (talk or ping me) 00:08, 4 November 2023 (UTC)

Ignoring that, it seems alright to me. The buttons feel weird, since they're just standard buttons without bold text, but I probably spend too much time looking at the buttons.

You can probably achieve the scrolling thing without replacing the normal collapsible code by using the events that it fires: 'beforeExpand.mw-collapsible', 'beforeCollapse.mw-collapsible', 'afterExpand.mw-collapsible', 'afterCollapse.mw-collapsible' (example of use). Matma Rex talk 22:11, 5 November 2023 (UTC)