Archives

Archive 1

This page has archives. Sections older than 30 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present.

Done. Izno (talk) 22:02, 3 August 2024 (UTC)[reply]

Add |imageclass=, |imageleftclass=, and |imagerightclass= parameters as done in the sandbox at Special:Diff/1245579475. This will allow classes such as skin-invert to easily be added to the images. --Ahecht (TALK
PAGE) 20:46, 13 September 2024 (UTC)[reply]

 Done Izno (talk) 23:05, 28 September 2024 (UTC)[reply]

Please add parameter |class=, so that those message boxes that were enabled for it, could pass the parameter to allow user styling, including turning off the box.

My use case is the issue of banner clutter on article talk pages, where there have been disputes about placement of many non-compulsory banners. The easiest way to handle this imho would be to permit the user to enter .banner-foo {display:none} in their common.css, applying it to a class passed in the message box but for that to work we need to have the class available in the box as a parameter. Imho, having this available would reduce the strife about talk page banners that seems to be a perennial issue; those most perturbed could simply turn them off individually. It should be clear that this feature would not permit users to arbitrarily turn off any banner, only those which had the passed the param through (via |class={{{class|}}}) in the *mbox template, and only one by one; so that it would allow adding, say, a |class= param to the {{Tmbox}} for Template:Talk header to allow it to be turned off, but not to an ArbCom template. Those templates are already mostly edit protected anyway, so there shouldn't be any problem with editors maliciously adding a class to an mbox where they shouldn't. (Full disclosure: I generally want to see all message boxes and wouldn't use the feature; I am interested in having it to reduce the disputes and wasted time about the topic by offering it to those who oppose them, and who are sufficiently motivated to go to the point of adjusting their common.css, which should quiet the disputes and keep everybody happy.) Mathglot (talk) 20:48, 14 September 2024 (UTC)[reply]

Listed: at WP:Village pump (proposals). Mathglot (talk) 20:44, 16 September 2024 (UTC)[reply]

I think an opt-in strategy might be better at allaying editor concerns about too many messages. If the message box is designated as a hidden message box, a general class could be added, with a rule that hides content with that class. A parameter could be used to provide a custom class, so someone could create a personal CSS rule to display messages that specified the custom class. Editors who want to see all the hidden messages would just need a personal rule for the general class. isaacl (talk) 22:22, 16 September 2024 (UTC)[reply]

Adding a class per the request maintains the status quo, as no page changes appearance after implementation. That doesn't need a heavy level of consensus, because nothing changes for anybody, unless they want it to. Your approach, if I understand it correctly, would require some committee to decide which templates were hidden by default, and allow users to opt in to view them. That would certainly reduce banner clutter by default, and technically, I see no problem with that. But it would represent a potentially big change to the status quo, and therefore would require a significant level of consensus, and might provoke a contentious discussion, as there have been in the past about the topic. I'm not sure that would serve the goal of reducing strife about banner clutter, and might even make it worse. Mathglot (talk) 11:16, 24 September 2024 (UTC)[reply]

I'm not suggesting that the status quo be changed. By default message boxes remain visible. If by English Wikipedia's usual decision-making processes there's a consensus agreement that some template should be hidden by default, then it would be modified accordingly. I imagine creators of new templates would be the first to try to use this functionality, again to preserve the status quo. isaacl (talk) 00:23, 29 September 2024 (UTC)[reply]

 Not done: but not for the usual reason: this template already supports |class=. It is not advertised because its use should be limited.

That said, for the work you're suggesting I would recommend instead filling in |name=, which will add a class similar to box-name (for example, {{multiple issues}} outputs box-Multiple_issues today), a fact I discovered mostly after I implemented TemplateStyles (which needed support for setting a class). This parameter is fit for the purpose of hiding specific message boxes, unlike the more powerful suggested |class=. Izno (talk) 22:50, 28 September 2024 (UTC)[reply]

That not-done aside, I am definitely on the "we should get rid of as many talk page templates as is feasible and/or consensus allows", which is necessarily going to lead to conflict. For all the usual reasons of banner blindness. Having more classes to target available won't make everyone happy because not everyone can modify their CSS. Unregistered users also read talk pages and shouldn't have to deal with pages upon pages of banners that aren't pertinent to them. Izno (talk) 22:54, 28 September 2024 (UTC)[reply]

Agreed, and my motivation in posting was to improve the situation, if only ever so slightly, without just giving up because it doesn't fix the larger problem by a long shot, which indeed deserves further attention. Very much obliged for the tip about undocumented class; this should remove a roadblock on one particular use case I'm involved with. Thanks again, Mathglot (talk) 23:02, 28 September 2024 (UTC)[reply]

To me, it's just not a scalable approach to say that editors have to continually update their CSS to hide message boxes they're not interested in if the goal is to reduce the effect of banner blindness. So while I think it will be useful for some, and thus it's a good idea to set the |name= parameter, I don't think it's going to "keep everybody happy". isaacl (talk) 00:23, 29 September 2024 (UTC)[reply]

Indeed it isn't scalable, but maybe one day we will get a turn-off-all-TP-banners switch in Preferences, and I guess until then, I'm going for "happier" or shall we say, one quantum "less unhappy" rather than a perfect solution. My long term goal is to see you basking in contentment as you look around and see that everything at Wikipedia is exactly as it should be. Of course, it's a wiki, so it may not stay that way for very long, but still, something to strive for, eh? Mathglot (talk) 01:22, 29 September 2024 (UTC)[reply]

Well, that's the heart of the problem: different people have different ideas regarding what they feel is the best approach, and so are striving for different end targets. isaacl (talk) 02:50, 29 September 2024 (UTC)[reply]

I mean, if someone wants to nuke all talk page banners, .tmbox {display: none !important} will basically do it. Izno (talk) 05:31, 29 September 2024 (UTC)[reply]

A disussion is taking place about whether to add a new value to Ambox param |type= to accommodate violations of wmf terms that do not fall under any of the existing type values. Your feedback would be appreciated at Template talk:Ambox. Thanks, Mathglot (talk) 04:01, 5 December 2024 (UTC)[reply]