Module talk:Message box/Archive 2
| This is an archive of past discussions about Module:Message box. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
| Archive 1 | Archive 2 |
Change background color for .fmbox-warning
This edit request to Module:Message box/fmbox.css has been answered. Set the |answered= parameter to no to reactivate your request. |
Current background color doesn't meet WCAG AA contrast requirements with links color used in Vector-2022, Timeless and Minerva, so I request to change it from #ffdbdb to #ffe6de.
More specifically, edit the 14th line so that
background-color: #ffdbdb; /* Pink */
becomes
background-color: #ffe6de; /* Pink */
. Sapphaline (talk) 18:02, 10 September 2025 (UTC)
- Hmm why not change it to
var(--background-color-destructive-subtle, #ffe6de);? waddie96 ★ (talk) 18:05, 11 September 2025 (UTC)- Then it'll be dynamic, adaptive for CSS themes, and change in dark mode waddie96 ★ (talk) 18:07, 11 September 2025 (UTC)
- Why did the WMF feel the need to mess with link colors again? (Sent from the REAL vector skin) —pythoncoder (talk | contribs) 17:57, 16 September 2025 (UTC)
- Hahaa I +1 this. waddie96 ★ (talk) 18:30, 16 September 2025 (UTC)
Not done for now: This is also the background used for cmbox speedy and delete. I'd be fine making this change for all or none. I also think it's a reasonable question whether to consider the token directly for this case. Izno (talk) 23:37, 30 September 2025 (UTC)
- As for the token, the actual token is #ffe9e5 in use with background-color-error-subtle, which is probably the preferable token to reference rather than destructive-subtle.
- My issue with lightening the color is indeed that the original color is used in the context of at least one deletion mbox, and we want those to be annoying enough to be annoying.
- WCAG 2 AA should be taken a little less interestingly these days with the development of WCAG 3.0 which uses Accessible Perceptual Contrast Algorithm (APCA) to decide whether some content is too much or too little contrast. I expect blue/dark purple on pink to do better with the APCA than it does with WCAG 2 computation. Izno (talk) 03:13, 1 October 2025 (UTC)
- Thanks for the interesting pointer to a new contrast metric! Based on a quick reading of some sites that came up in search, it seems that the WCAG working group is still considering if it will include APCA in the new release of its standards. Nonetheless, it does seem that improved ways of measuring contrast are under consideration. isaacl (talk) 04:55, 1 October 2025 (UTC)
- Yeah, APCA takes into account some of the factors that have been recommended (but rarely considered) for consideration while looking at WCAG 2.0 contrast checking (notably, [relative] font size and boldness), but the contrast checking algo itself has also changed AIUI. Izno (talk) 15:36, 1 October 2025 (UTC)
- My understanding is that APCA tries to adjust the luminance contrast ratio to account for differences in how humans perceive luminance in different colours, as well as which colour is foreground and which is background. The threshold values in WCAG 2.0 were always known to be arbitrarily chosen; there seems to be some concerns that a new replacement in WCAG 3 should have more hard data behind it. isaacl (talk) 21:52, 7 October 2025 (UTC)
- Yeah, APCA takes into account some of the factors that have been recommended (but rarely considered) for consideration while looking at WCAG 2.0 contrast checking (notably, [relative] font size and boldness), but the contrast checking algo itself has also changed AIUI. Izno (talk) 15:36, 1 October 2025 (UTC)
- Thanks for the interesting pointer to a new contrast metric! Based on a quick reading of some sites that came up in search, it seems that the WCAG working group is still considering if it will include APCA in the new release of its standards. Nonetheless, it does seem that improved ways of measuring contrast are under consideration. isaacl (talk) 04:55, 1 October 2025 (UTC)
Warnings for wrong mainspace use or something
Given this comment, I'm entertaining adding a configured warning which would display (and category with it) when a message box is in the mainspace and it shouldn't be. There are some recent changes that I'm going to have to chase down and/or revert to support that. Izno (talk) 21:12, 15 October 2025 (UTC)
fmbox migration
A change is occurring in how {{fmbox}} is implemented. It should help improve display at mobile resolutions now, and accessibility later. fmbox was chosen because it has lower reader-facing impact than most other message box types and it's fairly self-contained. (There is some other planning information in #CSS instead of tables.) (Previously, cmbox was done.)
You can expect some difference in styling from previous for a small period due to the job queue, after which it should return to "normal". You should be able to correct it manually if you want with one of the usual steps (purge, null edit, or dummy edit). If an issue with display persists, leave a comment here (this scenario may be possible with some unexpected setup fmboxes). Izno (talk) 21:19, 15 October 2025 (UTC)
cmbox migration
A change is planned to occur sometime starting in the next day or two in how {{cmbox}} is implemented. It should help improve display at mobile resolutions now, and accessibility later. cmbox was chosen because it has lower reader-facing impact than most other message box types and it's fairly self-contained. The change to cmbox will likely pave the way for other message boxes ({{fmbox}} or {{imbox}} is probably next). (There is some other planning information in #CSS instead of tables.)
You can expect some difference in styling from previous for a small period due to the job queue, after which it should return to "normal". You should be able to correct it manually if you want with one of the usual steps (purge, null edit, or dummy edit). If an issue with display persists, leave a comment here (this scenario may be possible with some unexpected setup cmboxes). Izno (talk) 21:22, 1 October 2025 (UTC)
- Ok, this is now deployed. I await the lions and bears (oh my!). Izno (talk) 20:30, 2 October 2025 (UTC)
- I think this is not working too well with minerva's JavaScript.
- Onhttps://en.m.wikipedia.org/wiki/Trolleybuses_in_Tours#Lines for example learn more link appears before rather than after the text (and is kind of useless since it just repeats the expanded text).
- Page issues on mobile expect a certain markup outlined on Mw.org. Hopefully an easy fix? 🐸 Jdlrobson (talk) 21:31, 3 October 2025 (UTC)
- @Jdlrobson {{cmbox}} is not (supposed to be) used in mainspace (the c stands for category). If there are issues, they are pre-existing there. Izno (talk) 21:51, 3 October 2025 (UTC)
- Ok, this was a mis-translation use of {{images}} from French Wikipedia which is apparently something closer to {{multiple images}} there. IDK how you stumbled onto this use. It's the only use of cmbox in mainspace. Izno (talk) 21:58, 3 October 2025 (UTC)
- Thanks for looking! I just looked at WhatLinksHere and picked the top article. I didn't realize it was the only one! I must confess I didn't look closely at your changes to determine if it was preexisting. 🐸 Jdlrobson (talk) 00:56, 4 October 2025 (UTC)
- Ok, this was a mis-translation use of {{images}} from French Wikipedia which is apparently something closer to {{multiple images}} there. IDK how you stumbled onto this use. It's the only use of cmbox in mainspace. Izno (talk) 21:58, 3 October 2025 (UTC)
- (edit conflict) The change made here is bringing it more into compliance with your mw:Recommendations for mobile friendly articles on Wikimedia wikis#Avoid tables for anything except data. 🙄 Anomie⚔ 21:52, 3 October 2025 (UTC)
- And as for certain markup, {{ambox}} which is supposed to be used in articles already has one task upstream about it. I suppose I'm glad you ran into this because it mostly firms up my feeling that what MF/Minerva/WikimediaMessages does with what it does desperately needs an overhaul even above the task or two out there. Izno (talk) 21:52, 3 October 2025 (UTC)
- And specifically I had noted this issue with ambox though I hadn't yet written it down as being an issue. I'll go do at least that much. Izno (talk) 22:13, 3 October 2025 (UTC)
- Now at Module:Message box/div/doc#Written. Izno (talk) 22:18, 3 October 2025 (UTC)
- @Jdlrobson {{cmbox}} is not (supposed to be) used in mainspace (the c stands for category). If there are issues, they are pre-existing there. Izno (talk) 21:51, 3 October 2025 (UTC)
- I assume "is planned" here means "is planned by you, Izno, who individually decided to fix it" — or is this orchestrated by the ægis of some larger and grander edifice? jp×g🗯️ 11:08, 13 October 2025 (UTC)
- If the former, then thanks: somebody's gotta do it. jp×g🗯️ 11:09, 13 October 2025 (UTC)
- The former. And it's already happened. I was going to do fmbox/imbox at the end of the last week but then time got away from me. Then I took a couple days away. Izno (talk) 16:45, 13 October 2025 (UTC)
- Your nation thanks you for your service. &#xsalute; jp×g🗯️ 00:56, 16 October 2025 (UTC)
- The former. And it's already happened. I was going to do fmbox/imbox at the end of the last week but then time got away from me. Then I took a couple days away. Izno (talk) 16:45, 13 October 2025 (UTC)
- If the former, then thanks: somebody's gotta do it. jp×g🗯️ 11:09, 13 October 2025 (UTC)
- The div version has 4 pixels shorter height than the table version. For example, Template:Maintenance category is 57.8 px high using table, but 53.8 px using div. Snævar (talk) 22:55, 15 October 2025 (UTC)
- Yes, I noticed that too shortly after merging it, it's on account of browser default CSS being
table { border-collapse: separate; border-spacing: 2px }. I came to the conclusion that there's no real reason to be pixel-perfect here—the only reasonable way to emulate it is to add additional padding, which is probably a few more lines of CSS. Izno (talk) 23:02, 15 October 2025 (UTC)- Well, it's not a few more lines, it's a gentle adjustment to what we have (bumping our mbox-image/text paddings by about 0.1em), but we probably still won't end up pixel perfect as that would require the use of
calc()to add em widths and px widths. I have no great qualms adjusting the current CSS to support that if someone else thinks we should. Izno (talk) 04:34, 16 October 2025 (UTC)- Ok I did it anyway. Izno (talk) 01:02, 17 October 2025 (UTC)
- Well, it's not a few more lines, it's a gentle adjustment to what we have (bumping our mbox-image/text paddings by about 0.1em), but we probably still won't end up pixel perfect as that would require the use of
- Yes, I noticed that too shortly after merging it, it's on account of browser default CSS being
imbox migration
A change is occurring in how {{imbox}} is implemented. It should help improve display at mobile resolutions now, and accessibility later. imbox was chosen third because it has lower reader-facing impact than most other message box types and it's fairly self-contained. (There is some other planning information in #CSS instead of tables.) (Previously, cmbox and fmbox were done.)
You can expect some difference in styling from previous for a small period due to the job queue, after which it should return to "normal". You should be able to correct it manually if you want with one of the usual steps (purge, null edit, or dummy edit). If an issue with display persists, leave a comment here (this scenario may be possible with some unexpected setup imboxes). This may also, but should not have, affected the already-migrated cmbox and fmbox, so if those also appear to have an issue, here is a good spot now. Izno (talk) 18:34, 19 October 2025 (UTC)
T367463
Since it's fixed, can the relevant CSS rule be removed? Andyrom75 (talk) 07:07, 19 November 2025 (UTC)
- @Izno, @Jdlrobson, ping. Andyrom75 (talk) 07:08, 19 November 2025 (UTC)
- What do you think is fixed exactly? Izno (talk) 07:14, 19 November 2025 (UTC)
- And what rule do you think should be removed? Izno (talk) 07:19, 19 November 2025 (UTC)
Plural for {{Hooks}}
This edit request has been answered. Set the |answered= parameter to no to reactivate your request. |
Please copy this sandbox version (not the current version, which links to Module:Message box/configuration/sandbox) to live.
Let me know when done, and I'll update the documentation for the module, and make other tweaks.
All the best: Rich Farmbrough 17:12, 16 December 2025 (UTC).
Not done for now: please establish a consensus for this alteration before creating an edit request. Namely, making a change to a template used on 20 million pages because you created a template today? For a wording tweak? Please show a consensus that this is something desirable. Izno (talk) 18:09, 16 December 2025 (UTC)
- Looking at the archive I see you make changes without awaiting consensus. I find this modern gatekeeping behaviour unfortunate. All the best: Rich Farmbrough 02:48, 17 December 2025 (UTC).
- Flinging some incorrect mud (I have been very public about the changes I've implemented of my own resort in this module even if you didn't find where) is not any more likely to convince me or anyone else of the value of this change (see also WP:OTHERSTUFF: your edit request is relevant, not any of my edits).
- I also note that you were apparently able to implement the same display as what you wanted without making the change in this module. Izno (talk) 04:00, 17 December 2025 (UTC)
- And just to be very clear, the two changes at my desire have been the following:
- Supporting TemplateStyles. In this module, that had prior requests at Use TemplateStyles, A question to small param and TemplateStyle, and Site-local configuration.... I had set up MediaWiki talk:Common.css/to do previously with provided description there, and have generally advertised that link every chance I get because I don't like being the only person spending time on making changes more accessible to a wider public (you may check what links here at your leisure), and had also generally mused about the problem much earlier at In the context of meta templates. That culminated, when I finally got around to it, in mbox is now TemplateStyled only and associated target link. For which there have been no complaints not trivially remedied.
- Changing the table structure to divs. That change is right there and was also implicated in Aria roles and separately reinforced in the individual advertisements I've so far made, like cmbox migration. The cmbox migration section was incidentally also advertised to VPT.
- Any other changes that I made were implemented due to requested edit. Izno (talk) 04:21, 17 December 2025 (UTC)
- I don't mind that you made intelligent changes to the module, saying "Ok I did it anyway" - in fact I absolutely support them. Even if I would have disagreed with them.
- And yes, I coded around the obstacle by using an older method which I had previously used in
{{Hook}}(which I created). People have "updated" that, I do them the courtesy of assuming that their updates add value, unless I know otherwise. - If someone wants to update
{{Hooks}}in the same way that{{Hook}}was updated, they will have to, apparently, gain consensus. I won't. - If I see a problem on Wikipedia I like to fix it. If something stops me doing it one way, I'll usually try another.
- Hope that is all clear, and that you agree with my sentiments.
- All the best: Rich Farmbrough 13:47, 17 December 2025 (UTC).
- And just to be very clear, the two changes at my desire have been the following:
- Looking at the archive I see you make changes without awaiting consensus. I find this modern gatekeeping behaviour unfortunate. All the best: Rich Farmbrough 02:48, 17 December 2025 (UTC).
Module:Message box/ombox.css needs a couple of color: additions
Module:Message box/ombox.css has three background-color: statements without a corresponding color: statement. This can make the Linter complain and might cause problems in dark mode. If someone could add color: statements after lines 19, 98, and 104, that would probably help. color:var(--color-base, #202122); is usually safest when the color has been assumed to be black in the regular mode but should be near-white in dark mode. – Jonesey95 (talk) 17:56, 16 February 2026 (UTC)
- The same situation appears to apply to Module:Message box/ambox.css, Module:Message box/cmbox.css, Module:Message box/fmbox.css, Module:Message box/imbox.css, and Module:Message box/tmbox.css. – Jonesey95 (talk) 18:03, 16 February 2026 (UTC)
- Three message box templates are showing up in the top 25 templates on this new report of the most transclusions with dark mode errors. – Jonesey95 (talk) 05:11, 17 March 2026 (UTC)