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.
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.
You can now specify the theme an image is displayed for in Markdown. Appending
#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.
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.
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:
Thanks a lot for this feature, I hope it will soon work flawless everywhere!
Hey @dipree thanks for this!
It doesn’t work when trying to link the image. Neither:
<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
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
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)"> ![ALT_TXT](…_light.png) </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
color-scheme property that might help with this?
is this expected to work in comments?
attempting to use it there to no avail