We need to be able to detect known issues with night mode relating to inline styles/Templates that introduce background colors without text colors. While we will be able to automatically fix some of these issues ourselves, we still need a long term solution to make this sustainable. This will also help us have more confident in roll out as we'll have a good idea of how many pages are impacted.

Parsoid runs on all mobile views, but is not guaranteed to be triggered by edits or by desktop views. You'd probably be looking at a DOM Postprocessing pass either inside Parsoid directly or registered as an extension, and it would then register any lints found via Parsoid's SiteConfig.

Developer notes

Develop and integrate a linting rule within the Wikimedia editing environment to detect and flag instances where template styles specify a background color without an appropriate text color for night mode. This task involves creating the linting rule, testing it with a variety of templates, and providing documentation for editors on how to resolve flagged issues.

• Recommended to use the core linter

There are two possible mechanisms (and two hooks):

• One is the ParserAfterTidy hook, which is invoked by the legacy parser. It is not invoked by Parsoid, but the legacy parser is used post-edit and on almost all page views. This hook occur before caching and before the links update jobs, so it's an excellent place to add a tracking category (git grep nonnumeric-formatnum includes/ in core for an idea how this works). Editors use the category lists on-wiki to chase down and fix errors. Because this hook is (a) not invoked by Parsoid, and (b) affects pre-cache content, it's not a great place to make changes to the HTML output, but it's a fine place to tweak metadata like categories. The full HTML for the article, including styles added by TemplateStyles, should be available here, and attributes are guaranteed to be double-quoted and so a quick-and-dirty regexp like \bstyle="([^"]*(background-?)color)[^"]*" might be enough to pull up the lion's share of the problematic uses.
• The other path is to use Parsoid and the Linter extension. Parsoid runs on all mobile views, but is not guaranteed to be triggered by edits or by desktop views. You'd probably be looking at a DOM Postprocessing pass either inside Parsoid directly or registered as an extension, and it would then register any lints found via Parsoid's SiteConfig.

Acceptance criteria

• When I go to https://en.wikipedia.org/wiki/Special:LintErrors/night-mode-unaware-background-color there should be a list of pages impacted by the lint.
• Make sure to document the lint rule at https://en.m.wikipedia.org/wiki/Wikipedia:Linter
• Make sure the documentation is linked to Special:LintErrors page

---

Product-Specific Decision Making Documentation

Problem Statement:

The linting process needs to address inline style background colors that lack a corresponding color style rule. These issues are particularly prevalent when analyzing color contrast problems in night mode.

More detailed information about this issue can be found here.

Priority:

The linting priority for this issue is set to "none," which allows it to be suppressed on the special page. However, it's important to note that editors using Quarry will still have visibility of these flagged items.

Deployment Strategy:

The deployment strategy involves initially setting the priority to "none" and subsequently escalating it to "high" as necessary.

Linting Logic:

We're identifying all instances of background colors without corresponding color inline styles.

Handling False Positives:

While false positives are expected, particularly within the Wikipedia context, they are anticipated not to outweigh the volume of legitimate issues that need to be addressed. We will adjust the linter based on patterns observed with false positives, relying on bulk data to inform these adjustments.

Transition to Higher Priority:

The priority for addressing this linting issue will transition from "none" to a higher priority level approximately two weeks after deployment of this ticket, contingent upon a majority of flagged errors being deemed valid.