Skip to content
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

Use black font when background color is too light #5467

Merged
merged 6 commits into from
Sep 7, 2020

Conversation

PyvesB
Copy link
Member

@PyvesB PyvesB commented Aug 29, 2020

Fixes #4661.

I've chosen quite a conservative threshold for switching to black text. None of the badges advertised on our homepage will be affected, this functionality will only kick in with very light background colours.

Let me know what you think!

@PyvesB PyvesB added core Server, BaseService, GitHub auth npm-package Badge generation and badge templates labels Aug 29, 2020
@shields-ci
Copy link

shields-ci commented Aug 29, 2020

Warnings
⚠️

This PR modified helper functions in lib/ but not accompanying tests.
That's okay so long as it's refactoring existing code.

Messages
📖

Thanks for contributing to our documentation. We ❤️ our documentarians!

📖 ✨ Thanks for your contribution to Shields, @PyvesB!

Generated by 🚫 dangerJS against 5ba8b0f

@shields-cd shields-cd temporarily deployed to shields-staging-pr-5467 August 29, 2020 15:44 Inactive
@PyvesB
Copy link
Member Author

PyvesB commented Aug 29, 2020

Cc @subnut, got some time to work on this following your ping in #5455. :)

@subnut
Copy link

subnut commented Aug 29, 2020

@PyvesB Great!
This made my day! (technically, night. It's 10PM here 😅 )
Someone actually working on something due to my request!
Thanks again! 🥰

@subnut
Copy link

subnut commented Aug 30, 2020

@PyvesB can there be an option to override the auto-detection? Like ... textColor=dark for black and textColor=light for the default white ?
I personally think that the auto-detection should stay, but there should also be an option to manually override it.

Why? Well .. in #5455 .. I would have liked the badges having Black text. The current threshold still keeps it white.
Yes, you can always lower the threshold .. but then someone else would complain that his badge is having Black text instead of the White he expected !

So ... I think that the current threshold should be kept as it is. It seems well-thought-of. But it's always the edge cases that annoy users. So why not provide an override for them?

Just my two cents
Cheers!

@chris48s
Copy link
Member

This is really nice.

https://shields-staging-pr-5467.herokuapp.com/badge/foo-bar-white
https://shields-staging-pr-5467.herokuapp.com/badge/foo-bar-FFFF00

I appreciate the sentiment of setting a very conservative threshold so we don't change the appearance for any of the standard badge colours. Do you have any idea what sort of threshold we'd be looking at to start changing the text colour on something like

https://shields-staging-pr-5467.herokuapp.com/badge/foo-bar-9cf
https://shields-staging-pr-5467.herokuapp.com/badge/foo-bar-aqua

and whether that would start impacting any of the standard colours?

Also did you consider using the dark grey colour we use when we re-colour light logos for social badges (#333333) for the text? It might be a bit less harsh than a straight black?

@@ -10,6 +11,19 @@ function capitalize(s) {
return `${s.charAt(0).toUpperCase()}${s.slice(1)}`
}

function colorsForBackground(color) {
if (brightness(color) <= 0.8) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be clearer what we're doing here if we gave this a name e.g:

const brightnessThreshold = 0.8;

We should probably do the same thing for the logo thresholds too - those are also magic numbers.

@PyvesB
Copy link
Member Author

PyvesB commented Aug 31, 2020

@PyvesB can there be an option to override the auto-detection? Like ... textColor=dark for black and textColor=light for the default white ?
I personally think that the auto-detection should stay, but there should also be an option to manually override it.

Why? Well .. in #5455 .. I would have liked the badges having Black text. The current threshold still keeps it white.
Yes, you can always lower the threshold .. but then someone else would complain that his badge is having Black text instead of the White he expected !

So ... I think that the current threshold should be kept as it is. It seems well-thought-of. But it's always the edge cases that annoy users. So why not provide an override for them?

Just my two cents
Cheers!

Thanks for your thoughts @subnut! You've touched upon a classic problematic within the Shields project, namely how much customisation should we allow within our badges? Shields makes two main promises, readability and consistency. There's always a careful balance to strike and we need to make sure new customisation options don't impede too much on one or the other - for example we got the balance wrong in #1478.

Here, this PR trades off some consistency (i.e. text is no longer always white) for some readability (i.e. badges are easier to read on light backgrounds). However, I'm concerned that adding a textColor=dark|light option for users would further degrade consistency, as the text font color would now possibly be different for the same background color, with no clear gain on the readability side. Yes, users will be able to fine tune some specific edge-cases, but on the other hand there's a likelihood that they'll make a poor decision, copy-paste a badge URL and change the background but forget to tweak textColor (this kind of thing happens more often that you would think!) or simply specify the override on a build badge currently showing light green without realising that the badge will become unreadable when their build fails and the badge turns red!

Beyond this debate about readability, consistency and customisation, I think we should be careful when it comes to adding new options, as having too many of them doesn't necessarily help users and may even overwhelm some of them. There are already approximately ten query parameters available for all badges!

If a lot of users end up requesting an override and we can't make them happy by tweaking the threshold, then I'd personally be open to considering such an option, but I'm not keen on implementing it initially as part of this PR. 😉

I appreciate the sentiment of setting a very conservative threshold so we don't change the appearance for any of the standard badge colours. Do you have any idea what sort of threshold we'd be looking at to start changing the text colour on something like

https://shields-staging-pr-5467.herokuapp.com/badge/foo-bar-9cf
https://shields-staging-pr-5467.herokuapp.com/badge/foo-bar-aqua

and whether that would start impacting any of the standard colours?

0.75 would make the first one go black, 0.69 the second one. With 0.69 being used, I don't think our standard named colors change, but a few of the default badges displayed on the homepage do, "CII Best Practices Level", "SymfonyInsight Stars" and "9cf" from what I can tell from a quick browse through. With 0.75 only the "9cf" badge on the homepage changes from what I can see. Do you want me to lower the threshold to something in between so that only "9cf" is affected?

Also did you consider using the dark grey colour we use when we re-colour light logos for social badges (#333333) for the text? It might be a bit less harsh than a straight black?

Good point, I've pushed a commit with that change.

@PyvesB PyvesB temporarily deployed to shields-staging-pr-5467 August 31, 2020 17:38 Inactive
@shields-cd shields-cd temporarily deployed to shields-staging-pr-5467 September 6, 2020 10:30 Inactive
@chris48s
Copy link
Member

chris48s commented Sep 6, 2020

Sorry for letting this rot for a bit. The code as it stands looks good. I think we could go to 0.69 no problem (sorry I should have just played with this locally myself).

That said, this PR has got me thinking about the level of contrast on our standard colour schemes from the perspective of accessibility. Some of our standard colour schemes actually score quite poorly and could be improved. For example

Screenshot at 2020-09-06 11-55-53

Screenshot at 2020-09-06 11-56-18

I'm aware this is scope creep, so unless you really want to dive into that now I think we should probably switch the threshold to 0.69 (if you agree with that) and merge this because its an improvement over what we have now. Then as another issue it might be worth reviewing our most commonly used styles from this perspective. We probably can't rely on only brightness to get amazing contrast on every bespoke colour, but if we can use 'presets' to ensure all of these have a good accessibility score that would be beneficial.

@PyvesB PyvesB temporarily deployed to shields-staging-pr-5467 September 6, 2020 17:06 Inactive
@PyvesB
Copy link
Member Author

PyvesB commented Sep 6, 2020

Then as another issue it might be worth reviewing our most commonly used styles from this perspective. We probably can't rely on only brightness to get amazing contrast on every bespoke colour, but if we can use 'presets' to ensure all of these have a good accessibility score that would be beneficial.

Alternatively there is a color-contrast-checker package available, I'm wondering whether we could make use of that or another similar package.

I'm aware this is scope creep, so unless you really want to dive into that now I think we should probably switch the threshold to 0.69 (if you agree with that) and merge this because its an improvement over what we have now.

I've pushed the change. Agreed, let's continue to iterate over contrast in a separate issue.

@shields-deployment
Copy link

This pull request was merged to master branch. This change is now waiting for deployment, which will usually happen within a few days. Stay tuned by joining our #ops channel on Discord!

After deployment, changes are copied to gh-pages branch:

indus added a commit to js-org/js.org that referenced this pull request Sep 7, 2020
subnut added a commit to subnut/ncm2-github-emoji that referenced this pull request Sep 8, 2020
@laowantong
Copy link

Before:

51002331bf55b8f4d4cc5cd9376a01ba

Now:

image

That just ruined my carefully crafted band-aid badge 😢

@PyvesB
Copy link
Member Author

PyvesB commented Sep 8, 2020

@laowantong if you make the background a bit darker, the font will automatically swap to white. 😉

@laowantong
Copy link

@PyvesB Sure, but the background color would no more evoke a classic band aid. Thanks anyway!

@laowantong
Copy link

@PyvesB I have just switched to another service, sorry about that.

@hugovk
Copy link

hugovk commented Sep 12, 2020

Thanks, much improved!

Before

image

After

image

https://github.com/NaNoGenMo/2019

rrbutani added a commit to rrbutani/lc3tools-sys that referenced this pull request Sep 13, 2020
badges/shields#5467 unfortunately doesn't provide an override so we just have to make some of the colors darker
@PyvesB PyvesB mentioned this pull request Oct 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Server, BaseService, GitHub auth npm-package Badge generation and badge templates
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Color of badge text
7 participants