Help talk:Lint errors/night-mode-unaware-background-color

Is fixing worth it?

Coming from phab:T368673. Regarding Help:Lint_errors/night-mode-unaware-background-color#Why_are_we_fixing_this:

• Sometimes the CSS in WikimediaMessages doesn't work as expected and negatively impacts the page
  • true, but there are way less cases where this happens than where the SiteAdminHelper css just works. These issues can be solved with noinvert class.
• The WikimediaMessages extension uses computationally expensive CSS selectors such as :not and contains (*=).
  • valid disadvantage.
• Since WikimediaMessages needs to apply rules that work on all wikis, some are irrelevant or problematic in certain wikis.
  • can be fixed for the big wikis by having a local stylesheet and not having project specific selectors in the global css. The smaller wikis usually just use enwiki's templates, so they should be fine if the global one is restricted to enwiki's classes.
• The styles in WikimediaMessages are loaded on all pages.
  • Since the dark mode should work on all pages, this seems fine and is not different to other styling such as wikitable, galleries etc.
• Makes debugging issues harder, as editors have to understand where unexpected CSS rules are coming from.
  • valid disadvantage, on the other hand having to specify the front color explicitly makes editing harder and makes it more difficult to have a good looking page in all view modes. Many editors are just not super familiar with css, dont' care about darkmode (like they already don't care about mobile output), forget to add the front color definition, copy or create syntax errors. There are already too much inline styles in page content.
• The fixes only apply when content is consumed on Wikimedia sites.
  • true, but that's the same with wikitables and all other sitewide or projectwide css that is not inline. It seems new to me that reusing the raw html (instead of "just" the content) is a primary goal. The reference to the foundation mission doesn't help much, it's too generic for this special case IMO.

In addition: the standard text color is not unified between skins, so the explicit color:black for dark text on white background doesn't match the current front color of the vector skins and minerva. How should be determined which color to use? What if in a future Vector-2030 skin there is a text color that's different from the color hardcoded in 600.000 pages? hgzh 15:44, 8 July 2024 (UTC)

> What if in a future Vector-2030 skin there is a text color that's different from the color hardcoded in 600.000 pages?

The purpose here is to untie the content from the skin where stylistic choices have been made. Since the table is already setting a background, I don't think that would be a problem? if the background is white and the text is black, that's always going to work no matter what happens to the skin. Already by using colors the content has indicated it is breaking away from the official style guide.

Where content does want to be consistent it should use CSS variables to express color using https://doc.wikimedia.org/codex/latest/design-tokens/overview.html.

Consider a peculiar parallel universe where Wikipedia has green text on a black background by default and a table which has green and red rows to depict a soccer team won or lost. If the text is black and backgrounds green/red that would not be broken. Jon (WMF) (talk) 18:27, 18 July 2024 (UTC)