Page MenuHomePhabricator

Client side SVG rendering that is compatible with prefers-color-scheme ("dark mode")
Open, Needs TriagePublicFeature

Description

Feature summary (what you would like to be able to do and where): SVG files should embedded in output HTML and be rendered client side, this will enable a number of things that the PNG served files prevent. In particular, it will make it so SVG images can automatically adjust depending on the browsing users' light/dark preference.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): Dark mode on Wikipedia currently operates independently of the system-wide setting and doesn't seem to use prefers-color-scheme to detect what mode the user is currently using. If there is a mismatch between the dark mode as currently implemented, and an SVG image is served directly detects the opposite, this can lead to invisible or hard to see images.

Benefits (why should this be implemented?): Makes the entire site work with images that are compatible with prefers-color-scheme, and encourages editors/creators to upload images that utilize this technique to make images dynamically adjust to the system/browser in real-time. Improves readability for users who utilize dark mode, which is also an accessibility concern.

For some example images that utilize prefers-color-scheme see https://en.wikipedia.org/wiki/Category:SVG_images_that_support_dynamic_color_schemes

See also T5593: [Epic] SVG client side rendering T26070: [GOAL] Provide a dark / night mode skin or theme and the Community-Wishlist-Survey-2023 items Dark mode and Native SVG support

Event Timeline

@Izno, with regard to removing Community-Wishlist-Survey-2023, I'd think this would be closely related to Native SVG support and Dark mode, both of which scored highly in the survey.

@Izno, with regard to removing Community-Wishlist-Survey-2023, I'd think this would be closely related to Native SVG support and Dark mode, both of which scored highly in the survey.

This task was not directly a part of the wishlist and would not directly implement the intent of either of those two wishes. So, not appropriate to put it in that project.

TheDJ subscribed.

The dark mode extension is a completely separate extension, not in use on WMF. We currently don't really have a dark mode, which is tracked in T26070.

The dark mode extension is a completely separate extension, not in use on WMF. We currently don't really have a dark mode, which is tracked in T26070.

OK...? So you're saying definitively this change would have no negative impact on the extension?

The extension (!) is not used at all on Wikimedia wikis.

OK, I'm thinking this through a bit....

This is going to be problematic for any dark mode I think. The reason is that at a skin level, we won't know these images will automatically adapt their colors. Images are generally treated separately by dark skins, but these would have to NOT be treated separately (a double exception). Yet they do not self identify at the skin level and there are also 100 000s of SVGs that do NOT feature this and so having the skin treat all SVGs separately also doesn't seem feasible either.

We can add to that that prefers-color-scheme only works for 'automatic dark mode', and not for a site toggle, which generally people seem to like (they like to have automatic / on /off options). And lastly any PNG rendering of it, would require the rasteriser to support prefers-color-scheme and variance on the url for dark / non-dark modes....

The only place where I see this really being functional is in places where they SVG is given directly to the browser. The favicon is a pretty decent example of that, but I believe you can even have media queries for site icons in the <head> these days.

Izno moved this task from Change CSS to Backlog on the CSS board.