Template talk:Yes

RfC on the colour of Template:No (more options)

what colour should be used for Template:No? Gooduserdude (talk) 16:35, 20 February 2022 (UTC)

Description	Web color	Examples of use		WCAG level of contrast with blue links
Old color of {{no}}	#F99	Regular text	Unvisited link to article	4.17 (not compliant)
The darkest shade of red reaching WCAG AA	#FFA4A4	Regular text	Unvisited link to article	4.5 (AA)
Color User:Ftrebien proposed for {{no}}	#FAA	Regular text	Unvisited link to article	4.7 (AA)
Color the chosen for {{no}} after former discussion	#FFC7C7	Regular text	Unvisited link to article	5.78 (AA)
Color of {{no2}}	#FFE3E3	Regular text	Unvisited link to article	7.04 (AAA)

Survey

• #F99, Clearer Gooduserdude (talk) 16:35, 20 February 2022 (UTC)
• #FAA - not too light, but meets the WCAG AA standard. Remagoxer ^(talk) 17:54, 20 February 2022 (UTC)
• #FAA Just based on personal preference. #F99 is too dark. Some1 (talk) 19:16, 20 February 2022 (UTC)
• #FAA and #FFC7C7 are fine with me. #FAA is closer to the original color and more distinct from #FFE3E3, while #FFC7C7 is more accessible (closer to WCAG AAA) without being completely indistinguishable from #FFE3E3. #FAA and #FFA4A4 are practically indistinguishable, so I see no reason not to prefer a shorthand hexadecimal option which even slightly improves contrast. --Fernando Trebien (talk) 19:54, 20 February 2022 (UTC)
• FAAor lighter. North8000 (talk) 23:20, 20 February 2022 (UTC)
• #FAA solves the contrast issue and is not too light. Pikavoom ^Talk 07:39, 21 February 2022 (UTC)
• #FFC7C7 is better. There is little difference between #F99 and #FAA, with the latter being just a few decimal places above the first. Longer templates like {{eliminated}} or {{active fire}} which share the same color, as well as {{no}} tags with customized text, will greatly benefit from the improved readability of the less saturated background (compare examples with longer text below): Diego (talk) 17:12, 21 February 2022 (UTC)

This is a longer example of text	and links with darker, low-contrast background
This is a longer example of text	and links with lighter, higher-contrast background

• #FAA is not too light but not too dark. Thingofme (talk) 15:08, 23 February 2022 (UTC)
• #ffc7c7 In addition to better contrast than the currently favored #ffaaaa, it looks more aesthetically appealing, too. –LaundryPizza03 (dc̄) 00:38, 24 February 2022 (UTC)

  Nah, I changed my mind; #ffaaaa is easier to distinguish from {{no2}}. –LaundryPizza03 (dc̄) 01:51, 24 February 2022 (UTC)

References

Converting to templatestyles

I've created Template:Yes/sandbox/styles.css which has all the colours required. I've tested this at User:Matrix/sandbox. Should we convert these template to templatestyles for dark mode compatibility? Thoughts? —Matrix(!) _{ping one}^{when replying} {u - t? - _uselessc} 10:45, 25 October 2024 (UTC)

If there is any way that this family of templates could share some or all of their template styles, so that we didn't need to edit 100 templates when another MediaWiki change comes along, that would be great. If not, I still support this update. – Jonesey95 (talk) 14:49, 25 October 2024 (UTC)

Note that according to mw:Recommendations for night mode compatibility on Wikimedia wikis § Target night mode using standard media query as well as HTML classes, the dark mode rules have to be replicated to handle the case where the user has chosen to follow the OS setting. isaacl (talk) 23:24, 15 January 2025 (UTC)

Prompted by a VPT discussion, I put the templatestyles into the table cell, where it can be normal wikitext, instead of having it interpreted as table markup. Does it work? See the testcases page. – Jonesey95 (talk) 14:54, 17 January 2025 (UTC)

Jonesey95, looks good to me. — Qwerfjkltalk 21:34, 30 November 2025 (UTC)

Usage for merged cells

How can I use this template in merged cells? Quang, Bùi Huy (talk) 18:56, 20 December 2024 (UTC)

Colour change

I see HouseBlaster has boldly changed the colour shade of this and the No templates to "make compatible with dark mode". However, I should note that this does not seem to have been discussed or agreed anywhere, despite these templates being widely used in many articles (meaning the change has a wide impact). I would say that these changes should be reverted and discussed first, to see whether a consensus for these exists. Impru20^talk 13:31, 11 July 2026 (UTC)

Do you have a substantive objection or just a procedural one? I believe that better serving readers who chose to use a built-in MediaWiki feature is uncontroversial. Best, HouseBlaster (talk • he/they) 15:52, 11 July 2026 (UTC)

One of my substantive objections is that you just unilaterally overrode a discussion above that did not agree to one of the changes you have conducted. Is consensus "procedural" to you? The implemented changes have a wide impact across Wikipedia, so that should be enough for you to, at least, consider that unilateral action is not the best course of action. If you mind having a discussion on that, maybe we can all voice our substantive opinions on it. Impru20^talk 16:08, 11 July 2026 (UTC)

Consensus is procedural, yes. See Wikipedia:Don't revert due solely to "no consensus". That discussion was before the introduction of dark mode and the WMF decided that only certain colors are compatible with dark mode. By substantive I mean, do you dislike the color for some reason? I am happy to have a full discussion on which color is best, but I would hope that putting readers first is more important than anything else. I hope you can agree that using the old colors with dark mode is a serious problem. Best, HouseBlaster (talk • he/they) 16:22, 11 July 2026 (UTC)

The point is: there is a very visible notice at the top of this talk page stating that Substantial changes should first be proposed and discussed here on this page. I would have reverted you under WP:BRD because I am contesting your edit, which constitutes an undiscussed substantial change, and that would have been a normal course of action. But I cannot revert you because the template is fully protected. I see that you are taking this to your advantage to refuse to revert yourself even in spite of knowing that your edit is contested, by arguing than this is somehow "procedural". I have voiced my concerns to you on your unilateral action, the impact of your edit, a previous RfC above that did not go the way you are defending right here (and that you unilaterally overlooked), and the fact that this is not (nor was apparently so) an uncontroversial edit. Yet, you keep ignoring it (and no, do not say "I hope you can agree with me" because I am visibly not agreeing with you). I am more than happy to have a full RfC on the issue if required so that others (as well as you and myself) can present our arguments for or against the change, but I do not think the correct course of action is going "hey my edit is fully correct and you must get along with it". Best. Impru20^talk 16:49, 11 July 2026 (UTC)

Given you disagree that using the old colors with dark mode is a serious problem I will revert the changes. I was trying to ascertain whether you were merely objecting to the fact I did not seek consensus before making an edit. Now that you've clarified what you mean, let's workshop an RfC—do you have options other than the status quo you believe should be considered? Best, HouseBlaster (talk • he/they) 17:02, 11 July 2026 (UTC)

Note that what you say I am saying is not what I am saying. I disagree with your course of action as a whole. The Substantial changes should first be proposed and discussed here on this page notice should have been clear enough for you from the start; I thank you for agreeing to revert to the status quo version and workshop an RfC.

On the available options, and since you seem concerned with dark mode: there is some intermediate option that can work both with dark and light mode without deviating too much from the current shade? Maybe that could be thrown for discussion as well. Impru20^talk 17:50, 11 July 2026 (UTC)

There's a couple of intermediate options we can do. One, for technical reasons, we can set the color for skins other than Minerva (the default mobile skin) and Vector 2022 (the default desktop skin) to whatever we fancy, including the status quo color. Two, we can pick any color we want from the list of dark mode compatible colors, but there are not that many shades of green to chose from. There's  "lime" ,  "green" , and a handful of non-contenders because they fail MOS:CONTRAST. (For {{no}}, there are a lot of red choices.) Do any of those seem more amenable to you? Best, HouseBlaster (talk • he/they) 18:25, 11 July 2026 (UTC)

This discussion, and a recent change to the sandbox, appears to be ignoring the work that went into the templatestyles sandbox. See #Converting to templatestyles above, and Template:Yes/sandbox/styles.css. Ideally, one templatestyles page could be used to fix multiple table cell templates, centralizing the color declarations in one place. – Jonesey95 (talk) 18:53, 11 July 2026 (UTC)

I think we can take the opportunity to complete the TemplateStyles implementation while making the templates work in dark mode. Best, HouseBlaster (talk • he/they) 20:24, 11 July 2026 (UTC)

I agree that it's desirable to make the colours adapt for dark mode within a stylesheet (via the template styles mechanism), and that the easiest approach is to use one the colours defined by the CSS variables set by the base software, so ongoing support of choosing and selecting the colour based on viewing mode is handled by the MediaWiki devs without cost to the community. I think  background-color-success-subtle  and  background-color-error-subtle  would be suitable choices, given the purpose for those colours. isaacl (talk) 18:16, 12 July 2026 (UTC)

One note on using a stylesheet: I think that to follow Template:Yes/doc § Color subpage, the colour definition will have to be duplicated as I don't think MediaWiki pages with its sanitized CSS content model can transclude wiki pages. (Should one day MediaWiki allow CSS variables to be declared within sanitized CSS, then in theory English Wikipedia could transition away from the bgcolor subpage model to one based on CSS variables. But it would mean changing every place that hardcodes a custom style attribute using the bgcolor subpage for its value to use a stylesheet instead.) isaacl (talk) 18:34, 12 July 2026 (UTC)

@Impru20: Do you have thoughts on the above? Best, HouseBlaster (talk • he/they) 17:48, 16 July 2026 (UTC)

Am I understand you correctly that currently it's technically impossible to have a centralized stylesheet in Template:Table cell_templates/style.css and each individual cell template using colors from it via var(--background-color-template-rh/yes/no/etc...)? IamNikita (talk) 19:40, 17 July 2026 (UTC)

That is my understanding. See Phabricator ticket T320322 that tracks the request to allow CSS variables to be defined in style sheets being used via the TemplateStyles mechanism. (I think I went down the wrong path regarding the sanitized CSS content model; you can define CSS variables in your own personal style sheets.) isaacl (talk) 02:12, 18 July 2026 (UTC)

These /bgcolor subpages are not being really used, there are 72 uses total and half of them are in users namespace. And only 6 templates even have /bgcolor subpages. Maybe just get rid of them all? IamNikita (talk) 01:25, 20 July 2026 (UTC)

Another possibility is to add a named parameter such as |bgcoloronly=any value that would trigger the template to only return the background colour. isaacl (talk) 18:32, 22 July 2026 (UTC)