Support theme context for images in light vs dark mode

Hii,
I found a trick online to render math equations on github README page using Latex syntax. Something like this: img src=“https://render.githubusercontent.com/render/math?math=(P_{t+2} - P_{t+1})/P_{t+1}”

The rendered equations doesn’t render according to the mode. In the dark mode, it is still rendered in black.

2 Likes

Thanks for sharing this example @pia-nyk! We have been getting a lot of community requests/feedback to support theme context for images in light vs dark modes. I’m going to merge this topic with that one so that we can keep all related requests in one place. Is the README example you shared above by chance in a public repo? If so can you share a link? :pray:

Black elements are almost invisible on transparent images. For example page of cert-manager.

3 Likes

@levonet thanks for sharing the feedback on black images/elements not being very visible in dark mode! We have a related topic on supporting theme context for images in light vs dark mode. I’m going to merge your comment with that topic to keep in one place

Well, when will there be a concrete timeline for this issue? I think it’s pretty huge, considering the whole feature is basically unusable regarding markdown stuff. Sure, some pages are not dark-mode-ified yet and profile pictures get a white background, but breaking like 35% of all readmes on GitHub dark mode isn’t a “beta oopsie”.

There’s literally no sane workaround for this as well, so making this a top priority would be really nice.

3 Likes

Btw, I would suggest two features: Inline and block theme context handling. Like the different comment types in javascript work.

Block level theme context handling allows for more complicated stuff and would look like:

    # Logo:
    <!-- [if darkmode]>
        ![a bright image](./brightlogo.png)
        You are in dark mode
    <![endif]-->
    <!-- [if !darkmode]>
        ![a dark image](./darklogo.png)
        You are not in dark mode
    <![endif]-->

We could also use markdown reference links that are never referenced, like here:

    [//]: # darkmode
        ![a bright image](./brightlogo.png)
        You are in dark mode
    [//]: # end darkmode
    
    [//]: # !darkmode
        ![a dark image](./darklogo.png)
        You are not in dark mode
    [//]: # end !darkmode

GitHub Markdown would be fine with both styles, the second one is better though, because it doesn’t output actual comments in the resulting html.

2 Likes

Hi @nnmrts thanks for taking the time to share your feedback and implementation suggestions! We agree this is an important issue - I can’t tell you how many internal repos I’m in that have a transparent png black GitHub logo that completely disappears in dark mode. I don’t have a concrete timeline for you on when we’ll ship support for this, but I am hosting a workshop with the team tomorrow focused completely on this topic.

1 Like

I have transparent svgs, instead of changing my svgs to have white backgrounds, should this be possible to handle in the markdown itself?

GitHub Flavored Markdown Spec doesn’t seem to have a way to handle this at the moment unless you want to change all your images to html.

Might be cool to have a “default image background” setting on your repo for older repos that don’t look good in dark mode where people don’t have time to modify their images to look good in dark mode.

I think this might be my solution for now:

find . -name '*.svg' -exec sed -i'' '0,/style="width/s//style="background-color:white;width/' {} \;

Hi @BlackthornYugen - thanks for reaching out! I’m going to merge this with a similar topic related to supporting theme context for images in light vs dark mode. This has been a huge point of feedback since our beta launch and is something our team will start investigating potential solutions for this week. Its super helpful to have additional use cases - like svgs in old repos - for our internal exploration! :pray:

Thanks for the update. GitHub is (yet again) one of the few companies actually listening and responding, so please excuse my slight grumpiness in the beginning, as this is unfortunately not something I am used to when it comes to other services and their issues.

Looking forward to whatever your team comes up with to fix this.

Oh, and one more suggestion for just images. A lot of suggestions (as well as the ones I made) assume you changing the actual md file. GitHub could implement something that doesn’t need you to change your markdown, but to add alternative image files. For example, a current markdown file could look like this:

![](./media/logo.png)

Let’s suppose the directory “media” currently only has the file “logo.png” in it, which is black and looks bad in dark mode. Without changing the original markdown file, you could then add the file “logo-light.png” to that same directory. GitHub could then, with CSS or even just with altering the md-to-html conversion, display that alternate light logo image in dark mode if and only if it’s in that same directory. If there’s no alternate image, then don’t change anything.

Some research:

4 Likes

@gaknoll Any updates

2 Likes

@gaknoll is there any timeline for this feature?

1 Like

I should definitely stop coming here everytime I look at my ugly readme logo with a white background, it’s always a disappointment. :smiley:

2 Likes

How did the workshop go?

What is the status on this? Breaking 90% of READMEs seems pretty careless and not having this as a top priority already all the way back in December is astonishing.

6 Likes

Yep, I just read all the comments but still no fix. We definitely need some solution for this issue.

3 Likes

breaking 90% of readmes

wut? @tskj - i dont think that number is even remotely accurate - how many readmes are on GitHub.com?

I looked at 10 readmes today on GH and didnt have a problem with any of them. Maybe I’m special (I am a special kind of idiot), but I think in this case its because I didn’t opt into a beta feature.

If it is not working for you and breaking so much productivity, rather than continue feeling that pain I’d suggest that you opt out of the beta immediately and open a bug for the problem.

4 Likes

Normally I would agree but as a maintainer you want your readme to be readable for everyone (or at least the most amount of people possible). In general, your project should be acessible and endure a wide range of system configurations, environments and opinions.

For example, I personally don’t understand why people use yarn or a four years old node.js version or Angular, and we could argue about it for hours, but instead I’ll just make sure these people can use my project as it is, no matter how dumb their configuration/opinion is in my mind. Ideally. These are popular and established, it would just be stupid to make my project somehow “incompatible” with them, if I want people to interact with it.

Sure, I can turn off dark mode but I’m not writing my readmes for myself, but for everyone else, of which apparently a lot enabled dark mode already.

1 Like