Wikipedia:Templates for discussion/Log/2021 January 8: Difference between revisions

January 8

Template:WikiProject banner shell

• 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#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. ProcrastinatingReader (talk) 15:56, 8 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]
• 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]

Template:Column-width

• 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]

Template:Column-count

• 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]

Template:Column-gap

• 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]

Template:Column-rule

• 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]