I've been informed that on my website, my logo doesn't render correctly on Safari and it always renders as black regardless of the color scheme. This is not what it's supposed to do; it should be black when the color scheme is light and white when the color scheme is dark. It does this through a prefers-color-scheme media query in the style element of the SVG and it works in Firefox.

I wasn't sure how to fix this issue since I don't have a MacOS device, but another user mentioned that this issue is also present on Gnome Web. So, I've been using Gnome Web to test the fix for this bug.

Determining the issue

Safari and Gnome Web both use WebKit, so I searched for relevant issues and found WebKit bug 199134 "SVG images don't support prefers-color-scheme adjustments when embedded in a page", which was reported in 2019 and is still open. This is probably why the SVG doesn't render correctly, because the SVG is embedded into the HTML document.

Looking into the comments on the bug I discovered that, apparently, the CSS Working Group agreed that this should work:

The CSS Working Group just discussed [css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent?, and agreed to the following:

• RESOLVED: Have prefered-color-scheme reflect 'color-scheme' on the embedding element in the embedding document, to the extent acceptable from security standpoint (pending security review)

So it sounds like a WebKit bug, but I'm not sure. I also notice a linked PR mdn/content#19449. I'm aware that MDN is run by Mozilla and I would think that they would have good information on web standards, so I check it out. The PR states:

The change is that prefers-color-scheme in SVG files and iframes will now respect the the color-scheme of the embedder.

And indeed, in MDN's documentation on prefers-color-scheme, I can see that it's marked as working for SVGs:

The prefers-color-scheme CSS media feature is used to detect if a user has requested light or dark color themes. A user indicates their preference through an operating system setting (e.g., light or dark mode) or a user agent setting.

[...]

SVGs must be used embedded (i.e., <img src="circle.svg" alt="circle" />) as opposed to inlined in HTML. An example of using prefers-color-scheme in SVGs can be found in the "Inherited color scheme in embedded elements" section.

But when you check the "Inherited color scheme in embedded elements" section, their own example of this is broken in Gnome Web.

So, despite the fact that the CSS Working Group and MDN say it should be working, I think I can say that this is definitely a bug in WebKit. Given that the bug was reported in 2019, I think I'm just going to have to cope by finding a workaround.

Finding a workaround

I do some basic searches to see if anyone else has encountered this issue, and found this blog post written by Cassidy James:

Inline SVGs can inherit styles like any other element, so I always recommend specifying both color and fill anywhere you want to set the foreground color on your site, so your icons pick up the text color automatically.

It doesn't mention anything about the bug, but I notice that their examples work in both Firefox and Gnome Web. The SVGs have the correct color! So, it looks like inlining the SVG is the right way to solve this problem, though this does not support alternative text.

When an SVG is included via an <img> element, the alt attribute provides alternative text making the image accessible. Inline SVG does not support the alt attribute. But it does support several other ways of making it accessible. With inline SVGs, the source is available in the DOM, meaning all the markup within an inline SVG file is accessible to the Accessibility Object Model, or AOM. Including the <title> element provides that alternative text.

So, I've updated my website to inline the SVG instead. I've also updated the SVG to have the title element to maintain accessibility.

I know MDN says that it must be used embedded in order for prefers-color-scheme to work, but it seems to work anyway on Firefox and Gnome Web, so I guess it's fine. I've exhausted my energy for looking into this problem, so I don't think I'll investigate why it works anyway for now.