Template talk:Collapse

This is the talk page for discussing improvements to the Collapse template.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Archives: 1

Broken?

Resolved

So is it just me, or is this template completely broken? It certainly looks nothing like the results of {{Collapse top}} and {{Collapse bottom}}. It just presents the content it is supposed to put a collapse box around, and puts an empty little box, with no controls, below that content. This is using Google Chrome, current non-dev version as of this writing, on Vista x64 SP 2. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 11:28, 12 January 2010 (UTC)[reply]

In looking over the code, I think I have figured out what the intent was, and that it doesn't work any longer due to changes in MediaWiki. So, I just replaced the whole thing with a simplification of the {{Collapse top}} / {{Collapse bottom}} system. Anyone's free to revert, of course, but at least it actually does something functional now. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 13:16, 12 January 2010 (UTC)[reply]

Tables

Workaround provided

Hi. Is it just me, or doesn't this template work with tables? Rehman⁽⁺⁾ 01:01, 9 September 2010 (UTC)[reply]

Use {{hidden}} instead. It is due to the navbox class (as far as I can tell). Frietjes (talk) 22:28, 8 April 2011 (UTC)[reply]

Restrict

Resolved

Can we restrict this so it cannot be used in articles? It is structured in such a way that it will not show in the print version (navbox class). For example, try the "printable version" of pages like this page. For this reason, I think it should only be used on user pages and talk pages, but restricting to non-articlespace would be a good start. Frietjes (talk) 22:28, 8 April 2011 (UTC)[reply]

Broken

Resolved

Extended content
None of the examples on Template:Collapse/doc appear collapsed. When I preview edits the template appears collapsed, but when I save the edit it appears "uncollapsed".

Hyacinth (talk) 01:19, 25 September 2012 (UTC)[reply]

And now it appears fine... Hyacinth (talk) 06:07, 25 September 2012 (UTC)[reply]

Anyone got any idea why this is happening?

Compare:

Code: {{collapse|width=auto|title=Centered for no apparent reason|1={{lorem}}}}

Result:

Centered for no apparent reason

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Even this code results in unwanted centering:

<div style="text-align: left;">{{collapse|left=y|width=auto|title=Still centered despite all efforts!|1={{lorem}}}}</div>

Result:

Still centered despite all efforts!

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

But this works "magically":

{|
|-
| {{collapse|width=auto|title=Left-aligned, as expected|1={{lorem}}}}
|}

Result:

Left-aligned, as expected

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

The only non-table version that seems to work is this:

<div style="float: left;">{{collapse|width=auto|title=Left-aligned with <code>float:left</code>|1={{lorem}}}}</div>

Result:

Left-aligned with float:left

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

But it requires {{clear|left}} (or HTML+CSS equivalent) after it, and seems like a blecherous, truly brute-force approach, not much better than the table. Maybe I just need more coffee or something. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 15:40, 7 August 2015 (UTC)[reply]

User:SMcCandlish, the reason it floats in the center is the margin: 0.2em auto auto; in the outer container. Frietjes (talk) 13:19, 8 August 2015 (UTC)[reply]

Ah, good catch. Guess I did need coffee! — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 13:36, 8 August 2015 (UTC)[reply]

(edit conflict) The problem with the first demo above is a combination of the |width=auto parameter (which means that the block may be less than 100% wide) with this edit by Ahecht (talk · contribs) - if a block is less than 100% wide, and is not aligned to a margin, the css declaration margin: 0.2em auto auto; (top margin 0.2em, other three margins automatic) causes horizontal centring of that block.

The second one doesn't work for two reasons: (i) because the text-align: property affects text inside blocks (<div>...</div> is a block-type element), it doesn't affect the alignment of the block as a whole, see CSS 2.1 section 16.2; (ii) the |left=y parameter applies the declaration text-align: left; to a table cell (for our purposes, cells are also block-type elements), so it again affects text inside that cell, not the alignment of a cell.

The third one works because you're wrapping it in a table, and tables are left-aligned by default.

The fourth one works because the float: property affects the alignment of a block.

Returning to the initial problem, try |width=auto;margin-left:0;

Left-aligned with margin-left:0;

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

which is a bit hacky but doesn't need a clear. However, it does rely on the fact that in the present version, the width: propeerty is set after the margin: property, so is not guaranteed to be future-proof. --Redrose64 (talk) 13:52, 8 August 2015 (UTC)[reply]

correct, we could add a |float= ... option to this template, and we should rewrite this one as a wrapper for {{collapse top}}/{{collapse bottom}} to reduce code duplication. Frietjes (talk) 13:57, 8 August 2015 (UTC)[reply]

@Frietjes: Do you want to take a shot at that? I have been doing a lot of template work lately, but focused on some other stuff, and am running out of "WP time" this week. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 03:12, 26 June 2016 (UTC)[reply]

SMcCandlish, added |float=, with no changes to the default behaviour. Frietjes (talk) 12:58, 23 July 2016 (UTC)[reply]

A simple solution, March 2020

This interaction was a bit old and might be hard to understand for people like me who don't have experience with CSS. This was kinda done above, but imo not clearly so here's what I ended up doing to have multiple collapsibles all left-aligned.

{{collapse | title = This is the title | width = auto | float = left | This is a text body. }} {{clear | left}}

Which renders as:

This is the title

This is a text body. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

It's important to add the {{clear | left}} at the end if you have multiple collapsibles on your page. Otherwise all of the boxes will use the first one's left margin.

— tr3ndybear 20:44 (UTC), 11 March 2020

Importing to other wikis

I wanted to use this on w:ht:Wikipedya:Akèy nouvo arivan yo, to provide an English translation in a collapsed form. So I copied this, and then {{main other}}, which it requires, but it still doesn't collapse the content. Am I missing something else? WhatamIdoing (talk) 23:29, 6 February 2016 (UTC)[reply]

Have you got suitable rules for the three classes collapsible uncollapsed and collapsed in the appropriate CSS files? Is the JavaScript that does the actual collapsing installed? --Redrose64 (talk) 08:28, 7 February 2016 (UTC)[reply]

You know better than to expect me to know that, don't you?

Let's see: w:ht:MedyaWiki:Common.css mentions "collapse" in the context of tables. w:ht:MedyaWiki:Common.js might not exist? Where else should I look? WhatamIdoing (talk) 04:55, 9 February 2016 (UTC)[reply]

The declaration border-collapse: collapse; has nothing to do with it. This affects borders in tables:

Table with normal borders	Another cell
Another row

Table with collapsed borders	Another cell
Another row

More at the CSS 2.1 Specification.

I'm not an expert on how collapsible sections work, but I do know that it's not part of either HTML or CSS, and MediaWiki only manages it because of some JavaScript. --Redrose64 (talk) 12:51, 9 February 2016 (UTC)[reply]

I've updated the /doc in the hope of saving someone else the hassle. I'm going to use a different approach; there are multiple options. WhatamIdoing (talk) 17:18, 10 February 2016 (UTC)[reply]

Sidebar without collapsible lists

With the example {{sidebar with collapsible lists}} what is the parameter to prevent a sidebar from being collapsible at all? Say with the {{Signpost-subscription}} template, how would I make it to where it doesn't collapse or where there is no option to collapse it? Book-Portal & Talk 11:11, 17 March 2016 (UTC)[reply]

BookPortal, for that template you use |collapse=no or really anything other than |collapse=yes. if you have another example, I can try to help. Frietjes (talk) 16:34, 17 March 2016 (UTC)[reply]

Frietjes That doesn't work either. Notice when you use {{Subscription-signpost|collapse=no}} it still has the hide/show at the top. I tried creating my own template by copying the {{Subscription-signpost}} code and putting it in my own template and tweaking the code so the sidebar will look exactly the way I want it too but when I go to click save it won't let me. I'll eventually figure it out. BookPortal (talk) 16:58, 17 March 2016 (UTC)[reply]

BookPortal, right, there is no parameter for completely removing the [show/hide] button created by {{sidebar with collapsible lists}}, unless you use the |content#= fields instead of the |list#= fields. however, if you are not going to have [show]/[hide] buttons, you should used {{sidebar}} instead of {{sidebar with collapsible lists}}. for example, the version I created for you and added in this edit. Frietjes (talk) 17:05, 17 March 2016 (UTC)[reply]

Frietjes I finally figured it all out. You were correct in using {{sidebar}} I just had to use "content1 =" instead of "list1 =" because then what I had under "list1 =" would disappear. And as far as the template goes, all that was preventing me from creating it was one useless line of code. All is well, thank you. BookPortal (talk) 17:13, 17 March 2016 (UTC)[reply]

BookPortal, I moved your version to your user space and updated your userpage. Frietjes (talk) 17:23, 17 March 2016 (UTC)[reply]

Frietjes I see what you did, I don't know why I didn't think of using my user-space instead of using a template because more than likely no one else will use that template. Alright, all my problems are resolved for the time being. Thanks BookPortal (talk) 17:34, 17 March 2016 (UTC)[reply]

Changing the annoying, attention-grabbing color

The most frequent use of this template (or the {{Collapse top}}...{{Collapse bottom}} pair) is to collapse off-topic blather, details only a few people will want to look at, and other "trivia", but the bright color attracts attention to it, when this is the opposite of the intended effect. I propose changing the default color of both templates to #D3D3D3 (a.k.a. LightGray or LightGrey:

Example!
It really is just an example.

I find myself using this about 95% of the time, and it gets tiresome to keep adding the bg parameter.

PS: I agree with above suggestion to merge these templates (and their documentation), and just use one as the wrapper for the other so we don't have forked code. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 12:13, 12 April 2016 (UTC)[reply]

I find the colour fine. In any case, you could make your own template, sort of like cot-alt which is light gray, which would suit your needs. The colour does grab attention but you have a choice to display it or have it hatted, so I'd say it works the way it's intended to. --QEDK (T ☕ C) 16:51, 12 April 2016 (UTC)[reply]

Anyone can make a template, but WP:TFD routinely and pretty much automatically merges redundant templates, so we'd be right back at the same question: Why is this template screaming in a bright color about material it is trying to minimize? It's schizophrenic. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:30, 20 April 2016 (UTC)[reply]

Good idea to change it to something less screamy. I like the light gray. Bishonen | talk 17:37, 23 April 2016 (UTC).[reply]

Note – The proposed background color is not AAA-compliant with the default link color (#0669AD). The current one might be OK as it's bold and larger than 14pt (~14px = ~18.5px). nyuszika7h (talk) 14:28, 24 April 2016 (UTC)[reply]

why not just go with

Example!
It really is just an example.

which is the default for article space? Frietjes (talk) 17:39, 22 May 2016 (UTC)[reply]

@Frietjes, Nyuszika7h, SMcCandlish, and QEDK: I'm agreeable to Frietjes's proposed color and would be willing to implement it (and wait for the cries of "you didn't have consensus from everyone!"). Are any of you opposed to that color? --Izno (talk) 14:44, 8 June 2016 (UTC)[reply]

Perfect by me. I had not run the grey I'd picked earlier through the accessibility tests (I thought I had, but now that I think back on it, I started using that grey shade before WP started taking WCAG accessibility compliance very seriously, so I had not actually gotten around to it). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:12, 10 June 2016 (UTC)[reply]

Done I will go take care of collapse top shortly. --Izno (talk) 11:59, 10 June 2016 (UTC)[reply]

Request: I would like to retain the color (green). Can someone either explain how I can add the green color back in on an individual basis, or create a similar template that has the green color? Thank you. (By the way, I feel an RfC probably should have been held before this rather drastic change to something that has existed stably for many years was implemented.) Softlavender (talk) 05:23, 12 June 2016 (UTC)[reply]
@Softlavender: That would be the use of the |bg=F0F2F5. --Izno (talk) 14:51, 12 June 2016 (UTC)[reply]
Rather, |bg=#CCFFCC or arbitrary color of interest. --Izno (talk) 15:08, 12 June 2016 (UTC)[reply]
Concur with the above objection, and noting that Template:Collapse top and possibly other places still show the old default in the doc. At least be more thorough please. ―Mandruss ☎ 05:29, 12 June 2016 (UTC)[reply]
I will take care of the doc page--the main page may just need a WP:Purge. --Izno (talk) 14:51, 12 June 2016 (UTC)[reply]
@Mandruss: I'm actually not seeing the issue on the doc page of collapse top. The others need to wait for the WP:Job queue. --Izno (talk) 14:53, 12 June 2016 (UTC)[reply]
@Izno: - At Template:Collapse top, the description of the |bg= parameter says, "Defaults to #CFC - a pleasant green." Is that not the old default value? I'm clueless as to your job queue reference. ―Mandruss ☎ 22:32, 12 June 2016 (UTC)[reply]
Your concern wasn't very clear... I went looking for green bars. You can fix that if you want, or I can take care of it in the morning, Mandruss. --Izno (talk) 00:54, 13 June 2016 (UTC)[reply]
Done. [1] - Used "gray" instead of "grey", per AmEng spelling of the nearby "colors". ―Mandruss ☎ 01:12, 13 June 2016 (UTC)[reply]
@Izno: Personally, I don't see consensus for the proposed color change in this discussion~~, especially not for also applying it to {{collapse top}} (which has its own talk page). Notification of this discussion wasn't even posted at the talk page of collapse top.~~—Godsy^(TALK_CONT) 03:14, 13 June 2016 (UTC)[reply]
Oppose - If this change doesn't improve accessibility, I don't see any need for it (I prefer the old color and find it easier to read). I concur with Softlavender and Mandruss that wider input should be sought.—Godsy^(TALK_CONT) 03:49, 13 June 2016 (UTC)[reply]
And in this case the objections were actually anticipated and consciously ignored. Fairly poor judgment on the parts of all present, imo. But, as these things go, a relatively minor case. Obviously anyone who cares enough can go to WP:VPR and start that RfC, or even just a discussion with wider audience. I'm not that guy. ―Mandruss ☎ 04:11, 13 June 2016 (UTC)[reply]
I'm fine being reverted @Godsy, but I disagree about your read of consensus existing at this talk page (prior to the change). Of the people here who responded to the original discussion, only a single person (QEDK) objected to any change, with 4 others agreeing to a change, and a few of those agreeing to the exact change made (and I think the more logical change was in fact to the grey pointed out by Frietjes, for accessibility reasons, relative to the original grey proposed).
@Mandruss: I indeed anticipated them but only due to the wide-reach of the template and for no other reason. Softlavender asked how to take care of it for his own personal use after the change, so a solution for him is present. SMC pointed out in re to QEDK that a separate template wouldn't fly at TFD, so that solution is out. Now I'm left with Godsy's "I don't like it/I like something else" and your own "see about getting a wider consensus"; both objections I feel to be of low value relative to the change (and its reasoning) proposed (that the template, unnecessarily, calls attention to information which we deliberately want to have collapsed).
@Frietjes, Nyuszika7h, SMcCandlish, QEDK, and Bishonen, FYI. --Izno (talk) 11:19, 13 June 2016 (UTC)[reply]

@Izno: Second time in a week I've encountered that kind of reasoning. "It's a good change, so we can disregard due process." Never mind that the "goodness" of the change is then disputed by multiple editors who were not given the opportunity to weigh in before the fact, whose concerns you then dismiss as "low value", thereby justifying your action. It's all a bit too convenient, sorry.
You then ping the editors who supported the change, and I suspect some of them will now come here and support you, no surprise there. No opportunity for further editors to disagree with you, unless they just happen to drop by this talk page and read this thread.
As I've said, I don't care a lot about the color choice. I was already overriding the default in the template's transclusion on my user page. I do care about the principle involved. ―Mandruss ☎ 11:45, 13 June 2016 (UTC)[reply]
WP:BURO is relevant to "that kind of reasoning". We don't need everyone's agreement prior to full-steaming ahead. Sometimes it's a good idea. Here? Questionably, since I agree with your comment regarding "it's a peanuts issue size-wise".
Regarding pinging, they're the ones who will want to take action to search for wider consensus, since I am going to have no dog in this fight, deliberately-so. The people involved are all familiar with what occurs after a reversion is made; I obviously and personally won't revert the reversion, per the WP:Template editor and WP:WHEEL warring guidelines. --Izno (talk) 12:05, 13 June 2016 (UTC)[reply]

"I don't like it/I like something else" ≠ "If this change doesn't improve accessibility, I don't see any need for it (I prefer the old color and find it easier to read)." which is what I said. If you prefer a color you feel draws less attention to the template, there is a way to change the color on an individual basis, as you've stated above.—Godsy^(TALK_CONT) 15:40, 13 June 2016 (UTC)[reply]

Which the vast majority of our users cannot use, because it requires a registered account to use WP:USERCSS. So your "solution" is not a solution at all. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:36, 14 June 2016 (UTC)[reply]

@Godsy: Re your last sentence, have another gander at the OP. The main point is that (1) most editors will use the default color when collapsing something in a talk space, something that is off-topic or otherwise inappropriate but not qualified for outright removal, and (2) we want to de-emphasize that collapse bar, not highlight it to catch the eye. We're not going to expect all editors to start coding |bg=#F0F2F5 in those collapses. ―Mandruss ☎ 16:01, 13 June 2016 (UTC)[reply]

Per Mandruss. Re your first sentence, the change is accessibility-neutral, so I'm not sure why, so long as we are not detrimenting that experience, the change should be opposed. --Izno (talk) 16:21, 13 June 2016 (UTC)[reply]

I still find the previous green color easier on the eyes (i.e. easier to read), and I think that is just as reasonable of an argument for retaining the green, as the concerns about the green color drawing to much attention is for switching to grey.—Godsy^(TALK_CONT) 16:36, 13 June 2016 (UTC)[reply]

And it's the other way around for me, because while these two colors have nearly identical contrast ratios, the green one being a color not a neutral shade, makes it harder to distinguish the letters. This is always going to be subjective, as well as a matter of display calibration. What is not going to be subjective is that (except for certain colorblind users) the green background attracts attention as a form of highlighting to a much greater degree than the neutral grey, and this is counterproductive when the purpose of the template is to shift attention away from the material subjected to the template. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:36, 14 June 2016 (UTC)[reply]

Except the grey is already used in the mainspace (keeping in mind WP:MOSCOLLAPSE, mind you)... so your argument seems to be against that color as well, no? --Izno (talk) 16:43, 13 June 2016 (UTC)[reply]

No, the color of the text used within that background color in the mainspace is not the same color or generally bolded.—Godsy^(TALK_CONT) 16:56, 13 June 2016 (UTC)[reply]

That response does not relate to Izno's point; you're talking about the text color and formatting, Izno is talking about the background color. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:38, 14 June 2016 (UTC)[reply]

It absolutely does relate to Izno's point. It is a valid variable. For example: it is easy to read example 1, but not example 2, those would be equally easy to read if it did not matter what color text was used on what color background.—Godsy^(TALK_CONT) 04:40, 15 June 2016 (UTC)[reply]

What stands out to me in this discussion is that after the change, no one anywhere on Wikipedia appears to GaF enough to be upset about the loss of the green highlighting except Godsy, whose rationale for opposition is subjective and does not surmount the objective rationales for making the change. The central reasoning behind much of MOS:COLOR, MOS:ICONS, MOS:CAPS, MOS:TEXT, MOS:TM, MOS:IMAGERELEVANCE, etc. – do not do distracting things with visual presentation just because you think it looks nifty, especially if it interferes in any way with effective communication in service to reader needs – also applies to template coloration. Per WP:COMMONSENSE, WP:NOT#BUREAUCRACY, and WP:CREEP it is neither necessary nor even desirable to exhaustively catalog every single possible application of a general consensus and make a specific rule about it; see also WP:GAMING, on why we do not want such nit-picking rule proliferation, and WP:NOT#BLOG, on how WP is not to be used as someone personal Web style display platform. Wikipedia needs no special guideline about exact details of template coloration, when we already have a generalized, side-wide consensus against misuse of decoration and stylization for their own sake. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:36, 14 June 2016 (UTC)[reply]

I certainly am not going to fight over it. We need to understand that the current colour had no specific reason attached to it while there is a rationale to the change proposed. That's pretty much all I had to say. OTOH, the people who want gray can just use {{Cot|bg=lightgrey}}. --QEDK (T ☕ C) 14:23, 14 June 2016 (UTC)[reply]

Left or centered alignment by default?

Stale

– Closed with 'no consensus'.

Please see Template talk:Collapse top#RfC: Heading centered or left-aligned by default? for a multi-template discussion that includes this template. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:30, 20 April 2016 (UTC)[reply]

Mobile

FYI, this template does not appear to work on mobile using Android and chrome. Not sure if that's helpful or not. TimothyJosephWood 22:27, 29 November 2016 (UTC) TimothyJosephWood 22:27, 29 November 2016 (UTC)[reply]

It is still not working on Firefox Android (mobile mode) and Safari iOS. 217.162.112.133 (talk) 02:28, 28 July 2019 (UTC)[reply]

This is because collapsing is altogether disabled on the mobile website (excluding section collapsing, which is exclusive to the mobile site). Jc86035 (talk) 06:42, 29 July 2019 (UTC)[reply]

Use mw-collapsible

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I changed the sandbox to use mw-collapsible instead of collapsible. The former is provided by MediaWiki core, so it makes the template easier to copy between wikis, and using it is a small step to the eventual removing of collapsible from Common.js. –Tacsipacsi (talk) 15:29, 17 December 2017 (UTC)[reply]

@Tacsipacsi: done. Jc86035 (talk) 16:05, 17 December 2017 (UTC)[reply]

Installation

This help request has been answered. If you need more help, you can ask another question on your talk page, contact the responding user(s) directly on their user talk page, or consider visiting the Teahouse.

I want to copy the vastly simplified version of this template at User:Launchballer/sandbox to http://wiki.apterous.org, but it isn't collapsing when I copy it over. The documentation suggests the template depends upon having rules for the three classes (collapsible, uncollapsed, and collapsed) in the appropriate CSS files, and some related JavaScript installed - where would I check?--Laun chba ller 03:40, 2 June 2020 (UTC)[reply]

WP:VPT is going to be a better place to ask; not too many people watch this template and the {{help me}} isn't necessarily going to draw a technically-minded helper. Primefac (talk) 13:18, 2 June 2020 (UTC)[reply]

Remove unneeded font-size changes

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please remove the font size changes and the unneeded span tag. Now the table cell for the title is set with font size 88%, and the title is then again set with a span tag with font size 115%. This calculates to 100,05%. If we instead just use the default 100% we get the same font size and also fixes a few Special:LintErrors. See this edit in sandbox for the change. Tholme (talk) 15:03, 9 June 2020 (UTC)[reply]

Done — Martin (MSGJ · talk) 15:28, 9 June 2020 (UTC)[reply]

@Tholme and MSGJ: These are not equivalent. The font changes are specifically to target and de-target the Javascript-inserted show-hide, which is outside the span in question. I don't have a personal issue with it, but this is a wiki-pattern that shows up elsewhere that should have been noticed. --Izno (talk) 17:12, 9 June 2020 (UTC)[reply]

I was about to say the same. This change also made the header cell about 2.6% higher, although this change is almost unnoticeable (27.3px → 28px, so one pixel change when 1px is rendered as one physical pixel). The toggle size change, however, is noticeable, and I personally prefer the smaller (old) version. This change can be reverted without readding the <span> with TemplateStyles:

/* The collapsible toggle when it actually works */
.collapse-template-header > .mw-collapsible-toggle,
/* The collapsible toggle during page load, when it’s still just a placeholder */
.collapse-template-header::before {
	font-size: 87%;
}

(the template should be modified to add class="collapsible-template-header" to the header cell). This way the simple syntax is kept, but the small toggle returns. The only issue with this approach is that this template is designed to be substituteable, and having raw <templatestyles> tags in non-template namespace is not a nice thing. I don’t know how much it’s actually substituted, though. —Tacsipacsi (talk) 13:13, 11 June 2020 (UTC)[reply]

Substitution can be worked around. From WP:TemplateStyles:

In templates intended to be substituted, or those likely to be substituted, use {{ifsubst}} to remove the TemplateStyles tag. Example: {{allcaps}}. Inline styles may be used as the "if substed" case in a substituted template. Example: {{smallcaps}}.

However, the larger problem is that if these are stacked next to each other for whatever reason, then there will need to be CSS that accounts for the fact that it is now .mw-collapsible + link + .mw-collapsible, rather than .mw-collapsible + .mw-collapsible.--Izno (talk) 13:26, 11 June 2020 (UTC)[reply]

Unfortunately {{allcaps}}’s workaround makes the styling get lost and thus leads to inconsistent styling (different toggle sizes depending on whether the template is substituted), while {{smallcaps}}’s approach is simply impossible—pseudo-elements like ::before cannot be targeted with inline CSS, while the .mw-collapsible-toggle could in theory, but isn’t present in the wikitext. Stacking is less of an issue, as putting the TemplateStyles tag within the header cell works it around (that’s not a particularly elegant solution, but at least it works). —Tacsipacsi (talk) 19:52, 11 June 2020 (UTC)[reply]

Pick your poison. :) --Izno (talk) 20:18, 11 June 2020 (UTC)[reply]

Being able to click anywhere on template to expand/collapse?

curently: In these templates, one has to click the [show]/[hide] text to expand/collapse the content. This isn't ideal on wide screens where the title and the toggle can be far apart.
proposed: On some other wikis, it is possible to simply click anywhere on the template (example), and so it responds better to different pagewidths.
Thoughts and opinions? T.Shafee(Evo&Evo)^talk 09:08, 13 June 2020 (UTC)[reply]

Wikiversity’s solution is far not obvious. If it didn’t say “Click on this” in the title, I would have never clicked on it, but even with that, it cannot be spot when just scanning through the article. I almost missed that there are more collapsible elements on the page than just the gray one because of the lack of any visual sign of it. The other issue with this solution is that it can interfere with eventual links in the header. The first issue can be solved by keeping the [show]/[hide] toggle in addition to making the whole header clickable (which, I think, needs software changes in MediaWiki, but seems feasible); the second one can be solved only by not making such headers clickable that contain links, that is, this feature should be entirely optional (and disabled by default, so that existing template usages containing links won’t break). Other than these two things, I think this proposal is feasible and useful. —Tacsipacsi (talk) 17:07, 13 June 2020 (UTC)[reply]

@Tacsipacsi: I agree that it's sensible to keep the "[show]" text by default (possibly straight after the header rather than on the right when the page is over a certain width?). T.Shafee(Evo&Evo)^talk 02:25, 20 June 2020 (UTC)[reply]

MOS:COLLAPSE

The collapse template causes huge issues for accessibility. It is particularly problematic in infoboxes (where text is already reduced in size), but there is also a whole host of usage across music templates, navigation/category boxes at the bottom of pages and in tables that appear within articles. Can we go ahead and remove them from the article space? I can't see many legitimate reasons to have them in the article space, userspace maybe. ≫ Lil-Unique1 -{ Talk }- 23:11, 18 February 2021 (UTC)[reply]

I remove collapsing things on sight.

That said, I would recommend working on an actual backlog at the same time, which is WP:NavFrame usage. I'm currently tracking that at MediaWiki talk:Common.css/to do#NavFrame. --Izno (talk) 02:47, 19 February 2021 (UTC)[reply]

Izno, Can I ask your thoughts on the discussion here initiated by TipsyElephant about collapsing long episode lists in articles about podcasts? Should it be done at all, if this and related templates are inappropriate? I tried to offer some advice there but I see you have stronger, and hopefully better-researched opinions than mine. – Anon423 (talk) 15:19, 5 September 2021 (UTC)[reply]

@Anon423: No, you should not collapse such lists. The main content of the article should generally never be collapsed. Izno (talk) 16:05, 15 September 2021 (UTC)[reply]

Remove unnecessary font-size overrides affecting the show/hide button

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please apply these changes from the sandbox: [2] in order to remove the unnecessary font-size overrides affecting the show/hide button (it is smaller than usual). I'm also proposing the same changes at Template talk:Collapse top. Matma Rex talk 17:19, 23 January 2023 (UTC)[reply]

Not done for now: please establish a consensus for this alteration before using the {{Edit template-protected}} template. Is there a discussion about this change? – Jonesey95 (talk) 17:40, 23 January 2023 (UTC)[reply]

See Wikipedia:Village pump (proposals)#Font size of the show/hide buttons in Template:Collapse and Template:Collapse top for further discussion. – Jonesey95 (talk) 15:34, 24 January 2023 (UTC)[reply]

Time stamp functionality

What is this about specifically? Is it recommended in all usages? I don't understand this:

Note: {{Collapse}} needs to be substed in order for the time stamp functionality to work properly.

When is a time stamp involved with this template? --Timeshifter (talk) 10:49, 13 January 2024 (UTC)[reply]

Styling options

Does anyone have any insight how often any of these styling options are actually used, considering that this is a subst template ? It creates such a mess to have so many options, and I just don't see why anyone would need all this. —TheDJ (talk • contribs) 15:42, 17 April 2024 (UTC)[reply]

Dark mode compatibility

This edit request to template has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I'm not familiar enough with the scripting language, but wondering if the background/text can be changed from using static values as recommended in MediaWiki's "Avoid static values for inline background and text colors" -- macaddct1984 ^{(talk | contribs)} 13:20, 11 July 2024 (UTC)[reply]

Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format. —⁠andrybak (talk) 11:23, 14 July 2024 (UTC)[reply]