Module talk:Message box

Protected edit request on 25 June 2024

Change fmbox-warning background-color to #300 in night mode for consistency with other mboxes.

Diff:

−

html.skin-theme-clientpref-night .fmbox-warning { background-color: #683131; /* Reddish, same hue/saturation as light */ } @media (prefers-color-scheme: dark) { html.skin-theme-clientpref-os .fmbox-warning { background-color: #683131; /* Reddish, same hue/saturation as light */ } }

+

html.skin-theme-clientpref-night .fmbox-warning { background-color: #300; /* Reddish, same hue/saturation as light */ } @media (prefers-color-scheme: dark) { html.skin-theme-clientpref-os .fmbox-warning { background-color: #300; /* Reddish, same hue/saturation as light */ } }

Andumé (talk) 04:52, 25 June 2024 (UTC)

No opinion on the change request, but presumably if you want to change the bg color, then you'd want to change the comment to match? Mathglot (talk) 18:09, 25 June 2024 (UTC)

That would probably be a good idea, although those comments are often inaccurate anyway, especially on Module:Message box/cmbox.css. Andumé (talk) 21:30, 25 June 2024 (UTC)

Shouldn't be inaccurate? The only one I can think of is the blue of one of the specific cmboxes. IznoPublic (talk) 06:48, 8 July 2024 (UTC)

@Izno: The specific inaccuracy I was thinking of was the cmbox.css's night mode styles refer to #300   as "pink", although that is not the only one. Andumé (talk) 20:29, 14 July 2024 (UTC)

And in fact cmbox makes no claim about similar hue/saturation that I can see?? Please ensure you're being factual. IznoPublic (talk) 06:50, 8 July 2024 (UTC)

The light colors are also not consistent IIRC? Which specific other dark box are you trying to make this consistent with and what is the light color for that box? IznoPublic (talk) 06:48, 8 July 2024 (UTC)

What I meant with "consistency" was that cmbox's night mode styles (cmbox being the only standard mbox to use colorful backgrounds afaik), for colored backgrounds, use the same background color as the light mode styles, except with a lightness of 10. Also, cmbox-delete and cmbox-speedy both have the same background in light mode as fmbox-warning, and they use #300 as background-color in night mode. I hope this makes sense. Andumé (talk) 20:41, 14 July 2024 (UTC)

Please don't reactivate the edit request while discussion is ongoing. I'll review this later. Izno (talk) 23:27, 14 July 2024 (UTC)

 Done After looking at this and consistency among other templates, 300 is as fine as anything. Probably it would make sense to regularize the cmbox deletion colors and the fmbox warning color to match the deletion colors for all other templates in both light and dark mode, which is currently at fee7e6 for the speedy background and 310402 speedy dark background. And to reconsider that cmbox has colored backgrounds. Izno (talk) 21:58, 3 August 2024 (UTC)

Urgent: Please fix this template for printed content Module:Message box/ombox.css.

Firstly, apologies for writing in English if this is not your first language (this is an automated message).

This template has been detected as one of 436 pages using styles that break the page when printed when the user is using dark mode. The fix is very straightforward - all your styles relating to dark mode must be scoped to. Since there is a high risk of this templates being copied to other wikis it is important this notice is acted on ASAP.

To fix this:

1. Update `@media (prefers-color-scheme: dark` to `@media screen and (prefers-color-scheme: dark`
2. Wrap any styles relating to `html.skin-theme-clientpref-night` in `@media screen`

If this message has not been acted on in 7 days, this will be fixed by an automated script. Thank you for your help fixing this important issue.

For any questions feel free to ask them at phab:T369874.

Jon (WMF) (talk) 18:22, 2 August 2024 (UTC) on behalf of the web team.

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

Protected edit request on 13 September 2024

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)

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

Please add param class

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)

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

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)

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)

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)

 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)

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)

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)

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)

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)

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)

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)