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 Special:LintErrors there should be a high priority lint bug which tells me how many pages are impacted by the error
[] Make sure to document the lint rule at https://en.m.wikipedia.org/wiki/Wikipedia:Linter