The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was relisted on 2021 January 19. (non-admin closure) ProcrastinatingReader (talk) 16:06, 19 January 2021 (UTC)[reply]

• Template:Cyprus_dispute_detailed_map (talk · history · transclusions · logs · subpages)

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was merge to Template:University of Heidelberg. (non-admin closure) intforce (talk) 20:24, 15 January 2021 (UTC)[reply]

• Template:Center of Astronomy (University of Heidelberg) (talk · history · transclusions · logs · subpages)
• Template:University of Heidelberg (talk · history · transclusions · logs · subpages)

Propose merging ((Center of Astronomy (University of Heidelberg))) into ((University of Heidelberg)). intforce (talk) 18:07, 8 January 2021 (UTC)[reply]

• Merge There is no reason to have a separate template for "Center of Astronomy", especially with only 3 items. Tradedia^talk 21:59, 8 January 2021 (UTC)[reply]
• Merge no purpose for separate templates here. Elliot321 (talk | contribs) 09:10, 12 January 2021 (UTC)[reply]
• Merge. Too few items for standalone box. ((u|Sdkb)) ^talk 16:11, 12 January 2021 (UTC)[reply]
• Merge, no purpose for separate templates as said above. PyroFloe (talk) 13:35, 13 January 2021 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was consensus against autocollapsing. There is a clear consensus among the community that autocollapsing as the default does not bring enough benefit relative to the costs. The community is nearly evenly divided, and as such there is no consensus, about whether or not to use LUA to only autocollapse if there is beyond a certain number or project banners. Those who did support this option tended to advocate for a number in the 4-6 range. Barkeep49 (talk) 17:12, 16 January 2021 (UTC)[reply]

• Template:WikiProject banner shell (talk · history · transclusions · logs · subpages)

Proposing collapsing this template by default. See testcases here for example before/after. The default can still be overriden on a per-page basis using |collapsed=.

Please note deletion is not proposed. This is just a widely advertised discussion as the most accurate way of gauging consensus of the users of the template, to collapse by default. Talk page discussion last month did not produce an outcome.

Reasons to collapse by default: The expanded default is too much noise on already bloated talk pages, and the information (whilst helpful when needed) is not helpful most times someone is on a talk page, but it adds so much weight to talk pages, eg Talk:Bill Gates or even Talk:Artificial intelligence. On the avg talk page this is quite long and unnecessary extra scrolling, and perpetuates banner blindness. The templates will still be there for those who want to see potentially interested WikiProjects by expanding by clicking "show". Basically this just sets |collapsed=yes by default. Related: Wikipedia:Village_pump_(idea_lab)#Thinking_about_a_radical_reduction_of_talk_page_banners, and the picture on the right (WPBS makes up over half the image!). ProcrastinatingReader (talk) 12:22, 8 January 2021 (UTC)[reply]

• Oppose: use |collapsed=yes where needed. Or, Luafy the existing template to auto-collapse after X or more banners, which might require a larger discussion for consensus for what X should be. This might spur the addition of a default-override parameter as well. Also note the previous discussion @ Template talk:WikiProject banner shell/Archive 6#Collapse by default, where there are 3 Oppose & 1 Support.   ~ Tom.Reding (talk ⋅dgaf)  12:49, 8 January 2021 (UTC)[reply]

  That param can't be set on 2 million pages individually (well, it could by bot, but that's no better than this option). Lua can't do that, it's not technically possible to get pre-parsed templates without this 2014 Gerrit patch. Finally, that discussion was 2 support and 2 oppose, the second of which was yours, and came in afterwards. ProcrastinatingReader (talk) 12:53, 8 January 2021 (UTC)[reply]

  Why would you collapse 1-2-banner shells, which is probably the vast majority?

  Have you used Lua before? It's certainly possible.

  I don't think Redrose64's comments there sound like a Support.   ~ Tom.Reding (talk ⋅dgaf)  13:07, 8 January 2021 (UTC)[reply]

  Please let me know how this is possible with Lua, perhaps you can write a mockup? And I don't believe it is the vast majority, I looked at a sample by clicking "transclusions" and having only 1-2 banner shells, well, I didn't even see that once. They all have way more, and none are collapsed, and nobody is going to collapse a million pages by hand. A banner shell wouldn't be used for just one or two projects anyway. ProcrastinatingReader (talk) 13:08, 8 January 2021 (UTC)[reply]

  It may be possible using gmatch, actually, with the post-parse values, but I'm not sure. ProcrastinatingReader (talk) 13:23, 8 January 2021 (UTC)[reply]

  @ProcrastinatingReader: Do not presume my support unless I explicitly say so. This is not the first time that you have twisted my comments to suit your own agenda. --Redrose64 🌹 (talk) 15:37, 8 January 2021 (UTC)[reply]

  Who said I was talking about you...? 2 support was myself and Mathglot, and 2 oppose being Djm and Tom. I couldn’t extract your position. The rest of your comment is an unsubstantiated aspersion. ProcrastinatingReader (talk) 15:56, 8 January 2021 (UTC)[reply]

  This seems, at best, weaselly. Your support of your own thing is implied. When saying "2 supports", RR is implied when looking at the discussion. Even so, 2 Oppose & 2 Support is by no means reason to do a massive disruptive "trial", and irresponsible use of your WP:TPE permissions.   ~ Tom.Reding (talk ⋅dgaf)  17:12, 8 January 2021 (UTC)[reply]

  There are enough admins watching this page that I trust collectively will make the appropriate decision, either way, whether or not to maintain those rights.   ~ Tom.Reding (talk ⋅dgaf)  17:17, 8 January 2021 (UTC)[reply]

  Chill you all. I don't think it was smart to do it for a total of 4 users discussing a change for a couple million pages, but I don't think, given how simple the change was, that we can or should call it an 'irresponsible use of your TPE permissions'. Easily done, easily reverted. --Izno (talk) 17:56, 8 January 2021 (UTC)[reply]

  Well, all edits are easily reverted, regardless of how complex or how simple they are; it's the mindset & decisions involved when making the edit that exhibit incredibly poor & selfish judgement. I'll leave it at that.   ~ Tom.Reding (talk ⋅dgaf)  20:33, 8 January 2021 (UTC)[reply]

  It was, at the time, 2 support and 1 oppose over the course of one month and 2 days. Yours came afterwards. Perhaps a small quorum, but I didn't think it was too broad of a change. I'm happy to start this TfD, and did so, for wider participation. ProcrastinatingReader (talk) 00:53, 9 January 2021 (UTC)[reply]

• Oppose: also think auto-collapsing after say, four banners, would be a better solution. Is there really no way this can be done? Elliot321 (talk | contribs) 13:03, 8 January 2021 (UTC)[reply]

  As I say above, it's not possible afaik. All the banners are condensed into the same parameter name. The software parses those before the template, or Lua, can parse it. The Foundation said in the Gerrit patch they don't want to add support for this due to VE, or something. The only other way is to change how the template is used by doing a bot run to edit 2 million pages, which is just watchlist spam. And tbh, most pages have more than 3/4 "interested WikiProjects" anyway nowadays. Just click "transclusions" above and skim through. The only pages this isn't bloat on are the ones where it's manually been collapsed, which are few and far between. ProcrastinatingReader (talk) 13:06, 8 January 2021 (UTC)[reply]

• Oppose I'd have thought (but haven't seen numbers) that the majority of article talk pages are not filled with discussion or bloat rather than the project banners, so just using |collapsed=yes where needed seems to be the better solution. Collapsed by default means even less users will even see the ratings, etc. In an ideal world, I'd support auto-collapsing for over X projects (maybe 5), though seems easier said than done. I also wonder how many articles have more than 3 projects lists and don't even use the banner shell at all. -Kj cheetham (talk) 13:14, 8 January 2021 (UTC)[reply]
• Comment: is there a way to make the template show the class and importance if and only if the class/importance is the same for every banner in the parameters? I'm guessing the answer is "no" based on the description of the WP banners being evaluated "before" the template is passed them. This would be my ideal, to have it show "(Rated C-class, low-importance)" in the collapsed shell, because usually that's the information I'm looking for. Without this functionality, I'm not sure I can support because it seems to me less undesirable for people to have to add the "collapse" parameter manually on high-discussion pages than for people to have an extra click or two every time they want to see the class of an article whose talk page has just banners and no discussion. — Bilorv (talk) 13:23, 8 January 2021 (UTC)[reply]

  Bilorv Importance is almost never the same across 3+ Wikiprojects, though. Elliot321 (talk | contribs) 16:42, 8 January 2021 (UTC)[reply]

  @Elliot321: what's the relevance of that comment? In such a case no importance would be shown, by the rule I gave. Is that an issue? — Bilorv (talk) 16:53, 8 January 2021 (UTC)[reply]

  Bilorv not really, I'm just somewhat confused about your use-case given the limits there Elliot321 (talk | contribs) 16:56, 8 January 2021 (UTC)[reply]

• Support I do a lot of editing of medical and anatomy articles. When I am looking at this template, I really only need to know the WikiProject, the class, and the importance. This is stated in the collapsed version. As such, there is no disadvantage to collapsing the WikiProject banner. As already stated, collapsing the banners by default cleans up the page enormously. Even if a page only has one banner, it may have large amounts of talk discussion, and every bit of extra clutter adds up. It is very tedious to have to add the banner collapse every time you want it present. Bibeyjj (talk) 13:23, 8 January 2021 (UTC)[reply]

  @Bibeyjj: one of us is misunderstanding the discussion and it could be me, but my understanding is that we're talking about the "collapsed" parameter, which doesn't just hide the full banners but hides the list of banners (so it just says "This template is of interest to the following WikiProjects: [show]", similar to how it looks when you see the base view at ((WPBS))). Your comment refers to the "uncollapsed" view (which still does collapse the inner WikiProject banners). — Bilorv (talk) 13:27, 8 January 2021 (UTC)[reply]

  @Bilorv: Apologies, I misunderstood the test cases when I looked at them. As has already been said, perhaps the autocollapse feature for the shell can only apply when a certain number of WikiProject templates are included, such as 3 or 4.

As I understand it, there are two levels of collapsing - collapsing at the banner level, which is what this discussion is about, and effectively hides the list of projects, and at a single project level, which is currently already done by default. -Kj cheetham (talk) 13:45, 8 January 2021 (UTC)[reply]

• Oppose Just use |collapsed=yes if necessary. HurricaneCovid _(contribs) 13:55, 8 January 2021 (UTC)[reply]
• Oppose – I need to see the full list of projects every time I look at a talk page. If editors feel it should be collapsed for a certain page, they can do that. -- Michael Bednarek (talk) 13:59, 8 January 2021 (UTC)[reply]
• Luafy to autocollapse at a certain number of banners. Here's my proof of concept: source and showcase. (Please be gentle, this is my first time ever writing Lua. This is ugly, and definitely not the way it should be done). Not sure about the number of banners before it should autocollapse, I've currently set it at six in my PoC. --rchard2scout (talk) 13:57, 8 January 2021 (UTC)[reply]

  Nice! Looks like the pattern matching works. An idea of the number of pages to collapse for would be helpful. My preference is 4. ProcrastinatingReader (talk) 14:01, 8 January 2021 (UTC)[reply]

• Luafy as it appears to be possible. I don't have a great idea for the number of templates to collapse it for. Skarmory (talk • contribs) 14:04, 8 January 2021 (UTC)[reply]
• I'm quite happy to Support this proposal as I am unclear on the benefit of keeping the list of related projects on permanent display. Those interested in seeing the list need only click "Show", and all the information becomes available. It seems a small amount of effort in comparison to the clutter of having all the projects on display, and having to scroll past to get to the list of contents. I do think we need to focus on clearing away the clutter from talkpages in order to make them more attractive and useable for the majority of readers. However, I'm quite prepared to change my support to oppose if someone can give a convincing explanation of the benefit of keeping the projects on permanent display. SilkTork (talk) 14:16, 8 January 2021 (UTC)[reply]
• Luafy to autocollapse per Rchard2scout. My preference would probably be autocollapse at 6 or more projects, followed by 4. Otherwise, oppose on the grounds that |collapsed=yes can just be used. - Favre1fan93 (talk) 15:15, 8 January 2021 (UTC)[reply]
• (edit conflict) Luafy, with thanks to rchard2scout. Same preferences as Favre1fan93. (Oppose original proposal, if that's still necessary to say.) --BDD (talk) 15:17, 8 January 2021 (UTC)[reply]
• Oppose since the majority of talk pages do not have a large number of WikiProjects under the bannershell, so it should not be made default because the bannershell can be added when there are too many. --K. Peake 15:33, 8 January 2021 (UTC)[reply]
• Oppose because I see no advantage but many disadvantages. This is change for the sake of change: rule 1 of making a far-reaching change is that you must demonstrate that there is an actual need for a change. --Redrose64 🌹 (talk) 15:37, 8 January 2021 (UTC
• (edit conflict) Oppose as there is no evidence of a problem on the vast majority of pages this template is used on. I've got no objection to lauifying to autocollapse as long as the number chosen is no smaller than 3. Thryduulf (talk) 15:39, 8 January 2021 (UTC)[reply]
• Oppose there's not that many articles that have 10+ WikiProjects listed, and those that do can manually collapse them. It's not a clutter for 99% of articles, so collpasing them by default would just make 99% of article talkpages worse. Joseph2302 (talk) 16:00, 8 January 2021 (UTC)[reply]
• I think auto collapse would be preferred for some quantity. Yes, it is possible to do this in Lua simply by parsing the argument: you can do the simple thing and just count the number of (( appearing in the parameter of interest, or you can try to parse out all the names if you really think you must (don't do the second one). My personal preference would be 6+ maybe. 4 is borderline for me. --Izno (talk) 17:56, 8 January 2021 (UTC)[reply]

  The thing I'd like to get a handle on is how many pages have more than 4 or so. 3 is not usually problematic. --Izno (talk) 18:17, 8 January 2021 (UTC)[reply]

  Anyway, the fundamental issue isn't "we have a lot of WikiProject banners on each page" (deliberately not "we have a lot of banners on each page; we do), it's "we have a lot of dead WikiProjects for which the banner is only questionably of value". It's probably good to have even inactive WikiProjects advertised, but as I reverse-ranted at someone today, it would be better if we consolidated, redirected, and/or removed the ones that aren't doing a collective good as a central location for organizing. It just needs someone willing to take on that slog of a process. ProcrastinatingReader, sound like you? ;) --Izno (talk) 18:32, 8 January 2021 (UTC)[reply]

  Many times the issue is that too many WikiProjects are tagged, some of only questionable relevance, to the article. Honestly, I don't have the time or energy to edit 2 million pages to go back and correct that, and as for merging WikiProjects together, I have minimal experience in the administration of WikiProjects to be able to do that competently. Counting the number of (( is not possible by the way (which is what I was getting at above) without that Gerrit patch. The way Rchard did it is by parsing the identifier from the parsed banners (wpb%-banner). ProcrastinatingReader (talk) 01:02, 9 January 2021 (UTC)[reply]

• Strong oppose — Per Joseph2302 🔥LightningComplexFire🔥 18:04, 8 January 2021 (UTC)[reply]
• It should be collapsed by default only if there's over e.g. 5 entries. --Joy [shallot] (talk) 18:11, 8 January 2021 (UTC)[reply]

• Strong support Talk page banners get way out of hand, especially in highly-edited articles, ending up spanning several page lengths. This is a good way to cut that down. Further on, we should consider moving auxiliary page information to a separate page from the discussion page... ɱ (talk) 18:42, 8 January 2021 (UTC)[reply]
• Oppose The banner shell does what it is supposed to as is when there are multiple project banners placed on a talk page. Starcheerspeaksnewslostwars^{Talk to me} 19:38, 8 January 2021 (UTC)[reply]
• Strong oppose we already have a customization for articles that this is an issue, |collapsed=yes JackFromReedsburg (talk | contribs) 20:09, 8 January 2021 (UTC)[reply]
• Oppose: As other people stated, the only time this seems like it would be necessary is if there were about five or more, but even then, you can just put |collapsed=yes. benǝʇᴉɯ 20:57, 8 January 2021 (UTC)[reply]
• Oppose: Unnecessary for most pages. As many have already stated, just use "|collapsed=" when necessary. Super Ψ Dro 21:31, 8 January 2021 (UTC)[reply]
• Oppose. On most talk pages, there aren't enough banners for this to be an issue. On the contrary, I feel this proposal has the potential to cause more harm than benefit as it will reduce the visibility of WikiProjects, which have already been suffering from a decline in relevance over the past decade. No objection to using Lua ("Luafying") to collapse automatically past a reasonable threshold. Mz7 (talk) 21:36, 8 January 2021 (UTC)[reply]
• Oppose per above, the param could just be currently used if needed, also TFD was not the place to bring this to. P,TO 19104 (talk) (contribs) 22:05, 8 January 2021 (UTC)[reply]
• I'm with Izno and Thryduulf on this. A half-baked idea is to go to the banner templates for inactive wikiprojects and <noinclude> them so that they don't take up space but are still there if the project becomes active again. — Wug·a·po·des​ 22:41, 8 January 2021 (UTC)[reply]
• Support for simple and plain reasons of practicality. Many objections are based on honorable principles but ignore the reality of Wikipedia having become The Source of First Resort of the internet. It's counter productive to be originalists here. -The Gnome (talk) 22:43, 8 January 2021 (UTC)[reply]
  • What does being the source of first resort have to do with non-reader-facing talk pages? I manage to enjoy the NYT crossword just fine regardless of the clutter on Will Shortz's desk, and our readers will be just fine regardless of how many talk page banners we have. — Wug·a·po·des​ 01:29, 9 January 2021 (UTC)[reply]
• Support, the lengthy list of Projects is contributing to talk page clutter, bloat, and making talk pages unreadable. Collapse by default is a most helpful option, and will save a lot of time in cleaning up talk pages to a more readable state. I can see no benefit to having the amount of real estate on talk given to WPs, and no harm in having them collapsed by default. SandyGeorgia (Talk) 23:02, 8 January 2021 (UTC)[reply]
• Oppose We already have a template to do this... ~ HAL333 23:33, 8 January 2021 (UTC)[reply]
• Oppose – If there is truly a need to collapse the talk page banners, just use |collapsed=yes. BTW, there aren't that many articles that are a part of so many WikiProjects where collapsing is necessary. And if it is needed, it can be done manually. Why force this change upon every single article just because of a problem that exists in a relatively small number? This change will cause more problems than benefits if it is implemented. BTW, the Banners should only be collapsed if we have at least 5 different talk page banners on an article. And even in those cases, the template can already accommodate that. LightandDark2000 🌀 (talk) 23:50, 8 January 2021 (UTC)[reply]
• Oppose Few articles can benefit, those that can can be modified on an individual basis. Andrew nyrtalkcontribs 00:05, 9 January 2021 (UTC)[reply]
• Oppose, the amount of space taken up with the 9 WikiProjects on the template's testcases' page is really not that much. It's only 2 scrolls down to get past that. There are usually more comments on un-archived talk pages that cause one to really have to scroll down several pages. Also, the template, as mentioned above, already has the collapsed parameter available to use for talk pages that have a lot of project templates. I'm afraid that if the projects are hidden by default, that no one will take a look at them, even more so than now! I also hate to have to click and un-collapse the shell to be able to look at the project list. Perhaps, more attention should be given to archiving talk pages, so that they don't get unbelievably long? Funandtrvl (talk) 02:06, 9 January 2021 (UTC)[reply]
  • 2 scrolls is a lot for banners. It diminishes value in other banners, too, as it’s hard to distinguish between the notices. Not as much issue with long talk pages, there’s a TOC to aid with navigation there, and conversation is fine. There’s no organisation with talk page banners though. Yes, it has the collapsed parameter, but it’s rarely used. The support for collapsing conditionally for 3+ but opposing otherwise is strange to me, do people really think this holder is being used for 1 or 2 projects? ProcrastinatingReader (talk) 04:58, 9 January 2021 (UTC)[reply]
    • do people really think Absolutely. I've seen it and I've done it. That said, your characterizing the opposition as having settled on "3+" seems a a misreading; I and at least one or two others are in the 6+ camp, possibly down to 4+. Others supporting 5+. It's not a "3+" thing, it's a "we'll probably end up picking one later" thing. --Izno (talk) 05:32, 9 January 2021 (UTC)[reply]
      • I took a skim by clicking “transclusions” and, assuming that’s a random sample, this doesn’t seem to be true generally. People used 1-2 as an example of why to keep it expanded, such as Tom and Thryduulf (which has a few concurrences). I’m not saying 3 is the reading of the minimum, but low number of projects do appear to be the main reason expressed above, and I don’t think 1-2 projects make up the majority of usages here at all. ProcrastinatingReader (talk) 05:39, 9 January 2021 (UTC)[reply]
• Comment:

  If single project then non collapsing, More than one or any other banners on talk page then collapsing. But I want to digress a bit in related issue.

  But my question is different except for those articles which are in midst of controversy for some reason, talk pages are least visited. Effectively very less participation in Projects in turn many topic projects are inactive. Where there is a members list finding active member for any collaboration requests is too tough so member lists are largely unused.

  Present Wikipedia systems are curator friendly but not encyclopedic writer friendly. Any new article development is thrust upon individual who wishes to work on. Seeking help in expansions is usually too tough and very hard to come bye.

  If one sees hundreds of curation maintenance banners on Top of the article then why not give same opportunity for project banners in the article itself until it grows at least upto B class?

  Or why not use category pages as Project pages and list active encyclopedic writers users directly on Category pages

  Or at least why not have project banners on Category pages itself?

  Thanks Bookku (talk) 04:12, 9 January 2021 (UTC)[reply]

• Oppose. The non-collapsed form allows editors to find wikiprojects and aids collaboration. The vast majority of talk pages in my experience are lacking any discussion at all, and where the project templates are in the way, they can easily be manually collapsed. Espresso Addict (talk) 05:13, 9 January 2021 (UTC)[reply]
• Oppose and would support luafying per rchard2scout. SWinxy (talk) 06:22, 9 January 2021 (UTC)[reply]
• Question - Is it feasible to have some per-user configuration item that determines whether the default state is collapsed? That would (presumably) keep every body happy. Mitch Ames (talk) 13:10, 9 January 2021 (UTC)[reply]
• Support collapsed by default. The banners are unnecessary clutter - they are not, in themselves, a discussion about the article, which is what the talk pages are for. Banners are like road signs - the more of them there are, the less attention we pay to them. In particular, editors are more likely to ignore the ones that matter - and although the WikiProjects are useful, they don't matter, in the sense that an editor can always safely ignore them when discussing or editing the article. Mitch Ames (talk) 13:19, 9 January 2021 (UTC)[reply]
• Comment: I'm glad this change was reverted because I believe that in 95% of cases the uncollapsed version is probably most suitable. I would be happy to work with interested editors (including ProcrastinatingReader, Rchard2scout) on the sandbox and template talk page to develop a more intelligent default collapsing state. It would be useful if editors in this discussion (while you're all here!) to indicate what threshold they would prefer for the banner is collapsed. Personally I could get behind 5 or 6. Regards — Martin (MSGJ · talk) 15:20, 9 January 2021 (UTC)[reply]
  • Comment I'd be happy with 5 or 6. It would be pushing it at 4, and I'd be unhappy with 3. -Kj cheetham (talk) 16:11, 9 January 2021 (UTC)[reply]
• Oppose - removing this template would make clutter worse on many talk pages, not improve it. Therefore I am opposed. If need be this template should be improved, but certainly not deleted. Inter&anthro (talk) 15:45, 9 January 2021 (UTC)[reply]
• Comment: 5 or 6 seems like a reasonable threshold to me as well. I'll write an AWB scan to see what the banner-count-distribution is. Should take ~a week.   ~ Tom.Reding (talk ⋅dgaf)  15:53, 9 January 2021 (UTC)[reply]

  Update to at least 6 after scanning 1M transclusions (see distribution below under #Collapsing criteria).   ~ Tom.Reding (talk ⋅dgaf)  16:36, 13 January 2021 (UTC)[reply]

• Oppose Useful information should be visible. Nothing is lost by having it visible. Debresser (talk) 16:55, 9 January 2021 (UTC)[reply]
• Comment In two different discussions above Tom.Reding and ProcrastinatingReader have brought up the number of projects tagged on a talk page. I loaded the transclusions link above and counted the number of banners inside the shell on a random sample of 119 transclusions. The vast majority of banners are WikiProjects but other ones do occur, notably including vital article and Education course banners. The following table documents my results:

Banners	Instances
1	0
2	15
3	32
4	20
5	16
6	11
7	8
8	5
9	2
10+	10

My subjective impression is that the longer a list the more likely it is to be collapsed, although there is no direct correlation - at least one page (I forgot to note which) was uncollapsed with 10 banners, one page (Talk:Wookey Hole Caves) has two banners and is set to collapsed. Certainly the majority of lists of about 8 or greater are already collapsed. The greatest number of banners I saw on a page was 13 (at Talk:Margaret Mead and Talk:Hypatia). Thryduulf (talk) 16:56, 9 January 2021 (UTC)[reply]

@Thryduulf: thanks, I was itching to see that a rough distribution. I'm doing this for 1M transclusions currently (~50% of all transclusions, since that's AWB's download limit). Will take a few days to process.   ~ Tom.Reding (talk ⋅dgaf)  17:17, 9 January 2021 (UTC)[reply]

• Oppose: as per other comments above, I think lists of relevant WikiProjects and article ratings should remain easily visible/accessible (it's harder to locate the list when it's been collapsed). The current non-collapsed banner shell already helps to significantly cut down on talk page clutter. Alanna the Brave (talk) 17:20, 9 January 2021 (UTC)[reply]
• WikiProjects are treehouses in which grown adults pretend they're in cool clubs. We put up with them because such behaviour occasionally results in psychological behaviour that results in marginal improvements to articles. This is marginal at best, however, given the negatives (primarily ownership and the inevitable pile-ons). Subtly directing people to them is fine; huge advertising banners everywhere isn't. I collapse them on sight in every case. This proposal doesn't stand a snowball's chance in hell because, well, pile-ons, but it's always worth registering when something which is obviously a good idea gets mobbed out of existence on here, for when the aliens arrive and decide what few of us to spare. Chris Cunningham (user:thumperward) (talk) 18:17, 9 January 2021 (UTC)[reply]
• Comment I'm very sympathetic to the overall goal of reducing banner clutter, but it seems there are some hesitations about collapsing banners specifically. If it is to be decided alogirthmically, which I think would be a neat technical solution, the better criteria would be whether or not there are lots of other non-project talk page banners, not whether there are lots of projects. ((u|Sdkb)) ^talk 18:31, 9 January 2021 (UTC)[reply]

• Question? Don't most people fill these parameters out with WP:RATER anyways? Can't we just ask Evad37 to update the script to automatically fill in the collapse parameter =yes if there are more than like 5 WikiProject banners? but like if you want to keep it uncollapsed with more than 5 banners just do |collapse=no? Seems like a simple solution. –MJL ‐Talk‐^☖ 19:50, 9 January 2021 (UTC)[reply]
  • Its possible, but if there's going to be a specific number, using Lua is a neater solution since it will also account for manual edits to add or remove banners - Evad37 [talk] 00:39, 10 January 2021 (UTC)[reply]

• Oppose per most of the cogent arguments for oppose above. Gog the Mild (talk) 22:50, 9 January 2021 (UTC)[reply]
• Support. If it's technically possible to make it so that it collapses by default if there are more than a certain number of banners—four or five, perhaps—that might be ideal. But discussion, not banners, is the purpose of a talk page, so I generally favor making banners as compact as possible. A. Parrot (talk) 23:17, 9 January 2021 (UTC)[reply]

• Luafy – it looks like virtually all opposers here are opposed the default collapsing, but not (or haven't said anything about) collapsing by default after a certain amount (say 4 or more?) Aza24 (talk) 23:15, 9 January 2021 (UTC)[reply]

• Oppose per the various points made. --HistoryofIran (talk) 23:56, 9 January 2021 (UTC)[reply]
• Support I have never noticed the project templates being of any value and they seem to be used indiscriminately as if they were categories. The less we see of them, the better. Andrew🐉(talk) 00:06, 10 January 2021 (UTC)[reply]
• Oppose - this seems to be a solution in search of a problem. The vast majority of talk pages with unreasonable numbers of banners are already collapsed. While Luafying could in theory be acceptable, the threshold would have to be pretty high - e.g. eight or ten - for the inconvenience of scrolling to outweigh the inconvenience of expanding. Extraordinary Writ (talk) 00:26, 10 January 2021 (UTC)[reply]
• Luafy per Rchard2scout and others as the solution that will give the best result in most cases: uncollapsed when there are only a few projects, collapsed when the length of the list starts to become overwhelming, and with manual overrides for other cases such as when there's lots of other banners and only a few projects, or a moderate amount of projects but no other banners - Evad37 [talk] 00:33, 10 January 2021 (UTC)[reply]
• Strongly Support collapsed by default. Wikiprojects are of interest to only some editors. Its more important to let the information & request banners get more notice. Having to click "Show" is not a big deal. — Lentower (talk) 04:09, 10 January 2021 (UTC)[reply]
• Comment. Ideally, the text "This template is of interest to the following WikiProjects:" would be changed to: "This template is of interest to these WikiProjects: <LIST_OF_WIKIPROJECTS>." What the WPs are for a page is more important to most editors than the details at either level of expansion. I don't know how hard it would be to program this. — Lentower (talk) 04:09, 10 January 2021 (UTC)[reply]
• Oppose: On the vast majority of talk pages, banners are the only item. They serve the useful purpose of article assessment and should be visible.--Ipigott (talk) 08:28, 10 January 2021 (UTC)[reply]

Oppose, there already exists the ability to collapse it for those few articles that require it. Cavalryman (talk) 08:32, 10 January 2021 (UTC).[reply]

• Support. The headlines (class and importance) appear also in the folded version. In the current situation, there is unnecessary scrolling, while technicalities take precedence over conversations. gidonb (talk) 12:42, 10 January 2021 (UTC)[reply]
  • @Gidonb: No, the version that shows the project, class and importance is the uncollapsed version. The collapsed version just says "This article is of interest to multiple WikiProjects. [Show]". Compare Talk:Wookey Hole Caves (collapsed) and Talk:Cheddar Gorge (uncollapsed). Thryduulf (talk) 13:15, 10 January 2021 (UTC)[reply]
    • I stand corrected. What I really want is that one line per project and quickly move on to the discussions. When I need more project detail, I open these. Accordingly, oppose and fold any and all project templates, regardless of how many and what may come next and whether a shell was added or not. gidonb (talk) 14:32, 10 January 2021 (UTC)[reply]
• Oppose: in agreement with the arguments already made.--Johnsoniensis (talk) 13:01, 10 January 2021 (UTC)[reply]
• Oppose: unnecessary, and would get in the way of article maintenance. -- The Anome (talk) 13:26, 10 January 2021 (UTC)[reply]
• Modulise (is that even a word?) as per Rchard2scout's example, pending consensus on the maximum number of banners to be listed before auto-collapsing kicks in (probably 4 or 5 IMO). -- PinkPanda272 (talk/contribs) 14:29, 10 January 2021 (UTC)[reply]
• Luafy to autocollapse at a certain number of banners, as others mentioned. 4-5 sounds sensible. Maybe we even want to look at the current distribution of number of banners to decide on the exact cut. --MarioGom (talk) 18:31, 10 January 2021 (UTC)[reply]

  @MarioGom: I looked at a random sample of 119 transclusions for exactly that reason, my results are in the table above. Tom.Reding is in the process of doing the same on 1 million transclusions but this will take a few more days to produce results AIUI.
  If this discussion does end in a consensus to autocollapse at a certain number of transclusions there will not unlikely need to be a subsequent discussion about the exact number (I'm guessing that will be on the template talk page?). Thryduulf (talk) 21:16, 10 January 2021 (UTC)[reply]

• Oppose - It isn't that hard to place |collapsed=yes where needed. - Knowledgekid87 (talk) 23:54, 10 January 2021 (UTC)[reply]
• Luafy as per the solution proposed by Rchard2scout, above. This solution would declutter talk pages, while allowing for a more flexible solution that's tailored to the relative number of banners already on the page. Edge3 (talk) 02:15, 11 January 2021 (UTC)[reply]
• Oppose. Oops, I was thinking of the wrong template with my previous !vote. I do like seeing which projects an article's in; if this adds to talk page bloat maybe the problem is the projects ... I have seen some which are rather marginal to the article subject. Daniel Case (talk) 04:11, 11 January 2021 (UTC)[reply]

  @Daniel Case: maybe you're right, but we have 2 million talk pages this template is used on. Who's going to go back and check/adjust 2 million talk pages, and teach NPPs to tag less projects? And even if that's done, is that actually a good use of anyone's time? High time investment for relatively low reward, whereas both the main proposal and the luafy proposals here are low time investment for high reward. ProcrastinatingReader (talk) 05:01, 11 January 2021 (UTC)[reply]

• Comment. Numerous-- probably thousands-- of articles have used the collapse parameter. If the template is set to autocollapse directly, will it harm the talks wherein a collapsed parameter is set? There's no way we can refurbish all articles in a snap. GeraldWL 06:36, 11 January 2021 (UTC)[reply]

  It would only change the default. If an article already sets |collapsed= as yes or no, that will take precedence and be respected rather than defaults. This will only change the view where no value is specified manually (which is the majority). ProcrastinatingReader (talk) 06:40, 11 January 2021 (UTC)[reply]

• Oppose with sympathy but isn't it snowing already? All the best: Rich Farmbrough 13:09, 11 January 2021 (UTC).[reply]
  
• Oppose I think this is obviously a net-negative when there are only 1 or 2 items in the box; why add a click for minimal space gains. I'd be neutral to a lua-based collapsing when there are 5 or more entries, but don't think that's necessary. In the egregious cases (Talk:Margaret Mead) it can be added by hand or by AWB if nobody does the LUA. power~enwiki (π, ν) 01:26, 12 January 2021 (UTC)[reply]
• Support, underdog position here but I agree that if it is possible to target only those with more than 3-5 then it should auto-collapse. HLPD (talk) 06:13, 12 January 2021 (UTC)[reply]
• Oppose It is literally stupid and not worth to discuss. If there is no bannershell then how can you refurbish or republish the needed information when necessary? Okay, I am not always on point, but why deleting it? Very uncanny and caused more harms in long term. ZaDoraemonzu (talk) 14:30, 12 January 2021 (UTC)[reply]

Comment: please remove immediately the message about this discussion to readers. Such internal Wikipedia messages are appropriate for editors only. CapnZapp (talk) 13:51, 12 January 2021 (UTC)[reply]

This template is only used on talk pages, so the message about this discussion should only be visible to people who are interested enough in editing Wikipedia to look at talk pages. Mz7 (talk) 19:16, 12 January 2021 (UTC)[reply]

Oppose Just no. That's not the point of the bannershell. CapnZapp (talk) 13:51, 12 January 2021 (UTC)[reply]

CapnZapp It's not being discussed for deletion, it's being discussed whether it should be collapsed or not by default. Joseph2302 (talk) 16:00, 12 January 2021 (UTC)[reply]

• Support talk page clutter is getting out of hand, and realistically very very few people actually go to the talk page to click through onto a WikiProject, most are there to discuss something. Even better I like the idea of an autocollapse past a certain number, perhaps 3. EoRdE6^{(Come Talk to Me!)} 17:02, 12 January 2021 (UTC)[reply]
• Strong support: It's always been Auto Collapse, so I don't know why this is a "thing" now, but hey, go for it. If it clears up clutter, I'm all for it. :) - Neutralhomer • Talk • 23:15 on January 12, 2021 (UTC) • #WearAMask • #BlackLivesMatter
  • But it hasn't always been Auto Collapse...? It's curently collapsed at an individual project level, but not at the banner level, which is what is being discussed here. -Kj cheetham (talk) 15:03, 13 January 2021 (UTC)[reply]
• Oppose Can be collapsed individually if necessary; most of the complaints are about articles with a large number of wikiprojects/templates, but realistically most articles don't have many and collapsing would hurt more than help overall. Zoozaz1 talk 00:02, 13 January 2021 (UTC)[reply]
• Oppose: the banner generally takes up little room and having it collapsed reduces its usefulness since WP ratings can no longer be checked at a glance. Praemonitus (talk) 04:23, 13 January 2021 (UTC)[reply]
• Oppose, although I think that it is a little bit cluttered, collapsing it automatically is a little over the top as glancing at it's Wikiprojects grade without extra hassle is pretty useful. PyroFloe (talk) 13:22, 13 January 2021 (UTC)[reply]
• Oppose the box is far less useful if you can't see the projects and ratings at a glance. It's fine as is and in 99% of cases requires barely any scrolling. This change would actively harm most of the talk pages that have this template. LEPRICAVARK (talk) 14:59, 13 January 2021 (UTC)[reply]
• Super strong support, which should count as like two or three support !votes, because talk page banners are unwieldy. I especially super strong support (four !votes) autocollapse for 6 or more (or any numerical cut-off) per Tom's impressive analysis below. Levivich ^harass/_hound 04:01, 14 January 2021 (UTC)[reply]

@Levivich: Got a good laugh by imagining someone responding to this with a super-duper double dog oppose or something on that order . — Godsy ^(TALK_CONT) 10:12, 15 January 2021 (UTC)[reply]

• Oppose; noting that some editors stating "support" seem to have misunderstood what would be collapsed, and are only consciously supporting the collapse of the project banners to one line each. I visit talk pages to check that relevant projects are already there in order to generate alerts, so I do not want to have to also click "Show" on each one where WPBS is present. – Fayenatic London 11:34, 14 January 2021 (UTC)[reply]
• Comment: It seems unlikely that consensus for a change is going to be achieved here. This TfD should be closed, if only so talk pages can go back to looking normal again. Morgan695 (talk) 19:18, 14 January 2021 (UTC)[reply]

  This TfD is up for closure from tomorrow anyway (TfDs are 7 days), and I think at least the luafy proposal stands a chance! ProcrastinatingReader (talk) 09:14, 15 January 2021 (UTC)[reply]

• Luafy per those above (especially rchard2scout) with a preference of autocollapsing at 5 or more (with thanks to Tom.Reding below). — Godsy ^(TALK_CONT) 09:52, 15 January 2021 (UTC)[reply]
• Oppose Only use it when needed for excessive projects that clutters up the talk page, no need for if theres only 1 or 2 projects. The C of E God Save the Queen! (talk) 18:59, 15 January 2021 (UTC)[reply]

  Per data below, 1 or 2 projects makes up just 13.42% of the usage of this template. ProcrastinatingReader (talk) 19:02, 15 January 2021 (UTC)[reply]

• Mixed. I think this proposal does no harm, but it does no good either... at least for certain talk pages. I think that you can do it by yourself, but at the same time what if you don't need to? Ugh, flummoxed. Either way, I'll support whatever is the outcome. GeraldWL 06:37, 16 January 2021 (UTC)[reply]
• Oppose: Per previous discussion somewhere else. I'd also note the collapsed=yes is very hard to spot when a lot of other talk page top templating is in use being swamped by dyk from X years ago and the like at times.Djm-leighpark (talk) 07:44, 16 January 2021 (UTC)[reply]
• Oppose. There is no need to collapse for even half a dozen or so projects, never mind one or two. If the number of projects on one page is well into double figures with several other templates also present, then that page can be managed on an individual basis. No Great Shaker (talk) 09:52, 16 January 2021 (UTC)[reply]

Collapsing criteria[edit]

A substantial portion of editors above seem to be interested in or at least open to the possibility of collapsing by default under certain circumstances. I'm opening this subsection to figure out, if we pursue that path and assume technical feasibility, what criteria we'd ideally want to use. Most proposals so far have dictated a specific number of projects, but personally I think the more relevant criterion is number of other non-project banners, since the issue is not talk pages with 7 projects and nothing else, but rather those with several projects in addition to a sea of other banners that add up to clutter the top of the page. Thoughts? Note: This section is not the place to express general opposition to any collapsing; comments doing so will be collapsed or moved. ((u|Sdkb)) ^talk 10:10, 10 January 2021 (UTC)[reply]

Absolutely, you are on the right track. It is often the sea of other banners that make the talk page unmanageable, and some of those banners (for example, discretionary sanctions) are essential and should not be lost amid lesser critical talk page clutter. I don't know how one can measure this eg via bot or script or even manually, because there are so many kinds of banners, used and not used correctly, but one knows it when one sees it :) Even if a bot could so something like measure the length of everything on the page, that might not be a good measure, as talk pages often include templates that should have/could have been rolled in to other banners or articlehistory, and often include things like duplicates of archive boxes (one in talk header, and additional one below), and duplicates of "find sources" templates (one in talk header, and an additional below). Alternately, if a talk page has nothing but an articlehistory and two WikiProjects --> no action needed, no talk clutter. When a talk page has a sea of other banners, many essential, then collapsing even two or three WikiProjects in the banner helps. How to measure any of this or assign criteria when talk pages are typically cluttered for many different reasons? Overall length, number of other banners, number of other templates-- even if those have not been incorporated into articlehistory-- are all factors that confuse the picture. One knows it one sees it and is cleaning up talk pages, and there are cases where collapsing even two WPs into banner is necessary. SandyGeorgia (Talk) 11:15, 10 January 2021 (UTC)[reply]

SandyGeorgia, regarding feasibility, as I envision it, the bot could count the number of templates on a page within Category:Talk header templates, and if there are more than X, it would autocollapse the WikiProject banner. That's still not perfect, and there's a lot of room for more fundamental reform, but it's a step closer. ((u|Sdkb)) ^talk 16:18, 12 January 2021 (UTC)[reply]

I agree with SandyGeorgia. Number of banners inside the shell is objective and easy to measure but only partly relevant. Total number of templates is also objective and relatively easy to measure (although by not not in any individual template), but only tangentially relevant as which boxes are important is subjective as it depends on which other boxes are on the page and the vertical space they take up (and pages with lots of banners usually have the WikiProjects collapsed already). Thryduulf (talk) 13:28, 10 January 2021 (UTC)[reply]

Good idea, but I fail to see how it could be implemented within this template, in its relationship to other templates. Aren't there too many variables? Funandtrvl (talk) 00:34, 11 January 2021 (UTC)[reply]

Collapsing past four would be good, imo. Sure, it's not the best solution possible, ideally it'd check with other templates, but it's something that we can do, better than nothing. Elliot321 (talk | contribs) 08:41, 11 January 2021 (UTC)[reply]

• Collapse when at least 6 or more banners exist

I scanned ~half of the ~2M transclusions of ((WikiProject Banner Shell)) to determine the banner-count distribution. User talk pages, and pages with PUA characters, those protected, or since-deleted, were excluded. The overwhelming majority were mainspace (910,525) & category (83,919) talk pages, comprising 99.5% of all scanned talk pages.

Graphs are unavailable due to technical issues. There is more info on Phabricator and on MediaWiki.org.

Banner Count	Page Count	% of Total	Cum. % of Total
0	390	0.04%	0.04%
1	4,742	0.47%	0.51%
2	129,003	12.90%	13.42%
3	528,731	52.89%	66.30%
4	216,367	21.64%	87.94%
5	77,243	7.73%	95.67%
6	25,712	2.57%	98.24%
7	9,287	0.93%	99.17%
8	4,076	0.41%	99.58%
9	1,869	0.19%	99.76%
10+	2,351	0.24%	100.00%
Total	999,771	100%	100%

For anyone writing the module, the worst (but rare) exceptions I found to "counting opening curly brackets" were Book talk:Eminem & Book talk:Pope John Paul II, which should be checked against any working module to accurately count their banners.

Given this distribution, my vote is to default auto-collapse when at least 6 or more banners exist, thereby affecting, at most, only the worst ~4.3% of transclusions. I'm ok with a higher banner-count threshold as well.   ~ Tom.Reding (talk ⋅dgaf)  16:33, 13 January 2021 (UTC)[reply]

Comment I primarily want to say thank you for pulling that data together! Actual data is always good to see. I'd definitely support collapsing for 6 or more. -Kj cheetham (talk) 17:12, 13 January 2021 (UTC)[reply]

Comment. I echo Kj cheetham on both points, good job Tom.Reding on helping visualize this issue, and default auto-collapse when it hits 5 or 6 banners sounds good too. Cordially, History DMZ ^{(talk)+(ping)} 03:50, 14 January 2021 (UTC)[reply]

Comment. I love that the bottom of this thread is a graph that looks like a raised middle finger. Levivich ^harass/_hound 03:59, 14 January 2021 (UTC)[reply]

Thanks very much for gathering the data, Tom. Personally, I think 4 is best, as roughly the length of 2 British English talk notices, but am OK with 5 also. Pages could always override if there's a particular reason to expand. ProcrastinatingReader (talk) 12:40, 14 January 2021 (UTC)[reply]

Re curly brackets, Rchard's solution looks for the talk notice class (see source), not the curly braces which aren't possible to check (per my comments above - the braces are expanded by the time it hits the Lua module), so those edge cases shouldn't pose a problem I think. ProcrastinatingReader (talk) 12:43, 14 January 2021 (UTC)[reply]

Other criteria[edit]

(Creating subsection to discuss other subtopics that are not collapsing criteria.)

Quoting my comment from Template talk:WikiProject banner shell:

I'm also wondering if we added a class to some element in the collapse banner at the same time, whether that would permit the development of a script to modify [collapse] behavior per user opt-in in their common.js.

The point being, is that once the default behavior is hashed out in other discussion here, then users who felt strongly one way or the other, could have it their own way. Mathglot (talk) 21:14, 14 January 2021 (UTC)[reply]

Excellent suggestion. Best of both worlds. Levivich ^harass/_hound 21:18, 14 January 2021 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was delete. (non-admin closure) ProcrastinatingReader (talk) 09:12, 15 January 2021 (UTC)[reply]

• Template:Column-width (talk · history · transclusions · logs · subpages)

Per WT:Manual of Style/Accessibility#Group of users interested in changes to CSS, we no longer need the vendor prefixes for any interesting quantity of traffic. As such, this template will be a simple statement of the CSS for a column gap. This template can be made trivially inline, or where needed for templates, in TemplateStyles. The template cannot be implemented as a TemplateStyles directly. Accordingly, we should subst and delete.

I've removed the last major users preliminarily, reflist and refbegin (and div col), so the count of uses should diminish soonly. (In fact, the count is now closer to 600k rather than the template-reported 900k.) Izno (talk) 06:17, 8 January 2021 (UTC)[reply]

• Subst and delete Insufficient complexity of markup to warrant a template. * Pppery * _{it has begun...} 16:01, 8 January 2021 (UTC)[reply]
• Comment: This search may be useful in finding any remaining uses (the rest are probably from server caching). Plastikspork _―Œ^(talk) 19:38, 8 January 2021 (UTC)[reply]

  Down to 478k from 947k not too long ago, and down from 600 from 24 hours ago. Exciting ~. Anyway, my query would be this one of course. --Izno (talk) 05:37, 9 January 2021 (UTC)[reply]

• substitute and delete, doesn't do much now that the moz and webkit lines have been removed. Frietjes (talk) 00:34, 14 January 2021 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was delete. Plastikspork _―Œ^(talk) 20:05, 15 January 2021 (UTC)[reply]

• Template:Column-count (talk · history · transclusions · logs · subpages)

Per WT:Manual of Style/Accessibility#Group of users interested in changes to CSS, we no longer need the vendor prefixes for any interesting quantity of traffic. As such, this template could be a simple statement of the CSS for a column count.

However, unlike the other column properties, the current major implementer of this template that I'm aware of is ((refbegin)), where I'm currently entertaining using the same trick as in ((reflist)) to change the column count to column width driven. This TFD is primarily to verify that would be a reasonable implementation decision, subsequently to implement (probably in both refbegin and this template), and then to subst and delete this template entirely. Izno (talk) 06:14, 8 January 2021 (UTC)[reply]

As a potential note of interest, I've seen some sidebars and infoboxes implementing ((col-begin)) and ((columns)) to get fixed columns into those templates. I think it would make sense to cover that case with a template as something slightly different from the standard ((column-count)) use case (which is generally lists out in the wild), but it would make more sense to have a different helper template for that, which could a) implement TemplateStyles for it and b) restrict the use of that template from the wild to a specific subset of templates, something like .infobox .column-count-helper-2, .sidebar .column-count-helper-2 { column-count: 2; }. There's another use case out in the wild inside of image code that does similar, like this one, where it's awfully awkward to do that in column widths rather than counts. Just something to entertain. Infoboxes and sidebars are flex width em but it's still a hassle not to be direct with the browser. Images can vary in size given the mobile, but in that context I think I'd still be fine being willing to say "just show me 3" (at most; maybe tending toward 2; could also be implemented with columns: 5em 2).

The other such implementation of interest might be display: flex, which is supported by the vast majority of browsers at this point (and which degrades gracefully to full width in the others that we serve, IE9, 10, and Firefox 27). (I need to submit an RM or something for ((flex columns)), which for such a specialized implementation of that template should really be named ((flex portal columns)) or similar. Or even just ((portal columns)), which accurately describes how that is built.) --Izno (talk) 06:25, 8 January 2021 (UTC)[reply]

• Comment: This search may be useful for finding any remaining uses. The rest are probably from transcluding templates using this template. Thanks! Plastikspork _―Œ^(talk) 19:41, 8 January 2021 (UTC)[reply]

  Plastikspork, I prefer this search to catch remainders, which I'll probably work my way through soonly. This is probably the more fun accounting, apparently some 80k uses of the CSS column-count lying around. Just a cool 110 in mainspace though, so. --Izno (talk) 20:14, 8 January 2021 (UTC)[reply]

• I've made a ((image key)) for the one case. Thoughts are appreciated. --Izno (talk) 05:12, 9 January 2021 (UTC)[reply]

  Just to expound somewhere:

  Right now, it's heads or tails how users are adding the ((legend)) template, especially to images. To that end, I've made ((image key)) to sync how things are done. Some people were using one or another of the bad-sad-bad table columns (c.f. Template:Columns/Template:Col-begin), others using a raw div with a style such as <div style="column-count:2">, and I was replacing uses of Template:Columns with Template:Column or ((columns-list)) with a small colwidth just recently per Columns's deprecation/pending deletion. As described above, it's kind of gross to do it that way given how constrained an image is.

  The template also does things a bit better in some ways. It's generally bad to use column-count but I think in this context the use is acceptable given we know we're fairly constrained on space (unlike the rationale for column-width which moved the major columns templates solely to column-width). Maybe not the best name now that I see the name of this one, but we can go from there.

  (I am considering whether to do a media query to make it 1 column on super small screen devices e.g. 100-200px wide.) --Izno (talk) 05:44, 9 January 2021 (UTC)[reply]

  It also uses plain lists as standard. --Izno (talk) 05:44, 9 January 2021 (UTC)[reply]

• substitute and delete, doesn't do much now that the moz and webkit lines have been removed. the image key template looks like a good solution for the remaining uses in articles (and for others that are using ((col-begin))/((col-break))/((col-end))) Frietjes (talk) 00:36, 14 January 2021 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was delete. (non-admin closure) ProcrastinatingReader (talk) 09:11, 15 January 2021 (UTC)[reply]

• Template:Column-gap (talk · history · transclusions · logs · subpages)

Per WT:Manual of Style/Accessibility#Group of users interested in changes to CSS, we no longer need the vendor prefixes for any interesting quantity of traffic. As such, this template will be a simple statement of the CSS for a column gap. This template can be made trivially inline, or where needed for templates, in TemplateStyles. The template cannot be implemented as a TemplateStyles directly. Accordingly, we should subst and delete. Izno (talk) 05:56, 8 January 2021 (UTC)[reply]

• Subst and delete Insufficient complexity of markup to warrant a template. * Pppery * _{it has begun...} 16:01, 8 January 2021 (UTC)[reply]
• subst and delete --DannyS712 (talk) 03:22, 11 January 2021 (UTC)[reply]
• substitute and delete, doesn't do much now that the moz and webkit lines have been removed. Frietjes (talk) 00:36, 14 January 2021 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was delete. (non-admin closure) ProcrastinatingReader (talk) 09:11, 15 January 2021 (UTC)[reply]

• Template:Column-rule (talk · history · transclusions · logs · subpages)

Per WT:Manual of Style/Accessibility#Group of users interested in changes to CSS, we no longer need the vendor prefixes for any interesting quantity of traffic. As such, this template will be a simple statement of the CSS for a column rule. This template can be made trivially inline, or where needed for templates, in TemplateStyles. The template cannot be implemented as a TemplateStyles directly. Accordingly, we should subst and delete. Izno (talk) 05:47, 8 January 2021 (UTC)[reply]

• Subst and delete Insufficient complexity of markup to warrant a template. * Pppery * _{it has begun...} 16:01, 8 January 2021 (UTC)[reply]
• subst and delete --DannyS712 (talk) 03:22, 11 January 2021 (UTC)[reply]
• substitute and delete, doesn't do much now that the moz and webkit lines have been removed. Frietjes (talk) 00:36, 14 January 2021 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).