<noinclude>{{pp-template|small=yes}}</noinclude>
Use <code style="font-size:95%">{{<!--
--><includeonly>{{PAGENAME}}</includeonly><noinclude>''Template name''</noinclude>|state=collapsed}}</code> to show this template in its collapsed (hidden) state.<br/><!--
-->Use <code style="font-size:95%">{{<!--
--><includeonly>{{PAGENAME}}</includeonly><noinclude>''Template name''</noinclude>|state=expanded}}</code> to show this template in its expanded (fully visible) state.<br/><!--
-->Use <code style="font-size:95%">{{<!--
--><includeonly>{{PAGENAME}}</includeonly><noinclude>''Template name''</noinclude>|state=autocollapse}}</code> to show this template in its collapsed (hidden) state only if there is another template of the same type on the page. ({{{state|This}}} is the default.)<noinclude>
{{documentation}}
<!-- add categories, interwiki links etc on the bottom of /doc page, not here -->
</noinclude>
{{editprotected}}
Hi. Please prefix each "Use..." statement in the template with an asterisk to produce a wikistyle bullet list. (Suggest this makes reading the list easier when lines wrap, also when more "Use..." variations added after it.) Sardanaphalus (talk) 02:31, 22 August 2008 (UTC)[reply]
[...] Do you know if/how there's a way for [Template:Collapsible option] to look at the {{{state}}} parameter of the template in which it's transcluded and thereby render the [correct "(This is usually the default.)"] phrase automatically? [...] {{{state}}} doesn't tend to be set, or is set incorrectly, or has been changed, etc) [...] Do you know if it's possible to have {{collapsible option}} set its {{{state}}} parameter automatically, depending on where it's been transcluded? Sardanaphalus (talk) 19:53, 23 August 2008 (UTC)
Not done Please give a complete and specific description of the edit requested so that clueless admins don't send the wiki spiraling into an early demise. Skomorokh 22:02, 17 September 2009 (UTC)[reply]
Came here wanting the same thing (usability on the /doc subpage) and concluded that mucking around with this template to make it an option was too much like hard work, but making a fork ({{Collapsible option-doc}}) was easy. Ergo, I did that. Rd232talk12:05, 25 October 2009 (UTC)[reply]
Scratch that. I've just realised that the magic word {{BASEPAGENAME}} will work equally well for the /doc page and the template page, so I've amended this template. Rd232talk11:09, 26 October 2009 (UTC)[reply]
Consensus for universal use of template?
Gentlemen, it has been noted over the past several months that one or two editors are inserting this template into every navbox within certain WikiProjects, greatly expanding its transclusion count in a very brief period of time. Is this the result of some Wikipedia-wide navbox standardization consensus of which I am unaware? Or has such consensus been determined on a project-by-project basis? The courtesy of a timely response to this inquiry is requested. Thank you. Dirtlawyer1 (talk) 10:19, 21 September 2012 (UTC)[reply]
For the record, I note that nearly 12 weeks have elapsed since I made the above inquiry on this talk page, and none of the creators, editors, or proponents of this template have seen fit to answer the inquiry. Please note I hereby contest any purported universal use of this template by consensus, as no such consensus is reflected on this talk page or anywhere else on Wikipedia. Accordingly, I will continue to delete this template from all navboxes that I maintain and from those on which I work as a superfluous bit of coding that serves no useful purpose. Dirtlawyer1 (talk) 18:54, 13 December 2012 (UTC)[reply]
I am confused. Are you against the use of |state={{{state|}}} in a navbox, or are you against adding documentation of this feature? this template does not add the feature, but generates the documentation of this feature. depending on your objection, this may or may not be the correct forum. Frietjes (talk) 20:42, 13 December 2012 (UTC)[reply]
Frietjes, I am against the universal use of this template in what is rapidly becoming every navbox on Wikipedia. The feature which it documents is used so rarely in practice that including the documentation universally is redundant in almost all circumstances. Every navbox template page does not require an advertisement for a feature whose application is rarely needed. I believe the near universal addition of this template was ill-considered and represents one of those ideas whose greatest merit is that it generates a higher edit count for the users adding it to the navbox template pages. In short, it is a template in search of a purpose. Dirtlawyer1 (talk) 18:28, 14 December 2012 (UTC)[reply]
I see, so you are against adding documentation. I am personally against adding both |state={{{state|}}}and{{collapsible option}} to templates which clearly don't need it. however, I am not against adding {{collapsible option}} to templates that are using |state={{{state|}}}. I don't see anything wrong with documenting a feature. however, I don't see a need to add an additional feature to a template which doesn't need it. so, if you remove the {{collapsible option}}, please also remove the |state={{{state|}}} at the same time. Frietjes (talk) 18:44, 14 December 2012 (UTC)[reply]
Note: It's now possible to omit the "state=".
an editor has been adding this text next to transclusions where state = {{{state|{{{1|}}}}}} is used, instead of state = {{{state|}}}. to allow for uniform presentation of this note, I suggest adding this note to this template. Please add the following line at the end of the template:
{{#ifeq:{{{state optional|}}}|true|Alternatively, the <code>state =</code> can be omitted.}}
Comment. I'm the editor to whom Frietjes refers, so, naturally, I approve his (her?) message. This one too, I think -- so long as omitting the "state=" will work where this template is shown. CsDix (talk) 22:50, 30 November 2012 (UTC)[reply]
Question: I thought that the |state= parameter has always been optional, and that if it is omitted {{navbox}} and similar templates default to autocollapsed. This is true for cases where |state={{{state|}}} in templates like {{Algeria topics}}, and for these templates to behave differently when |state={{{state|{{{1|}}}}}} there would have to be a value specified in the first unnamed parameter when they are transcluded. Has there this been the case in a significant number of these transclusions? Or I guess what I'm trying to say is, why can't we just say that autocollapsed is the default state and leave it at that? Best — Mr. Stradivarius(have a chat)00:24, 1 December 2012 (UTC)[reply]
at least one editor [that'd be me, CsDix] has been changing |state={{{state|}}} to |state={{{state|{{{1|}}}}}} and then appending "Note: It's now possible to omit the "state="." just after this template. I personally think this is pointless, but whatever. however, if we are going to be adding this "first unnamed parameter" option to a load of templates, then rather than pasting "Note: It's now possible to omit the "state="." in every single template, might as well just document it here. however, if people feel we should go back to |state={{{state|}}}, then clearly this isn't needed. the convention, as far as I recall, has been to use |state={{{state|}}} and reserve {{{1|}}} for {{navbox with collapsible groups}}. until we can have that discussion, I was hoping to add the additional documentation here, which could be easily tracked, and removed later if necessary. thank you. Frietjes (talk) 01:11, 1 December 2012 (UTC)[reply]
This is just about the convenience (and, cumulatively, the space saved) by using {{Template |state}} rather than {{Template |state=state}} -- isn't it..? CsDix (talk) 03:02, 1 December 2012 (UTC)[reply]
Ok, now I see what's going on - thanks for the clarification. Are there any templates that this documentation would apply to which use the first unnamed parameter for anything other than a shortcut for the |state= parameter? We need to think of all the possible cases when working this out. — Mr. Stradivarius(have a chat)05:34, 1 December 2012 (UTC)[reply]
Yes, that's what I'm also wondering when I said "... so long as omitting [etc]" above. Also, wouldn't the state-handling of those templates using this collapsible-option message need to be amended to include {{{1| ...}}}, e.g. by a bot..? (If so, I'm still thinking it's probably worth doing -- although maybe that's because I wouldn't be programming the bot!) CsDix (talk) 09:08, 1 December 2012 (UTC)[reply]
Ok, Done. As this is an optional parameter, I couldn't see any harm in adding it. However, its addition to the template should not be taken as an endorsement to add |state={{{state|{{{1|}}}}}} to more navboxes. I think a change on this large a scale needs a full discussion where all community members have a chance to comment. I suggest starting a new thread at WP:VPT to make sure there is a solid consensus for rolling this out on a wide scale. Best — Mr. Stradivarius(have a chat)12:32, 1 December 2012 (UTC)[reply]
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Thanks, Mr. Stradivarius. However, could...
the parameter be renamed "statename";
the value become "optional";
the "state =" in the message added become "state=";
the message added start on a new line;
and an inline example included,
...please, as...
"state optional" suggests the parameter is something about the state itself rather than the "state=" wording;
the syntax would then become "statename=optional";
there isn't a space between "state" and the subsequent equals-sign in the main message;
the message added is more easily noticed when it has been added;
an example should make clear what's meant by the added message.
In other words, I'm think I'm thinking of...
{{#ifeq:{{{statename|}}}|optional |<br/>Alternatively, the <code>state=</code> can be omitted (for example, <code>{{<includeonly>{{BASEPAGENAME}}</includeonly><noinclude>''Template name''</noinclude> |expanded}}</code>}}
...in the template's code.
I'm also thinking it might be worth adding a space between each <noinclude> and |state= in the main message, to produce e.g.
....{{Template name |state=collapsed}}....
...in order to make the separation between the Template name (however unorthodox and/or lengthy it might be) and the state parameter.
Update: Haven't done anything at WP:VPT as there doesn't seem to be any push for or against this template's use (i.e. leaving this template for editors to discover and use or bypass works seems to be working fine). CsDix (talk) 17:46, 12 February 2013 (UTC)[reply]
Edit request on 12 February 2013
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Currently, this template message's last sentence, about whether (and what) default state might be in use, seems to be presented as more of an afterthought than as worthwhile as the rest of the message's information. So, here's a version (in the template's sandbox) giving this sentence its own line and more handling. (If this version is implemented, I'll add an example to the documentation to indicate how the message changes when a custom default state is supplied.)
Thanks for your speedy action – and for the amendment. (I'd commented out the space as, depending on the browser, I thought it might otherwise affect the output; but, if you reckon not, that's fine.) CsDix (talk) 22:03, 12 February 2013 (UTC)[reply]
Except when editing a page, browsers never get to see parser functions like {{#if:}} - these, like all other Wiki markup, are converted to HTML by the Wikimedia servers. --Redrose64 (talk) 22:47, 12 February 2013 (UTC)[reply]
Template-protected edit request on 29 January 2014
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The semicolon formatting used at the very start of this template can produce uneven linespacing when the template is added below other content, so please replace the first line
; {{larger|How to manage this template's visibility}}
with
'''{{resize|120%|How to manage this template's visibility}}'''
Not done for now: I'm not going to do this as proposed as there is no consensus to change the size of the text from 110% to 120%. Please do one of the following:
Re-propose your request using the existing {{Larger}}
Put your request in the sandbox and make appropriate testcases (maybe show all three sizes; {{Larger}}, {{Big}}, and {{Resize|120%}})
Note: I moved the bolding inside the template. I agree that the font-size should remain the same at 110%. Hopefully, this will solve the problem with the rendering. Funandtrvl (talk) 17:50, 29 January 2014 (UTC)[reply]
Template-protected edit request on 14 May 2014
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please replace the template's code with the sandbox version here (current as of this message). The changes made are:
The pp-template code placed after rather than before the template's main code, compressed but otherwise unchanged;
{{big}} (115%) rather than {{larger}} (110%) heading (more consistent beside other headings and/or font-sizes over 100% when this template transcluded on template pages and/or within {{Documentation}}); ...Having just seen the thread above, I've added a Heading size comparisons section to the testcases page;
 s rather than s (better transition between <code> and plain text);
" {{ (( }} " and " | " in place of " { { " and " | ";
Bullet-points before two rather than all four lines of text;
Each line of text no longer interrupted by comment tags;
Corrected conditional used in fourth line of text;
Fourth line now shown in italics if amended by |default=;
Removed comment after {{Documentation}}.
The single change I'd originally intended to make was #8, but I then noticed the need for #7 and the remainder followed thereafter.
Sardanaphalus (talk) 17:00, 14 May 2014 (UTC), updated 17:20, 14 May 2014 (UTC)[reply]
Not done: I'm not sure it's a helpful link since Help:Collapsing is about collapsible tables only, not about navboxes and other templates (which is what this template is for). The hatnote-linked WP:NavFrame, albeit about the collapsing method used for templates, are about how to make templates collapsible using CSS classes and is probably too technical for users who want to know what collapsing is. SiBr4 (talk) 10:42, 24 May 2014 (UTC)[reply]
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
There are whitespace errors related to two of the plaincode templates. It displays as (1) "thestateparameter" and (2) "default state isautocollapse". A space should be inserted after plaincode at (1), and a space inserted before plaincode at (1) and (2). Brianhe (talk) 18:16, 12 November 2014 (UTC)[reply]
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Hi, could someone add back the curly brackets (braces), so that it is much easier to cut and paste into another template? This revision shows the braces in an easy cut/paste format. Thanks, Funandtrvl (talk) 23:53, 4 December 2014 (UTC)[reply]
Apologies for the delay before responding to your note. The braces etc were removed in case the template's message gave the impression that the collapsible option was only for templates taking no other parameters (or wouldn't work with templates taking other parameters, e.g. templates using {{Navbox with collapsible sections}}). On the other hand, I suspect the bulk of those templates using this option are Navboxes that do take no other parameters, so I'll experiment with some rephrasing that reintroduces the convenient copy-pasteable text. Thanks for prompting, Sardanaphalus (talk) 18:59, 11 December 2014 (UTC)[reply]
It occurs to me that this template has a top line that suggests a header (but is not). I find it way too big in any sense for what is just a single parameter description (think of what if the template has dozens?). Also the wording is not specific enough (for example, visibility=collapse only?). Can someone make a proposal with downsized importance? -DePiep (talk) 19:09, 23 December 2014 (UTC)[reply]
I think it is (meant to be) a heading, but, so as not to e.g. perturb ToCs when transcluded, not a standard section/"equals-signs" (official term?) heading. I'm not sure how wise it would or wouldn't be to make it a standard (third-level?) heading, though I imagine it's probably best not. Having just experimented a little, there doesn't seem to be much if any scope for reducing its size and/or removing its boldface here (PC running Firefox-based browser) without making it look like just another sentence. Although it's only with reference to one parameter, that parameter is many e.g. {{Navbox}}es' one and only parameter, so I'd say it's pretty significant.
As regards the wording, I'm not sure what you mean/indicate by "visibility=collapse only?"..?
Yes it's used often. That does not imply it should use 75% of a screen. And it's still a parameter, I don't see why that merits a section of whichever level. Just take a look at any template with 3 or 12 or 30 parameters. How are these documented? 30 sections? -DePiep (talk) 10:09, 25 December 2014 (UTC)[reply]
As I mentioned above, current formatting suggests a section header, while it actually is formatted text only. The effect is that the reader is visually confused with the status of this paragraph. Also, in whichever context structure (like surrounding section or parameter listing) it is placed, it interrupts that structure.
In general, such a block of text should not contain any higher level setting at all, because it is variable or undetermined what its position is in the transcluding (receiving) page.
As it is proposed now, it will have a semicolon for default paragraph, and that can be overruled (including blanked) by using |title=. This gives a general format by default, and an option to tailor specific situation (including adding a section header). The anchor is present always, so sectionlinking is always possible by standard name.
Note: I oppose using an id in that way, and I'm not sure why this heading needs to be changed in that way. I oppose the lack of backwards compatibility for this change, and there has been insufficient discussion to change the default behavior. I'll leave the request open or someone else to close since I've already closed it once. — {{U|Technical 13}} (e • t • c)13:15, 17 January 2015 (UTC)[reply]
I'm not sure why this heading needs to be changed in that way. - sigh. Why didn't you read the ratio provided? And why not actually click and read any secondary reasoning provided? I have little patience with this reply, Tech13, because you clearly say you did not read it at all (as opposed to, say, "I have a question"). And this is the second time in this thread (my #1 @21:35). I don't see what I am supposed to reply to. -DePiep (talk) 17:34, 17 January 2015 (UTC)[reply]
I did read the rationale provided, and I did read the section above, and I'm still not convinced this is needed or a good idea. I never said I didn't read all of it, and I'm not sure where you came up with that notion. I see this as a solution where there is no problem. Anyways, like I said, I won't enact or decline this request (unless of course it sits around for an undue amount of time and it is clear no-one is going to act on it, in which case I'll close it as a lack of consensus to fix a problem that hasn't been adequately established to exist). — {{U|Technical 13}} (e • t • c)17:50, 17 January 2015 (UTC)[reply]
The very first sentence of the ratio says it. Then you write "I'm not sure why". (And again, #3, you conclude there is no problem to fix). If you repeatedly fail to see it (without trying to), I can not help you. Instead of "I don't understand so I oppose", you can say "I don't understand, so I'm out". -DePiep (talk) 08:21, 18 January 2015 (UTC)[reply]
Simply: if you don't understand the issue and write so, that does not constitute lack of consensus. It is lack of understanding -- a pity, but no blocker. (And, it obfuscates your other possibly reasonable remarks. However it is not up to other editors to clean up your comments). -DePiep (talk) 08:25, 18 January 2015 (UTC)[reply]
No comment on the merit of this request but I don't understand your code. What is the purpose of checking the |title= parameter twice in the following line? — Martin (MSGJ · talk) 10:23, 19 January 2015 (UTC)[reply]
@MSGJ: The two #ifs do different things, since the {{{title}}} parameter in the first #if check has an empty fallback value while the one in the second check does not. The whole thing returns ;Collapsed state if |title= is not defined, nothing if it is defined but empty, and the parameter value followed by a line break if it is defined and non-empty. It could be replaced by
I still oppose this. There needs to be discussion and consensus will need to be assessed by an uninvolved editor. I'm still of the mindset that changing the default behavior of this script is bad and DePiep's I don't like the default behavior isn't a good enough reason to modify it for everyone else. — {{U|Technical 13}} (e • t • c)16:47, 19 January 2015 (UTC)[reply]
"current formatting suggests a section header, while it actually is formatted text only". I wrote. That is not an opinion, that is saying the format is bad and out of style. Avoid various kinds of overemphasis. And you saying "still" is weird, because this is your third or so angle of approach. Whatever I write, tomorrow I must expect another reason. -DePiep (talk) 17:09, 19 January 2015 (UTC)[reply]
That is your opinion. My opinion is that I don't think it looks like a header. So, this is still a solution in search of a problem. — {{U|Technical 13}} (e • t • c)17:23, 19 January 2015 (UTC)[reply]
Bingo: another day another another angle (you are trolling, right?). The other day it was "not enough discussion". "There needs to be discussion" you write without even reading two other editors right before your post. That's an attitude. So I think your going for quantity of text as argument, and having it your way by ididnothearthat.
"I don't think it looks like a header" is good for you, but does not nullify the issue. It also does not conclude that we can not change it (take note).
This is what the code says:
<div style="font-size:120%;font-weight:bold;"> How to manage this template's initial visibility </div>
It could just be me, but I find this statement unclear/ unhelpful:
|state=autocollapse to show the template in its collapsed state but only if there is another template of the same type on the page
This wording suggests that the options are:
appear in a collapsed state (if there's another template)
not appear at all
It would be clearer if the logic were inverted:
|state=autocollapse to show the template in its expanded state, unless there is another template of the same type on the page, when it is shown in its collapsed state
DePiep, Putting the two cases on separate lines is good, and much clearer -- but I don't think the autocollapse works like you have described it. I think that it's like this:
|state=autocollapse
Does show the template (expanded state) if there are no other autocollapse-templates on the page
Does hide the template (collapsed state) if there is another autocollapse-template on the page.
Well, see: current text is so unclear ;-). Your text then is better. I won't go in the wording any further, but we agree an improvement is needed. Let's do it. -DePiep (talk) 21:35, 24 March 2015 (UTC)[reply]
Hmmm ... a little more digging shows that the state of the other template(s) doesn't make any difference to the autocollapse. Trying the following (yes, one by one rather than all on the same page :-) gives the following results:
the second (and only state=autocollapse case) is closed
So, even if there's only one state=autocollapse, that template is still collapsed, which leads us more towards:
|state=autocollapse
expands the template if it is the only collapsible template (=navbar?) on the page
collapses the template to the header line if there are any other templates of the same type
I think that the new wording will have to be written by someone who fully understands the phrase "template of the same type" used in the current doc, to make the autocollapse dependencies explicit, and clearer than they are now.
Scarabocchio (talk) 04:17, 25 March 2015 (UTC)[reply]
It says: "Adding the autocollapse class causes the table to collapse when there are 2 or more collapsible tables on the page." That simple ;-). -DePiep (talk) 11:25, 25 March 2015 (UTC)[reply]
So, your 21:27 post is the right one. In the current doc text (first quote here): "... only if there is another template of the same type on the page ... ", 'of the same type' is confusing (what type?) and wrong (class not type). It could just say 'using the same autocollapse class'. -DePiep (talk) 11:32, 25 March 2015 (UTC)[reply]
More digging... it's got nothing to do with autocollapse, and it doesn't actually have anything to do with templates at all. "if there is a template of the same type" should be "if there is another wikitable with the collapsible attribute":
{| class="wikitable collapsible"
! Simple collapsible table
|-
| Lorem ipsum dolor sit amet
|}
{{The Vampyre|state=autocollapse}}
is enough to collapse the template.
Given that most editors will have little idea about wikitable attributes, the wording will need to be generous
|state=autocollapse
shows the template collapsed to the header line if there is another {{navbar}}, {{sidebar}}, or other wikitable with the collapsible attribute on the page
shows the template in its expanded state if there are no other collapsible items on the page
That's wordy, but should provide enough explanation to all editors regardless of their knowledge of wikitable syntax.
I am going to add a description for another parameter called width. But it will only show if a width parameter is passed into his template. I am adding a new header to some templates that use {{chart/start}} and {{familytree/start}} but are not contained in a collapse box.
This template is a useful addition to add at the bottom as it is for many similar templates that use {{navbox}}, but as you can see above I am also using another parameter called width for which I need to explain how it works. So I am going to add the text to this template, but it will only be visible if the parameter "width" is passed into this template -- PBS (talk) 10:53, 18 April 2015 (UTC)[reply]
I think that this template is far to complicated for one that is only visible on the talk page and is just a generalisation of a standard "doc" as used on thousands of template.
For example why use:
<div style="font-size:120%;font-weight:bold;"> How to manage this template's initial visibility </div>
How to manage this template's initial visibility
when the same affect can be manufactured with:
'''How to manage this template's initial visibility'''
How to manage this template's initial visibility
or using a standard header as shown in this section header:
===How to manage this template's initial visibility===
How to manage this template's initial visibility
? The disadvantage of the current style is that what is a simple piece of text looks very complicated for someone not familiar with <div style=... type of expressions which I think is an unnecessary barrier to those editors who wish to edit this template -- PBS (talk) 10:53, 18 April 2015 (UTC)[reply]
WP:SOFIXIT. Documentation should be clear and concise. Sardanaphalus has saturated the documentation with all kinds of unnecessary markup-fluff; that was his editing style. I wouldn't mind a blanket revert to pre-Sardanaphalus state. -- [[User:Edokter]] {{talk}}11:41, 18 April 2015 (UTC)[reply]
I'd want it to be non-styled being boilerplate text. Stand-alone transclusions, without enveloping documentation page, must be covered as documentation, but deprecated. -DePiep (talk) 12:11, 18 April 2015 (UTC)[reply]
You answered my call. Explaining afterwards: When I transclude this into a regular /doc page, I want it to be plain text that I can sectionize & style as needed there (eg 2-= deep or 3-= deep). When it is stand-alone, it should show & act as a {{documentation}} page by itself. I'm glad that the constructed bolding (suggesting a section? LEvel?) has gone. -DePiep (talk) 17:30, 18 April 2015 (UTC)[reply]
Yep. In this one, I am happy with any simplification, and won't do details. Support from Edokter is always welcome too. Stay bold in this I'd say. -DePiep (talk) 20:34, 18 April 2015 (UTC)[reply]
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Change line:
Unless set otherwise (see the {{para|state}} parameter in the template's code), the template's default state is <code>autocollapse</code>
to
Unless set otherwise (see the {{para|state}} parameter in the template's code), the template's default state is <code>{{{default|autocollapse}}}</code>
To bring in line with documentation. Ignore the nowiki tags.
Done I see that nobase isn't working either, and the following parameters are undocumented: align, title-background, width. Alakzi (talk) 17:50, 25 April 2015 (UTC)[reply]
Could this documentation be automatically transcluded by Template:Navbox when used in the template namespace and the state parameter is defined? I.e. something like the following — Martin (MSGJ · talk) 13:42, 19 February 2016 (UTC)[reply]
Additionally, with that code, this template would confusingly show on navboxes that have |state= set without allowing overriding it (e.g., |state=collapsed instead of |state={{{state|collapsed}}}). Regarding duplication, it should be possible to only show this template's output if called from {{navbox}}: add {{collapsible option|some_parameter=1}} to the latter and have this template return nothing if the parameter isn't set. SiBr4 (talk) 21:44, 19 February 2016 (UTC)[reply]
Template-protected edit request on 8 October 2016
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please see {{Collapsible option/sandbox}}. The instances of {{</includeonly>BASEPAGENAME<includeonly>}} should be changed with {{</includeonly>{{#if:{{{nobase|}}} | |BASE}}PAGENAME<includeonly>}} to prevent potentially confusing instructions on templates (such as Template:AC/DC) which are subpages. This will allow {{AC/DC}} to show the help {{AC/DC |state=collapsed}} instead of {{AC |state=collapsed}}. This is especially useful in this case, as {{AC}} is used by ArbCom.
-- The VoidwalkerWhispers20:44, 8 October 2016 (UTC)[reply]
In addition, the layout and the use of the <code></code>-style boxed text for both the parameters |state=collapsed and the example use (e.g. {{Nordic Council |state=autocollapse}}) is confusing. We currently have something that looks like this:
How to manage this template's initial visibility
To manage this template's visibility when it first appears, add the parameter:
|state=collapsed to show the template in its collapsed state, i.e. hidden apart from its titlebar – e.g. {{Nordic Council |state=collapsed}}
|state=expanded to show the template in its expanded state, i.e. fully visible – e.g. {{Nordic Council |state=expanded}}
|state=autocollapse to show the template in its collapsed state but only if there is another template of the same type on the page – e.g. {{Nordic Council |state=autocollapse}}
Unless set otherwise (see the |state= parameter in the template's code), the template's default state is autocollapse.
I suggest restructuring, adding bullet points and correcting the false implication that the autocollapse is dependent only on other templates ("another template of the same type"), which is incorrect ... something like this, perhaps:
How to manage this template's initial visibility
To manage this template's visibility when it first appears, add the parameter:
|state=collapsed e.g. {{Nordic Council |state=collapsed}}, to show the template in its collapsed state, i.e. hidden apart from its titlebar
|state=expanded e.g. {{Nordic Council |state=expanded}}, to show the template in its expanded state, i.e. fully visible
|state=autocollapse, e.g. {{Nordic Council |state=autocollapse}}
shows the template collapsed to the header line if there is a {{navbar}}, a {{sidebar}}, or another table with the collapsible attribute on the page
shows the template in its expanded state if there are no other collapsible items on the page
Unless set otherwise (see the |state= parameter in the template's code), the template's default state is autocollapse.
Opening: "To set this template's ... when it first appears"
Use either "title bar" or "header line", not both.
Last sentence "Unless ..." is a double: "Unless otherwise" and "default" are the same. Maybe write: Default behaviour, when a parameter value missing, is |state=autocollapse. -DePiep (talk) 08:15, 2 November 2016 (UTC)[reply]
I agree with your points. I've added the box title (How to manage this template's initial visibility) to show some additional repeated text. Let's see what other comments come in. Scarabocchio (talk) 08:28, 2 November 2016 (UTC)[reply]
I've removed the box title, and replaced 'header line' with 'title bar'. I can't find a satisfactory way of explaining the template default default (sic) display mode without using a lot of text. Perhaps just lose the final line, given that we cannot say what the default setting for any given template will be? State of play so far:
To manage this template's initial visibility, add the parameter:
|state=collapsed e.g. {{Nordic Council |state=collapsed}}, to show the template in its collapsed state, i.e. hidden apart from its title bar
|state=expanded e.g. {{Nordic Council |state=expanded}}, to show the template in its expanded state, i.e. fully visible
|state=autocollapse, e.g. {{Nordic Council |state=autocollapse}}
shows the template collapsed to the title bar if there is a {{navbar}}, a {{sidebar}}, or another table with the collapsible attribute on the page
shows the template in its expanded state if there are no other collapsible items on the page
Even better. I like the listing setup (but I'm a technician, other people may like a more verbose description). Consider using "collapsed" not "in its collapsed state": needlessly long. Etc for "expanded". -DePiep (talk) 10:28, 2 November 2016 (UTC)[reply]
The repetition of the state (collapsed..collapsed..collapsed) is a bit clunky. Perhaps lose the last one in each option:
|state=collapsed e.g. {{Nordic Council |state=collapsed}}, to show the template hidden apart from its title bar |state=expanded e.g. {{Nordic Council |state=expanded}}, to show the template fully visible
Following discussions here and here with DePiep, we have evolved an improved version of the documentation text, one which:-
clarifies what affects the state of the autocollapse, removing erroneous statement about 'another template of the same type'
adds bullet points into the structure to make it clearer and more obvious that there are three options
presents the options in a language that is accessible to the majority of readers
Please change the documentation to read as follows:
To set the template's initial visibility, you can use parameter |state=
|state=collapsed: {{Nordic Council |state=collapsed}}, to show the template collapsed, i.e. hidden apart from its title bar
|state=expanded: {{Nordic Council |state=expanded}}, to show the template expanded, i.e. fully visible
|state=autocollapse: {{Nordic Council |state=autocollapse}}
shows the template collapsed to the title bar if there is a {{navbar}}, a {{sidebar}}, or some other table on the page with the collapsible attribute
shows the template in its expanded state if there are no other collapsible items on the page
Specifically, this involves
removing the initial (and redundant) header line 'How to manage this template's initial visibility'
changing the texts as given, replacing the example 'Nordic Council' with the template name
removing the last line about the possible initial state, as this does not (and cannot) identify the initial default state, and the default is irrelevent to someone who wishes to explictly set a given state.
Apologies for the lack of an explicit target ... this is a template that creates a divbox of documentation information. The text to be replaced is that which is the output of the template itself, NOT the /doc text. Scarabocchio (talk) 13:41, 10 November 2016 (UTC)[reply]
There should probably be something about the last option being the default, even if it's only:
To set the template's initial visibility, you can use parameter |state=
|state=collapsed: {{Nordic Council |state=collapsed}}, to show the template collapsed, i.e. hidden apart from its title bar
|state=expanded: {{Nordic Council |state=expanded}}, to show the template expanded, i.e. fully visible
|state=autocollapse: (default) {{Nordic Council}} or {{Nordic Council |state=autocollapse}}
shows the template collapsed to the title bar if there is a {{navbar}}, a {{sidebar}}, or some other table on the page with the collapsible attribute
shows the template in its expanded state if there are no other collapsible items on the page
Other than that, I'd like to see the exact code change as suggested in the sandbox, since this template is used on nearly 99,000 pages. Paineu/c13:51, 10 November 2016 (UTC)[reply]
My understanding of the current phrase "Unless set otherwise (see the |state= parameter in the template's code), the template's default state is autocollapse" is that autocollapse is NOT necessarily the default, and cannot be described as such. Scarabocchio (talk) 14:37, 10 November 2016 (UTC)[reply]
To editors Scarabocchio and DePiep: I think I see what both of you mean; however, I'm still not clear what is meant by "the statement is incorrect". The statement is only incorrect if the |default= parameter is not used when it should be used, e.g., |default=expanded. If "expanded" is used in the "default" parameter, then the last word becomes "expanded", rather than "autocollapse". How exactly is that "incorrect"? Paineu/c02:19, 11 November 2016 (UTC)[reply]
Adding any heading would blindly change the page layout on 99k pages. So better not into this proposal. Worth a separate development though. -DePiep (talk) 15:36, 10 November 2016 (UTC)[reply]
Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. I don't see much opposition to updating the template, but please come to some sort of consensus about what that update will be first. Each thread so far has changed the sandbox, and personally I'd like to see a "yeah, that looks good" from more than one person before "the change" is implemented. Primefac (talk) 21:09, 10 November 2016 (UTC)[reply]
You're right to do so, but a consensus was disrupted after the template was added. Hard to blame the OP for this. On top of this, editors did not simple !vote against because of an obvious error, but started the discussion anew, thereby even introducing an error -- then leaving. In other words, drive-by editors reopened the talk instead of understanding the Request-process, thereby driving the process in the mud. -DePiep (talk) 22:17, 10 November 2016 (UTC)[reply]
I realize that you and the proposer have worked on this very hard, and I do consider it very nice work for the most part; however, there may be implications that need to be addressed. For example, some pages like {{Nordic Council}} use a /doc page rather than to directly apply this template, as is done at {{Counties of Sweden}}. That means that the div box used here will appear within that /doc page as another little box – a box within a box. That's okay with me, but is it acceptable to all? Only a discussion would determine that for certain. Paineu/c02:48, 11 November 2016 (UTC)[reply]
The divbox is not part of the intended solution -- it was used here on the template talk page merely to show what that solution might look like on the page. Now that the sandbox exists, it can be cut. Scarabocchio (talk) 07:27, 11 November 2016 (UTC)[reply]
Good points, you both. Scara and I missed the point to state exactly which code to replace. I suggest we prepare a new/improved proposal from this, then add a new request template. (also to address: current version opens with a bold line. Should return to not break doc page layout that use this). Scarabocchio, will be back on this later on. -DePiep (talk) 10:53, 11 November 2016 (UTC)[reply]
about the default setting
To editor Scarabocchio: I can see how this template can be confusing, and especially how the wording you changed in the last sentence in the sandbox may have been confusing. The way you have it now appears to indicate that the template/navbar on which this /doc-type template goes has a state that is determined by the |default= parameter in this /doc-type template, which isn't true. The navbar's default state is determined by its |state= parameter, and then the |default= parameter in this /doc-type template may be used to actually show what the navbar's default state setting is. Paineu/c06:55, 14 November 2016 (UTC)[reply]
To editor Paine Ellsworth: Hmmm ... I still think that my version is correct (ie the initial state comes from |state=, falling back to a default from |default=). I'll try and reword it. The key thing that should be included if any text on the default is included, is that that default value itself comes from a parameter. ie that it may change in the future, and should not be depended on by any editor that wants a particular initial state set. Scarabocchio (talk) 08:27, 14 November 2016 (UTC)[reply]
Okay then, but you might want to keep in mind that the |default= parameter in this template does nothing to actually control the default state in the template to which it's applied. That's controlled only by the |state= parameter in the templates to which this template is applied. The wording should reflect that, as it did before you changed it. Paineu/c10:52, 14 November 2016 (UTC)[reply]
Why does the |default= parameter even exist? The main template's initial state, ie its default state, is set by |state=. Using |default= to overwrite the setting made in the very same code is redundant. What's the problem if we remove |default= from this documentation page completely? -DePiep (talk) 12:41, 14 November 2016 (UTC)[reply]
To editor DePiep: The |default= param exists in this template to notify editors that the default state in any particular navbar is differently defined by the template's |state= param from the usual default of "autocollapse" (and to show when it's not differently defined and is still "autocollapse"). It's still a good question, though, because in a fairly high sample of the usages, I found none that had a change in the default state to "expanded" or "collapsed", so maybe the param can be removed? Paineu/c18:28, 14 November 2016 (UTC)[reply]
I get it, not redundant then, but to document what the default |state= is set to for the particular main template. I suggest: |default= should add to the proper bullet text (1/3): "This is the default state for this template.", nothing more. -DePiep (talk) 21:11, 14 November 2016 (UTC)[reply]
I don't like the idea that the default (ie the setting chosen if state= is not set) can change without describing how it might do so. To declare that a value has a default will risk that someone depends on it. If the default is given, the parameter should be described (or at least mentioned). That said, my favoured solution is to use the documentation to tell the editor how to set a given state, and leave out all mention of the default (choice and parameter). In the mean time:
re the default (ie the setting chosen if state= is not set) can change without describing how it might do so: so that default is changed by changing code inside the main template (template programming). However, this doc template is aimed at template-users (=editors editing an article). Because of this, 'changing the default inside the main template' is not topic of this doc template. At most, this doc template could describe what that default setting is. ('if you do not set the |state= parameter, the template will show xxx on the page.'). -DePiep (talk) 13:50, 15 November 2016 (UTC)[reply]
I also concluded (as a line of thinking): 1. remove all reference to any 'default' from this doc page; 2. insert just a 'default' mentioning that is needed in this doc. -DePiep (talk) 15:23, 15 November 2016 (UTC)[reply]
OK, not to be changed in this proposal then. However, a point can be made that this template should have /doc style always (including light green background). -DePiep (talk) 12:42, 14 November 2016 (UTC)[reply]
Can a statement be added to creators and other editors who come across this template be added that says something along the lines of:
You may copy and paste {{BASEPAGENAME}} to articles that should be transcluded.
Maybe below the initial visibility section? That way, no one will need to copy/paste {{BASEPAGENAME|state=autocollapse}} into articles when the template parameter for "state" is already set for that. --StarcheerspeaksnewslostwarsTalk to me17:56, 2 February 2018 (UTC)[reply]
I only added |state=autocollapse to see if a lack of any state set in the template was causing the |state=expanded not to work. I've now removed it from the template, but it is still appearing collapsed... If there's something else that needs to be done, could you advise what? Cheers, Number5720:53, 23 September 2021 (UTC)[reply]
This edit removed the statename variable, but the current documentation still mentions it. Should it be restored to the template, or should it be removed from the documentation? jlwoodwa (talk) 03:24, 3 July 2023 (UTC)[reply]
Readability overhaul
I have overhauled the design of this template to improve readability; see the testcases to preview it. The new design shortens the text, removing a bunch of redundancy. Please let me know what you think; I'll plan to implement in a day or so if there are no concerns. Cheers, {{u|Sdkb}}talk20:13, 22 July 2023 (UTC)[reply]
I support this overhaul in general, but I don't think it looks right on navbox pages like {{Tommy Wiseau}}, where it is used outside of, and in the absence of, a proper documentation box. The ugly bold "Initial visibility" text provided some indication that there was a break between the navbox content and some sort of explanation. It was ugly but functional. I wonder if we need a built-in heading or something to separate the navbox from this template's content, which is now butted right up against many navboxes and looks like it is part of the template's transcludable content. I'm open to ideas. – Jonesey95 (talk) 03:55, 7 August 2023 (UTC)[reply]
Great idea! I was away for a week, so I hadn't caught up that far before I posted the message above. The replacement template is very nice. – Jonesey95 (talk) 15:35, 7 August 2023 (UTC)[reply]
Could we add syntax highlighting to the 2 bullets?
So that they would appear as:
{{BASEPAGENAME|state=collapsed}} will show the template collapsed, i.e. hidden apart from its title bar.
{{BASEPAGENAME|state=expanded}} will show the template expanded, i.e. fully visible.
WOSlinker and others (myself included) have been adding syntax highlighting to improve the look of template docs for a while, so adding it to templates like these I think is the next logical step. ~Tom.Reding (talk ⋅dgaf)02:16, 27 February 2024 (UTC)[reply]
