Template talk:Collapse top/Archive 2

Archive 1

Archive 2

Restricting this template to non-articles (2)

See above /Archive 1#Restricting this template to non-articles

@Frietjes are you proposing that we use a solution like that in Template:Findgp* which uses

{{#switch:{{NAMESPACEE}}
|{{ns:0}}=<br><font size="+2" color=red>Please do not use the findgp* template in articles.</font><br><br 
|#default=...

-- PBS (talk) 01:43, 5 July 2015 (UTC)

PBS, sure that would work to address the MOS:COLLAPSE problem. Frietjes (talk) 12:49, 5 July 2015 (UTC)

It can, of course, also be implemented as an if statement (instead of a switch), as it is in a lot of the citation templates that link to articles on Wikisource (such as {{DGRBM}}). They use it to include maintenance categories which could also be embedded in this template to warn if the template is used in the main article space. If you like the idea and think it worth doing why not add it to the current sandbox code and test it? -- PBS (talk) 13:05, 5 July 2015 (UTC)

PBS, done here. I believe class=error is better than using deprecated font markup, but otherwise, it's basically as you suggested. Frietjes (talk) 13:13, 5 July 2015 (UTC)

I have changed the wording to the imperative and included the reason for the message. I have also added a category -- the last thing needed is this error message in article space. Also I do not understand why you have not made it an "if then else" message. I seen no point in placing the text into a box if the error message is above it. I think it looks messy. -- PBS (talk) 13:45, 5 July 2015 (UTC)

PBS, not sure why we need a category when 'what links here' works, but whatever, assuming someone is patrolling the category. I added display:none for articles. Frietjes (talk) 13:59, 5 July 2015 (UTC)

I did a search there are three occasions where this template has been commented out in articles space. I can think of thee reasons why a category is useful: it uses less computing power to to search it; it is easier to access a category than a list of links; and it is easy for a bot to monitor a category once every so often and remove the templates in articles that show up in the category.

Is there a reason that you have implemented two test, instead of having one test in code that wraps around the existing codes as an "if error else collapse box"? -- PBS (talk) 14:31, 5 July 2015 (UTC)

not sure how a tracking category related to the 'insource' search, but again, whatever. wrapping the entire code in an if statement increases the transclusion depth. Frietjes (talk) 16:46, 5 July 2015 (UTC)

I don't see the disadvantage to increasing the transclusion depth by one to be as great as the clarity the modularity would bring to the code and therefore the ease of understanding for someone looking at the diffs, and maintain it when future changes are made.-- PBS (talk) 17:08, 5 July 2015 (UTC)

The wikitable pipes would have to be escaped, so I quite doubt that this would make the code more readable. Alakzi (talk) 17:25, 5 July 2015 (UTC)

This is a bad idea. Instead the fixes User:Philosopher noted at Template_talk:Collapse_top/Archive_1#Restricting_this_template_to_non-articles can be addressed, in time. We would just be pushing users to use {{Read more top}} instead, which has the same problems, while causing a lot of disruption and confusion. Strongly oppose.--Elvey^(t•c) 15:46, 13 July 2015 (UTC)

How many of these bleeding collapsible boxes do we need? Content should not be collapsed; period. Alakzi (talk) 15:51, 13 July 2015 (UTC)

WT? Read the policy you link to, don't misrepresent it. "Collapsible sections or cells may be used in tables that consolidate information covered in the main text" FCOL. --Elvey^(t•c) 17:05, 13 July 2015 (UTC)

That can be done by applying the collapsible class directly to a table. You don't need a wrapper for it. Alakzi (talk) 18:15, 13 July 2015 (UTC)

How, exactly? We don't 'need' templates for most of the stuff they're used for. But using them for those things is still a good idea. And with that, I'm done arguing. We disagree. And you went so far as to misrepresent MOS:COLLAPSE and don't seem to regret it. --Elvey^(t•c) 02:48, 14 July 2015 (UTC)

I did not misrepresent the guideline. Collapsible infoboxes and navboxes are not "content". This is how you make a wikitable collapsible:

{| class="collapsible collapsed"
|-
! Title cell
|-
| . . .
|}

Title cell
. . .

HTH. Alakzi (talk) 03:03, 14 July 2015 (UTC)

That's how you make an unstyled table collapsible. This is how you make a wikitable collapsible:

{| class="wikitable collapsible collapsed"
|-
! Title cell
|-
| . . .
|}

Title cell
. . .

The collapsed class is optional, it specifies the initial state - by default it's uncollapsed. --Redrose64 (talk) 16:17, 14 July 2015 (UTC)

Tables created using wiki markup are popularly called "wikitables", regardless of class. Alakzi (talk) 16:24, 14 July 2015 (UTC)

@user:Frietjes you are right, as I had not coded it I forgot the limitations of this scripting "language". So as your alterations seem to work, as I for one am for preventing this template being used in article space, I support moving the changes from the sandbox into the template . -- PBS (talk) 22:12, 15 July 2015 (UTC)

• @PBS and Frietjes: We we need to hunt down similar behavior in other templates. I keep running into other collapsed content, like for genealogies of nobles, track lists of albums, casts and crew of films or TV shows, etc. People don't seem to "get" why this is a usability and accessibility issue on multiple levels, and will work around this template's disabling in mainspace to force the same effect. If information is genuinely trivial in an article it should just be removed. If an article is too long, it should be branched per WP:SUMMARY style.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:27, 8 August 2015 (UTC)

Clear

Need to change clear: both; to clear: {{{clear|both}}}; so the default can be overridden. Already implemented and documented this at {{Collapse}}.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:37, 7 August 2015 (UTC)

BTW, this is the fix for #Collapses to the bottom of the page - troubleshooting above. That happens when something vertically long is floated to left, right or both. The clear is forcing the collapse box not appear until after that content. This is often not desirable.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:29, 8 August 2015 (UTC)

Proposed default color change

FYI

 – Pointer to relevant discussion elsewhere.

Please see Template talk:Collapse#Changing the annoying, attention-grabbing color (would affect both templates).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:13, 12 April 2016 (UTC)

RfC: Heading centered or left-aligned by default?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Wikipedia talk:Manual of Style/Accessibility and Wikipedia talk:WikiProject Accessibility have been notified of this discussion.

Should this template be centered or left-aligned by default?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:42, 19 April 2016 (UTC)

Current styling example

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.

Discussion

Some arguments pro each option:

• Centering is a common style for headings; while it is not the default style on Wikipedia generally, it is the default style for table headers, and collapse boxes are somewhat similar in appearance to tables styled with class="wikitable". A centered heading may seem more "title-ish" in some sense, at least to some users.
• Left alignment is what readers of English and other left-to-right languages expect in most contexts and parse most quickly, and eye-tracking studies prove this about Web pages [1], [2]. In 2016, when a large number of users have high-resolution, wide-screen monitors even on laptops and mobile devices, the centering of headings by default, when many if not most of the headings given by this template are quite short, poses a non-trivial usability problem. If the eyes have to track half way across the screen to even notice a heading is present, it is apt to be missed.

Whatever the preference, it should probably be applied to similar templates consistently, including {{Collapse}}, {{Notice}}, {{Warning}}, etc.

I changed the default from centered to left (enabling centering with |center=y). A week or so later, two users – out of however many thousands of active ones – have objected. Both claim that the change "broke" things, but have not demonstrated this, and at least one of the claims has proven unverifiable (I tested the claimed "broken" page myself by changing the collapse templates on it to be left-aligned, and it broke nothing at all, even aside from the ability to manually center them; the other editor did not specify a test page to verify). Over the last month or so, I made similar changes to the other templates mentioned and probably some others, on the same basis as the pro-left argument, above, with zero objections from anyone. This seemed to me to indicate a community preference for left alignment these days, but I ask explicitly with an RfC, to forestall template-by-template debate about it.

So, dramatic hyperbole about "breakage" aside, how should we style such template headings by default?
 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:42, 19 April 2016 (UTC)

• Unfortunately, the changes you made prevented me from centering headers in {{Collapse top}} templates altogether (at least by attempting to follow the doc's instructions), hence my mention of it being broken. I didn't necessarily test it out super thoroughly though so it might have been just working weirdly; however I reverted per BRD also because I oppose defaulting to left-aligned.

Even when putting aside the merits of left-vs-center alignment in the collapse header, changing it now means that 25000+ current transclusions will be changed to align left, which I find completely inappropriate. If you are proposing to change future default to left-align by using AWB or a bot to add the centering parameter to every existing transclusion that was center-aligned by default, then make that clear. But I object to changing the way 25000+ transclusions have been used so that they stop reflecting what their user intended. I know if it had always been left-aligned by default, I would've added the centering parameter to all my collapse headers, so if you change it now to default to left-align, every use of collapse-top that I've made so far stops reflecting my intention -- expand that principle to a hundred other users, and hopefully you'll realize the issue.

On the merits of center-alignment itself, of course some of it will always be up to individual editors' and readers' preference, but Wikipedia often uses centered titles in its boxed content -- Infoboxes, Navboxes, Table-of-Contents title, Wikitables, {{MfD top}}, Hatting ({{hat}}) -- and I've never heard a single complaint about it; those who wish for left-alignment already have the option. It is indeed more "title-ish" to have it centered.

For all these reasons, I object to the proposed change of default behaviour of {{cot}} (and by extension, of {{Collapse}} as well, since they are for the same purpose, and which you've also changed; please make it clear that this discussion applies to both templates in your opening post and cross-post this RfC on the other talk page). ☺ · Salvidrim! · ✉ 15:03, 19 April 2016 (UTC)

• Can't confirm or deny the problem you encountered, since the code's been reverted. It worked fine in sandboxing, and clearly worked exactly as intended in the extended documentation examples, or the examples would not have been functional, would they? Are you sure you didn't just have a typo in it? But let's assume there was a typo of some kind in my own code only triggered under unusual circumstances. The solution to that is to fix the typo; it's completely immaterial to the question of the RfC. The "it's centered already in so many pages" argument, given how unhelpful the centering effect is in most uses of this template (for anyone not using a monitor from 2002) is worse that a WP:CONTENTAGE and extended WP:OTHERCRAPEXISTS argument, but a strong argument in favor of left alignment, to my reasoning. It's akin to suggesting that since a few people really do not regret tattooing their faces that we should do away with tattoo removal (a good analogy, I think, since "don't tat your face" is a sensible default, but if you really, really insist on it, you can still do it; meanwhile we should not all made to have face tattoos by default unless we manage to escape). I have no incentive to see a bot change all existing cases that don't specify |left=y (a parameter that is relatively recent and which most users don't know about or remember) to hard-code for centered alignment, since the centered alignment is usually a bad idea. I did code the template on purpose to support both hard-coded alignments so that in a layout where it was important it would work as intended even if someone changed the default again. I realize that you see an issue, but the response to my change tells me otherwise. Two editors even caring or noticing at all after over a week tells us quite clearly that defaulting this to centered text is a trivial style quirk the community does not depend on or care to retain. You didn't even notice that {{Collapse}} had changed, either, until I pointed it out. No one did. It's a WP:DGAF matter to Wikipedians generally, so I decline to feel guilty for doing something that any experienced Web design professional steeped in eye-tracking-based usability studies, like those produced by Nielsen Norman Group, will tell you was and still is a good idea. (See sources added above.) PS: Yes, I dropped off a pointer to this discussion, at Template talk:Collapse.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:48, 20 April 2016 (UTC)

Resolved by refactoring.

This is an awful RfC. The guidelines at Wikipedia:Requests for comment say: "Include a brief, neutral statement of or question about the issue". The above is neither brief nor neutral. Please remove it, and replace it with something that is. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:50, 19 April 2016 (UTC) @SMcCandlish: Andy's concern is valid. I hope you don't mind that I took the liberty to separate your commentary on the issues from the RfC question at the top. I changed no text. You're welcome to refactor it in a different way if you prefer, but it seemed prudent to make this change before too many people see this RfC. ~ RobTalk 14:59, 19 April 2016 (UTC) Fine by me. I'm not a refactor-whiner. :-) I should have done it that way to begin with.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  10:16, 20 April 2016 (UTC)

• Center by default. This template is a lot closer to a table than regular text on a page. Given the color, it's highly unlikely it will be missed. For those with vision issues, the screen reader will read it regardless of justification. ~ Rob^Talk 14:59, 19 April 2016 (UTC)
• Comment: If I were going to change anything, it'd be to have the [show] link scoot over to just right of the heading (not floated right). That's the bit I find out of sight. As for the alignment of the heading text, I'm not overly bothered one way or the other, but as Rob says, the unusual strip of colour, draws the eye enough to the centre. fredgandt 08:39, 20 April 2016 (UTC)
  • Coloration of a page-wide strip has no effect on whether the eye is drawn to the center of it. See sources added above; the banner across the top of most websites, and which forms most banner ads, horizontal menus, and other wide-strip features, are all color bands just like this, but eye-tracking studies prove that readers go hard left, and stay there for about 70% of their reading/skimming. In fact, the coloration reduces the contrast between the text and background making it less likely that people will notice short, centered items. This is half of why I've proposed changing the default color to a higher-contrast, less saturated, more neutral one (see thread above this one). The other half being that it's self defeating to have a template the purpose of which is minimizing content scream at the reader in day-glow green to look at the box; it doesn't attract attention to the title, just the the fact that something has been collapsed, and should be looked at, the opposite of the intended effect.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:50, 20 April 2016 (UTC)
• Left align by default. I don't have a strong personal preference either way, and find the arguments in favor of making the headings left-aligned much stronger. APerson (talk!) 12:51, 21 April 2016 (UTC)
• Center by default, though I don't really care that much - I'm for centering because it is already a full-length UI element due to having the controls right justified. — xaosflux ^Talk 13:59, 24 April 2016 (UTC)
• Center – I've never had any issues with the heading being centered, and I prefer it this way, also if we left-align it, as Xaosflux said, it wouldn't make much sense to have the controls on the right. The show/hide button would probably be better next to the heading in that case. nyuszika7h (talk) 14:32, 24 April 2016 (UTC)
• Something to consider is that this follows the same style as navboxes, where, in a navbox, you'd have the template controls on the left. Perhaps people are trained to look for the title in the centre and may have to readjust. Izkala (talk) 14:54, 24 April 2016 (UTC)
• Neither - I'd expect it to just inherit its text-align from its parent element if unspecified — no text-align declaration by default. Would be friendlier to user CSS. Would also be easier to plunk down rtl content within rtl content, or anywhere else that isn't left-aligned for some reason. Matt Fitzpatrick (talk) 01:57, 9 May 2016 (UTC)
  • That would be fine, and will amount to left default except in unusual circumstances.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:14, 10 June 2016 (UTC)
• Center - Per Nyuszika7H --03:05, 14 May 2016 (UTC) — Preceding unsigned comment added by TerraCodes (talk • contribs)
• Prefer left-aligned/inherit, but regardless should be the same as Template:Collapse. No comment on e.g. Template:Warning, which differs enough from this template not to make a decision regarding that template here. --Izno (talk) 12:03, 10 June 2016 (UTC)
• Oppose changing to left align unless a center parameter is added to all existing transclusions per Salvidrim!.—Godsy^(TALK_CONT) 22:13, 13 June 2016 (UTC)
  • We could make a bot request to do that, mooting those objections.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:48, 14 June 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Typo?

Under the TemplateData2 header, it says: "Alight along the left margin (true or blank)". Shouldn't it be "align"? --Jennica✿ / ^talk 18:33, 24 December 2016 (UTC)

Conflicts with {{archive top}}?

This template seems to conflict with {{archive top}}. For example if one does {{archive top}} {{collapse top}} {{collapse bottom}} {{archive bottom}}

The {{collapse bottom}} terminates the box created by {{archive top}}, creating a mismatch. Example: [3].

--Deryck C. 22:44, 21 May 2017 (UTC)

Deryck, the problem is almost certainly with the colon indentation of the collapse top, which almost always causes problems. if you unindent the collapse templates the problem goes away. I could go into more detail why this is the case, but proper way to indent is with the |indent= parameter. Frietjes (talk) 13:37, 19 June 2017 (UTC)

Thanks Frietjes. Deryck C. 15:15, 19 June 2017 (UTC)

Parameter on clear:both?

I've just used this template on my user page, but I had to subst it to customize it - in particular, to make it display inline. Could we have a parameter on the clear:both style element (eg |inline=). ∰Bellezzasolo✡ Discuss 00:52, 3 March 2018 (UTC)

Aligning the Collapsed Box if Size is Less Than 100%

Looks like there hasn't been much discussion on this template in a long while. But, I'd like to make a request. If I set the size= to less than 100%, the box that results aligns to the center of the screen. That's not really optimal in all conditions... I'd like to have the option to align= left, center or right, if that's possible... One of the problems I ran into is, I have a collapse-able UserBox on the right side of my screen. When the collapse-top box is not sized below 100%, expanding the UserBox area "pushes" the collapse-top box downward. If I resize the collapse-top box small enough, then expanding the UserBox area doesn't affect the collapse-top box (they don't collide). But to get that affect, I need to resize the collapse-top box to a very small number and it appears directly in the middle of the screen... Anything you/someone can do to help that would be greatly appreciated. Thanks. TadgStirkland⁴⁰¹ (Tadg^Talk) 02:58, 16 August 2018 (UTC)

Span tag changed to div tag to fix Linter errors

I changed a span tag to a div tag with inline styling to fix some Special:LintErrors that were appearing when a manual line break was used in the |title= parameter of this template. I recognize that this template has many tranclusions, so I may have broken something in a cosmetic way. If I have broken something, anyone is welcome to undo this change or improve upon it, since the Linter errors in this case did not appear to affect the pages' rendering (yet). – Jonesey95 (talk) 06:46, 15 February 2019 (UTC)

Mobile

This template doesn't seem to work on mobile. Can this be fixed?  Nixinova  T C   22:51, 13 December 2019 (UTC)

Nope. --Izno (talk) 00:31, 14 December 2019 (UTC)

Left-algining this box?

Is there any way of left-aligning a collapsible box? See here. I want to make it left aligned rather than centre....Cas Liber (talk · contribs) 10:47, 31 December 2019 (UTC)

• Casliber this [4] is probably closer to your desired end result (although I'm not sure why collapsing a single captioned thumbnail is better than just.... showing said captioned thumb?) Ben · Salvidrim! ✉ 12:23, 31 December 2019 (UTC)
• Please see MOS:COLLAPSE. This template should not generally be used in mainspace, and where used should have a solid rationale. --Izno (talk) 13:24, 31 December 2019 (UTC)

Ok fine. Will think of something else. Cas Liber (talk · contribs) 13:43, 31 December 2019 (UTC)

Left aligning the [show]/[hide] function (to help Mobile users in Desktop view)

Following on from the above post, I see no option to position the [show]/[hide] function on the left side of the page. I'm wondering why that has never been addressed.

For regular mobile users like me, who work all the time in Desktop View (and usually in normal handheld landscape mode), the current default is really unhelpful as it first requires scrolling to the extreme right to look for the [show] link, and then back left to read the start of the content. If it were possible to make the [show]/[hide] function visible on the right and the left side, this would be so much more efficient for these users. See my userpage for how I've used the cot/cob functions to arrange content, and try viewing it on a small mobile screen. I know the alternative is switching to Mobile View on a mobile, but that's not really not desirable at all.

Similarly, with {{cob}}, the absence of any option to include a corresponding [show]/[hide] function at the bottom of an expanded page is also a pain for users of small mobile phones in Desktop View. Again, more fiddly up-scrolling and then right scrolling to find the [hide] function to collapse the section. If there isn't a solution to this, might this be worth putting forward at WP:VP? Cheers, Nick Moyes (talk) 00:53, 3 January 2020 (UTC)

Show/hide is inserted by Javascript which this template does not control. phab: in particular is the correct place to request a different location for show/hide. --Izno (talk) 02:11, 3 January 2020 (UTC)

Addl. parameter alias, clearer text

Please substitute the current code with what is in Template:Collapse top/sandbox (as of my last edit to it). The changes have been test-cased. Updated documentation is in Template:Collapse top/doc/sandbox.

• Adds |align=left as an alias of |left=yes, since it's annoying to not have the former work in this template but work in many others.
• Changes "The following is a closed debate" to "The following is a closed discussion" to better match other templates, and because most uses of this templates are not to hat debates, but off-topic noise. Proper debates are closed with {{Discussion top}} or some other template that does not hide the contents (usually; WP:AE is an exception to the latter point, which is often actually irritating since it breaks in-page search).

PS: I'm one of the principal authors of this template's functionality, so I know what I'm doing. I would just implement this (as a TemplateEditor), but it appears to now be full-protected for some reason.
 — SMcCandlish ☏ ¢ 😼  04:05, 17 July 2020 (UTC)

 Done Izno (talk) 14:03, 17 July 2020 (UTC)

Can I make a Collapsed item lie to the left of a right-aligned image?

The article House of Rohan formerly consisted mostly (measured in screenfuls) of hard-to-read family trees. I applied cot/cob templates to each tree, which I believe improved its appearance.

But there's room for further improvement. If you look at House of Rohan#The different branches in the House of Rohan, you'll see a bunch of subsections, each having

1. a subsection header
2. a right-aligned image of heraldry
3. a few lines of text
4. a collapsed family tree

As the cot template appears to start with something like "<br clear=both>", this results in a slab of white space between the text and the cotted family tree. I'd like to get the cotted tree tucked in to the left of the heraldry, if that's possible. (I tried adding "|width=80%", but that didn't work.)

Is there a way to achieve this? Or some other related template I could be using? Maproom (talk) 10:03, 6 August 2020 (UTC)

Per WP:MOSCOLLAPSE, you should not be collapsing anything in main space. --Izno (talk) 16:34, 6 August 2020 (UTC)

Thank you for pointing this out. I have, as recommended at WP:MOSCOLLAPSE, started a discussion at Talk:House of Rohan#Collapsing the family trees.   Maproom (talk) 21:26, 6 August 2020 (UTC)

Double exclamation mark in the header is interpreted as table markup and breaks the output

{{Collapse top|Header!!}}
Stuff
{{Collapse bottom}}

Header
Stuff

This is because the template is implemented using wikimarkup for the table. I don't know if there's a simple workaround here; the better workaround in any case would be converting the table to use HTML-style tags (the best workaround would be converting it to divs instead). I would go ahead and just fix this myself, but it seems this template is meant to be kept in sync with {{Collapse}}, judging by its edit history. 「ディノ奴千？！」^{☎ Dinoguy1000} 05:50, 15 January 2021 (UTC)

Nomination for merging of Template:Collapse bottom and Template:Hidden archive bottom

Template:Collapse bottom has been nominated for merging with Template:Hidden archive bottom. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. –MJL ‐Talk‐^☖ 03:15, 28 February 2021 (UTC)

Collapsing thing Size

Hello, collapse box I great but is there a way to change the size of the thing?????? i swear I am going to scream of you don't reply — Preceding unsigned comment added by BloxyColaSweet (talk • contribs) 09:57, 3 November 2021 (UTC)

@User:BloxyColaSweet "change the size" is not very explicit. However you can change the width with the width parameter. It is described the documentation. -- PBS (talk) 11:56, 8 November 2021 (UTC)

Changing this hideous color

I suggest changing the background color from ■ to ■ (transparent) or, perhaps, some light gray or pastel blue, or maybe just the same color as the other template. This green is hideous. François Robere (talk) 11:07, 22 July 2021 (UTC)

@François Robere: Relevant old discussion at Template talk:Collapse#Changing the annoying, attention-grabbing color. Izno (talk) 19:37, 24 February 2022 (UTC)

Edit request 15 January 2021

Please remove the extra transclusion of Template:Collapse top/TemplateData on the base template page, because it is causing "TemplateData" to show up twice in the TOC. See the sandbox for the update. The TemplateData page is already referenced on the /doc page, it is also able to be transcluded on the /doc page, instead of just having a link to the page. Funandtrvl (talk) 21:50, 15 January 2021 (UTC)

 Done Izno (talk) 22:38, 15 January 2021 (UTC)

I've now made the TemplateDate be transcluded rather than merely linked from the documentation page. However we arrange things it must be eventually be transcluded in the main template page to work. --Salix alba (talk): 07:05, 25 February 2022 (UTC)

Change wikitext table to HTML table

The wikitext table breaks when using {{cot}} and {{cob}} on the same line or with asterisk indentation. HTML would solve this. I made the conversion on {{Collapse top/sandbox}} and {{Collapse bottom/sandbox}} and it works for me, but my work should be checked before being applied here. An admin who fulfills edit requests could do that. But maybe a VPT regular could also check, considering how widely used this is. — Alexis Jazz (talk or ping me) 07:48, 13 June 2022 (UTC)

Mobile use

Can this be made to work on mobile? Pages like WP:ITNC are annoying to scroll through as this template does nothing on mobile.  Nixinova   T   C   00:32, 7 November 2021 (UTC)

you cant edit properly in mobile :) BloxyColaSweet (talk) 21:49, 9 November 2021 (UTC)

No, this is not possible though there is a known Phabricator task. At least the content is now visible where before it was simply removed. Izno (talk) 19:34, 24 February 2022 (UTC)

Nixinova, try Bawl. Don't use Enterprisey's script-installer as any scripts installed with that won't load on mobile. Let me know if it works. — Alexis Jazz (talk or ping me) 17:31, 28 June 2022 (UTC)

Edit request 4 August 2022

Please copy from Template:Collapse top/sandbox (revision 1098775950) (for collapse top) and Template:Collapse bottom/sandbox (revision 1102051095) (for {{Collapse bottom}}). This changes (as per above) the wikitable to HTML as the wikitable can cause severe issues when indented. See also Wikipedia:Village pump (technical)#Collapse template test. — Alexis Jazz (talk or ping me) 04:14, 4 August 2022 (UTC)

@Alexis Jazz why is this a problem? All of the documentation says that this is a block, it shouldn't be used inside of a list. — xaosflux ^Talk 01:33, 5 August 2022 (UTC)

Xaosflux, I seemingly forgot to reply here. Collapse top+bottom gets inserted in discussions fairly frequently. This can result in severe breakage, trapping follow-up comments inside the collapsed element. No such problems with an HTML table.
I was slightly wrong, the issue isn't limited to indentation. {{Collapse top}} and {{Collapse bottom}} always break when used on the same line. No such problems when using an HTML table. See Wikipedia:Sandbox (revision 1103130576) for an example. — Alexis Jazz (talk or ping me) 12:35, 8 August 2022 (UTC)

@Alexis Jazz seems like these are all of the "if you use this wrong, it won't output well" (the directions say use the first one, new line, plain text, new line, bottom one)? In your permalink example above, both of these look fine to me? Is this only a problem on specific skins or with specific browsers?

Both of these seem like bad idea, in that putting table element inside of list elements are generally bad design.

Please update the Template:Collapse top/testcases to include your examples. I'm not greatly opposed to making this work in more cases, mostly worried it could break existing things that are probably also barely-working. — xaosflux ^Talk 13:25, 8 August 2022 (UTC)

Xaosflux, does Wikipedia:Sandbox (revision 1103146687) make the issue more clear?
If I add the example to testcases I'll break the page, are you sure I should do that? — Alexis Jazz (talk or ping me) 14:16, 8 August 2022 (UTC)

@Alexis Jazz OK I see the breakage there. It is garbage-in, garbage out. 2 thoughts:

1. Would just inserting a line break before the table close tag in Template:Collapse bottom fix everything?
2. Won't your change to Template:Collapse top break everything without an additional corresponding change also made to Template:Collapse bottom

? — xaosflux ^Talk 14:55, 8 August 2022 (UTC)

Xaosflux, 1. Very smart solution, that appears to work too! 2. I had prepared and linked the corresponding needed change to {{Collapse bottom}} in its sandbox, but if that line break does the job we may not need the HTML table after all. — Alexis Jazz (talk or ping me) 16:10, 8 August 2022 (UTC)

Just following up on this. Do you still want a line break inserting in Collapse bottom? See below — Martin (MSGJ · talk) 18:00, 21 August 2022 (UTC)

Not sure if this discussion should be held here or at the technical Village Pump, but I agree with the comment there: using <div> elements would be more suitable semantically than a table. isaacl (talk) 14:52, 9 August 2022 (UTC)

I also agree that I would prefer some effort put toward making this a div based structure. I anticipate something or another breaking Somewhere due to such a change but that can/should be dealt with directly with relevant fixes at the location of use as necessary. Izno (talk) 21:35, 30 August 2022 (UTC)

Edit request 15 August 2022

Description of suggested change: per Template talk:Collapse top#Edit request 4 August 2022, can we have a line break before the |}? — Preceding unsigned comment added by Alexis Jazz (talk • contribs)

I just added <br> and it didn't work, so please can you be more specific? — Martin (MSGJ · talk) 18:05, 21 August 2022 (UTC)

@MSGJ I had suggested an actual line break, not a br; though I think that may cause other issues now. — xaosflux ^Talk 23:31, 27 August 2022 (UTC)

I have disabled the request as discussion seems to have stalled — Martin (MSGJ · talk) 10:06, 21 September 2022 (UTC)

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

Please apply these changes from the sandbox: [5] 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. Matma Rex talk 17:19, 23 January 2023 (UTC)

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

There wasn't a discussion, it seemed like a clear improvement to me, as the tiny text is unusual and misaligned, which displeased me. @Jonesey95 Do you want me to bother the kind people at WP:VPT about the font size of 6 characters, or where should I start the discussion? Matma Rex talk 19:45, 23 January 2023 (UTC)

@Matma Rex, WP:VPR. — Qwerfjkltalk 19:48, 23 January 2023 (UTC)

The template has had this formatting since July 2015, and {{Collapse}} has also had this formatting since July 2015. Before that, the templates were using the navbox class (since 2010, apparently), which sets text to 88% by default, so the small size of the link has probably been there for at least 12 years. Please discuss. – Jonesey95 (talk) 20:11, 23 January 2023 (UTC)

Wikipedia:Village pump (proposals)#Font size of the show/hide buttons in Template:Collapse and Template:Collapse top Matma Rex talk 09:46, 24 January 2023 (UTC)

Edit request 8 December 2023

Please sync with the sandbox so that constructions like |left=no work as intended (the sandbox wraps {{{left}}} and {{{warning}}} with {{yesno}}). HouseBlaster^talk 17:31, 8 December 2023 (UTC)

Do you need to use safesubst with those templates? — Martin (MSGJ · talk) 22:24, 8 December 2023 (UTC)

Yes. * Pppery * _{it has begun...} 02:13, 9 December 2023 (UTC)

Sandbox updated. HouseBlaster^talk 02:22, 9 December 2023 (UTC)

I don't see any activity yet at Template:Collapse top/testcases indicating these changes have been tested.  — SMcCandlish ☏ ¢ 😼  18:44, 9 December 2023 (UTC)

Disabling for now; will return when I have a minute to bang my head against subst magic. HouseBlaster^talk 15:19, 12 December 2023 (UTC)

This seems like a lot of work for little to no actual utility. We probably have 1000+ templates with a |foo=yes parameter in them that does not also parse a no value; it's understood that you just omit or blank the parameter if you don't want the feature in question to trigger. (Or in a few cases we have |bar=no syntax, to turn off a feature that's on by default, but again without an explicit yes being parsed). Handling both seems uncommonly done, and mostly for complex templates that both have wider usage and a larger number of parameters that people can't be expected to just quickly get what the default results of which are by a quick skim of the /doc page. Anyway, I don't object to adding this feature, but it seems rather unnecessary, and if you plan to go template-by-template doing this, you may meet resistance to the code bloat and "Template talk:" churn it involves.  — SMcCandlish ☏ ¢ 😼  20:08, 14 December 2023 (UTC)

Hide the title when the content is uncollapsed

Is there a way to have the line of text that is visible when the box is collapsed disappear when the box is uncollapsed. Clearly "something sort-of like this" can be done, given the [show] link disappears (replaced by [hide]). Two ideas that have been mentioned in the banner-shell redesign RFC suggest this would be a useful feature. DMacks (talk) 20:53, 18 July 2023 (UTC)

The [hide]/[show] stuff is done by a site-wide Javascript feature that makes use of CSS classes like mw-collapsible, mw-collapsed, etc.; I think it may be built into MediaWiki. It's not "magic" done within the template code. There's not a facility I can think of in the basic MW templating language that would make what you want feasible, though I would think it could be done in Lua code by converting from a template to a module and then working something up in the module.  — SMcCandlish ☏ ¢ 😼  20:13, 14 December 2023 (UTC)

Protected edit request on 26 May 2023

It would be useful if it were possible to left align the textbox by introducing a |margin= parameter, i.e.:

• Replace: margin: 0.2em auto auto;
• With: margin: {{{margin|0.2em auto auto}}};

T.Shafee(Evo&Evo)^talk 05:43, 26 May 2023 (UTC)

 Not done: I don't see a strong rationale to support a custom option here. Izno (talk) 00:48, 17 June 2023 (UTC)

Also redundant with |indent= which has simple syntax for left alignment control, which was the stated use case. A |margin= could do more than that, but there's not any demonstrated need for it, and people would probably be apt to do silly things with it.  — SMcCandlish ☏ ¢ 😼  20:34, 14 December 2023 (UTC)

Why doesn't this template work as expected in the mobile rendering?

I browsed to a page using this template on my phone and the content which was intended by page authors to be collapsed by default was instead showing and not collapsible. Can this be fixed? IMO mobile readers should be given as close to the same reading experience as practical.

Also, if this is going to remain broken for mobile views, the template documentation should describe what happens there and why. Otherwise desktop authors who don't themselves use mobile devices are given no hint that use of this template is buggy/broken for mobile readers. –jacobolus (t) 19:04, 10 February 2023 (UTC)

The documentation is not protected. There are notes about collapsing at Help:Collapsing and MOS:DONTHIDE. – Jonesey95 (talk) 19:23, 10 February 2023 (UTC)

Updated the documentation (also for {{Collapse}}) with a "Limitations" section, transcluding the relevant material from Help:Collapsing#Limitations, so if that gets updated with new information like an MW upgrade resolving the issue, then the templates' /doc pages will automatically inherit the update.  — SMcCandlish ☏ ¢ 😼  20:38, 14 December 2023 (UTC)

Want parameter to make the box as wide as the title, and left aligned

Please see: Wikipedia talk:Manual of Style/Accessibility#Template:Collapse top, and Template:Collapse bottom.

I would like a parameter that makes the collapsed box as wide as the title and left aligned.

There is already a parameter to left align the title text. I am not talking about that. I want the box itself aligned to the left side of the page.

And I want the title text to wrap in narrower screens. --Timeshifter (talk) 16:54, 10 February 2024 (UTC)