Perhaps it would be an idea to stipulate what is so hard about it? Many github issues and pull requests are much more transparent than this âcommunityâ forum. There have already been several suggestions in this thread. Youâll have to lay out why itâs difficult otherwise this is all not understandable to us as developers.
Check e.g. https://github.com/crownstone and https://github.com/crownstone/bluenet in gray mode.
interesting, why it is sanitized, is it may include some security problems?
For me this option should just work, it is a native html, why it is not supported?
What does this have to do with the topic?
Whatâs the status on this? Itâs been almost a year.
This is just sad⊠
This is by far the most viewed unsolved issue in this category, and one of the most viewed this year in general. Like, across the whole forum.
The apparently âblockingâ feature, colorblind themes, is out since September 30th. Any update would be nice. A thumbs up, an emoji, anything. Because currently it feels like this thread is shadowbanned at GitHub HQâŠ
EDIT: Just wanted to emphasize again: The main problem isnât theme context not being here. Itâs the careless introduction and release of the dark mode. If theme context really takes this long to implement, why did you even release dark mode, while knowingly breaking a lot of readmes? You admitted this is an issue with your own repos. Itâs this carelessness and apparent arrogance, that I thought only big gaming companies can have. Stop releasing stuff in an unfinished state, I donât care what your product owners or investors say.
Making a bunch of content unreadable for an estimated 80% of users is NOT âinclusiveâ or âaccesibleâ. And I know people can toggle dark mode off and on every time they encounter such a readme, but how many will? And how many will just not check out projects because their readmes are currently not maintained and look broken? How many hours do you want open-source devs to focus on creating theme-neutral images for every little repo?
At least just add a css rule to add a white background for every transparent image, then Iâll shut up. But sorry, the current state of this is unacceptable.
Hi everyone 
You can now specify the theme an image is displayed for in Markdown. Appending #gh-dark-mode-only or #gh-light-mode-only to the end of an image url will define whether itâs only shown to viewers using a light or a dark GitHub theme.
Example:
For more information please have a look at the docs
@dipree Thank you !
This even work with img elements, which is very useful for SVG (to resize larger images).
@dipree It does not seem to work on the Markdown pages part of a Wiki. Is that correct?
It shows the two pictures side-by-side.
In case this is helpful to others: You can use the #gh-dark-mode-only:target pseudo-class to style a single SVG differently in light and dark modes, e.g. [README] Change diagram color in dark mode by jablko · Pull Request #57360 · DefinitelyTyped/DefinitelyTyped · GitHub
I hope this will be supported as well soon, having this feature in the wiki area is the most important use case for me.
Hi,
Themed image work perfectly now in my README (https://github.com/Orange-OpenSource/hurl), but it the latest GitHub native iOS app (1.41.0), it shows light and dark pictures side-by-side:
Hey @dipree thanks for this!
It doesnât work when trying to link the image. Neither:
[](https://link.example.uk)
or
<a href="https://link.example.uk">
<img src="image.png#gh-light-mode-only" />
<img src="image.png#gh-dark-mode-only" />
</a>
Works - in fact placing the image in any container causes the issue. So no wrapping in <p align="center"> or similar. Itâd be wonderful if this could be tweaked to allow linking images again whilst still getting the benefit of the light/dark mode image switching. Both images are displayed - even if they are individually nested in their own <a> elements.
Fantastic effort though - really nice despite this limitation.
Although not mentioned in the official documentation, the (light|dark)-mode-only selectors appear to be based on the href suffix.
So I was just appending the hashtags to a[href] instead of img[src] and it seems to work:
Edit: Since itâs not documented, Iâm not sure if it would work in apps or if the implementation would change in the future.
Good catch. I noticed this too when I was trying to figure out how to get it to work with linked images (HTML, not Markdown, and also within a centered p tag like you have), but decided against using it for the reason you stated: since itâs not documented, I worry it may not be intentional (may be a bug) and may be removed at some point and I wonât notice until much later.
Would be nice to hear from GitHub as to whether this is intended or not.
Fixed in the updated iOS version (1.42.0)!
Thatâs really cool
How is this GitHub-proprietary, non-standard approach supposed to work with other markdown renderers of the same content? Every other renderer will render two images. Why was this feature not implemented in terms of the standard?
In other words, why not enable this?
<picture>
<source srcset="âŠ_dark.png" media="(prefers-color-scheme: dark)">
</picture>
This is a work-around that should not be needed:
<picture>
<source srcset="âŠ_dark.png" media="(prefers-color-scheme: dark)">
<img alt="ALT_TXT" src="âŠ_light.png#gh-light-mode-only">
<span style="display: none"><img alt="ALT_TXT" src="âŠ_dark.png#gh-dark-mode-only"></span>
</picture>
Hi, a quick status update from our end. We are currently still investigating how to best solve the existing issues.
@posita unfortunately there is no standard. The problem has multiple aspects and there is not a single solution that doesnât come with a downside right now. Media features has been created with the assumption that a client or an operating system has some color scheme setting that specifies what the user wants. For the case of GitHub, the main problem is, that a website cannot intervene. So, the <picture> element is a somewhat flawed concept that only works for the content of a single website. And prefers-color-scheme only serves the right image if the website is in sync with the system (which is not the case for a lot of GitHub users). Another problem is that if, for instance a README, is rendered on a different service, that service is required to have a dark mode. Otherwise users with the system setting set to dark mode would get served the dark mode optimized image on a light mode website. That said, please bear with us, we are still investigating whatâs the best way to tackle the known issues.
VS Code will support the new syntax FWIW
I think there might be an interaction between prefers-color-scheme and color-scheme property that might help with this?
is this expected to work in comments?
attempting to use it there to no avail