-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dark logos on dark backgrounds: Provide light version #1535
Comments
It may not be necessary to have separate light/dark versions ie, the github.svg contains <path fill="#333333" d=".... /> logoFillColor could specify "#FFF" to replace #333333 |
@bkdotcom |
I looked at some of the svgs more closely after my comment... I'm wondering if we give the "primary" fill a class of "color"... and any additional fills "colorB", "colorC", etc edit:: github only allows two colors. should we allow someone to specify |
If you download the GitHub logos they do provide a light and a dark version. |
I think allowing arbitrary colors is a step too far. Explicitly providing a dark and light version (where applicable) fixes the issue and is consistent with upstream specs. |
For the API, my first thought is that if we have light and dark logos, we should detect which one to use in code so it just happens automagically and the user doesn't need to specify. Even if that needs to be tuned in code, that seems like a pleasant way to go about this. If that doesn't work well enough, let's add a separate query parameter e.g. That should be a little cleaner overall than the simpler thing, |
We could also do something like (based on current templates for styles): <svg xmlns="http://www.w3.org/2000/svg" width="40" height="40" viewBox="12 12 40 40">
{{ supportedColors = { 'grey': '333333', 'white': 'FFFFFF' }; }}
{{ logoColor = supportedColors[logoColor in supportedColors ? logoColor : 'grey']; }}
<path fill="#{{logoColor}}" d="M32,13.4c-10.5,0-19,8.5-19,19c0,8.4,5.5,15.5,13,18c1,0.2,1.3-0.4,1.3-0.9c0-0.5,0-1.7,0-3.2 c-5.3,1.1-6.4-2.6-6.4-2.6C20,41.6,18.8,41,18.8,41c-1.7-1.2,0.1-1.1,0.1-1.1c1.9,0.1,2.9,2,2.9,2c1.7,2.9,4.5,2.1,5.5,1.6 c0.2-1.2,0.7-2.1,1.2-2.6c-4.2-0.5-8.7-2.1-8.7-9.4c0-2.1,0.7-3.7,2-5.1c-0.2-0.5-0.8-2.4,0.2-5c0,0,1.6-0.5,5.2,2 c1.5-0.4,3.1-0.7,4.8-0.7c1.6,0,3.3,0.2,4.7,0.7c3.6-2.4,5.2-2,5.2-2c1,2.6,0.4,4.6,0.2,5c1.2,1.3,2,3,2,5.1c0,7.3-4.5,8.9-8.7,9.4 c0.7,0.6,1.3,1.7,1.3,3.5c0,2.6,0,4.6,0,5.2c0,0.5,0.4,1.1,1.3,0.9c7.5-2.6,13-9.7,13-18.1C51,21.9,42.5,13.4,32,13.4z"/>
</svg> (probably a better way than the example above) Or to makes it easier for users to find the different allowed colors: variants = ['7289DA', 'FFFFFF', '99AAB5', '2C2F33', '2C2F33'];
logoColor = variants[logoVariant < variants.length ? logoVariant : 0]; |
Yeah that should work quite well,
Also here's a pretty good post about How to automatically choose a label color to contrast with background which uses the above formula. |
A few more considerations:
|
But i think for the start it may be better to just go with @paulmelnikow's idea and auto detect if the logo should be a light or dark variant (for non colored logos). |
👍 Finding or making a light/dark version of each of the current supported logos would also be an opportunity to review the branding resources for each one which might inform the requirements of a more complex solution. |
Since #1810 thanks to @RedSparr0w a color can be specified using https://img.shields.io/github/stars/django/django.svg?logo=github&label=Stars https://img.shields.io/github/stars/django/django.svg?logo=github&label=Stars&logoColor=white |
I think it would be nice to automatically detect light and dark, or let the user choose "light" or "dark" without having to pick a color. We did make progress here, so maybe that's best tracked in a new issue. |
Ah, I missed that above, yeah I think it may be better in a new issue as to not get buried. |
Sounds good. Opened #2431. |
Some logos are almost invisible on dark backgronds, e.g.,
https://img.shields.io/github/stars/django/django.svg?logo=github&label=Stars
It'd be great if there was a light version of them as well.
The text was updated successfully, but these errors were encountered: