Provide a way to fix the width of a shield

[sbrannen]

📋 Description

For https://junit.org we have 3 shields that are vertically aligned as follows.

In terms of user experience, this is not optimal.

Ideally those shields would all have the same total width, and the label sections would have the exact same width so that the version sections line up exactly.

We experimented with the logoWidth request parameter, but that appears to only add left-padding before the label as follows.

As you can see above, logoWidth does not help us achieve our goal.

We also experimented with add leading and trailing spaces to the labels, but those apparently get trimmed and so do not help either.

Is there any way to achieve our goal with the currently supported API?

If not, we would be grateful if you would introduce such support.

Thanks!

The JUnit Team

[RedSparr0w]

Here is a couple of possible workarounds:

Using logoWidth:

![JUnit Jupiter](https://img.shields.io/maven-central/v/org.junit.jupiter/junit-jupiter.svg?colorB=25a162&label=JUnit%20Jupiter&style=flat&logoWidth=8)
![JUnit Vintage](https://img.shields.io/maven-central/v/org.junit.jupiter/junit-jupiter.svg?colorB=25a162&label=JUnit%20Vintage&style=flat&logoWidth=4)
![JUnit Platform](https://img.shields.io/maven-central/v/org.junit.jupiter/junit-jupiter.svg?colorB=25a162&label=JUnit%20Platform&style=flat&logoWidth=0)

Add extra spacing in-between the 2 words:

![JUnit Jupiter](https://img.shields.io/maven-central/v/org.junit.jupiter/junit-jupiter.svg?colorB=25a162&label=JUnit%20%20%20Jupiter&style=flat)
![JUnit Vintage](https://img.shields.io/maven-central/v/org.junit.jupiter/junit-jupiter.svg?colorB=25a162&label=JUnit%20%20Vintage&style=flat)
![JUnit Platform](https://img.shields.io/maven-central/v/org.junit.jupiter/junit-jupiter.svg?colorB=25a162&label=JUnit%20Platform&style=flat)

I've tried using basically all the whitespace characters at the end or beginning of the label, but they all get trimmed.
Other than %A0 (non break space) but that ends up showing as:

Edit:
Add extra spacing in-between the 2 words & using %7F:

![JUnit Jupiter](https://img.shields.io/maven-central/v/org.junit.jupiter/junit-jupiter.svg?colorB=25a162&label=JUnit%20%20%20Jupiter%7F%7F&style=flat)
![JUnit Vintage](https://img.shields.io/maven-central/v/org.junit.jupiter/junit-jupiter.svg?colorB=25a162&label=JUnit%20%20Vintage%7F&style=flat)
![JUnit Platform](https://img.shields.io/maven-central/v/org.junit.jupiter/junit-jupiter.svg?colorB=25a162&label=JUnit%20Platform&style=flat)

Edit 2:

Screenshot of how it looks on my computer in case it shows different for others

[sbrannen]

Wow. Those are a lot of options for workarounds.

I think we'll try the last one.

Thanks so much!

[sbrannen]

I'm going to leave this issue open so that the team can consider providing built-in support for achieving the same thing without tricky workarounds.

[sbrannen]

@RedSparr0w, that looks good now: https://junit.org/junit5/

Thanks again!

[RedSparr0w]

No worries, glad I could help 👍

Agree, best to keep this open, I could see it being a useful option to have.

[paulmelnikow]

Hi! I'm sensitive to the desire to make these look a certain way. However I think probably we should not do this. Shields was created to make the badges look consistent and allowing callers to override the spacing works against that.

There are a few vendors which ship badges with alternative spacing, like Greenkeeper and Gitpod Gitlab, and they don't look good.

If you want badges stacked vertically instead of horizontally, you could use a table and set the label to the empty string, e.g.

https://img.shields.io/maven-central/v/org.junit.jupiter/junit-jupiter.svg?colorB=25a162&label=&style=flat

Package	Version
JUnit Jupiter
JUnit Vintage
JUnit Platform

I realize that's not what you're asking for, but wanted to put it out there as an option.

[sbrannen]

Hi @paulmelnikow,

Thanks for chiming in and providing some background information.

You're right: one could opt for a table as you've demonstrated.

That would definitely work technically, so we'll keep that in mind as an option.

However, if you are against supporting a way to fix the width, why then do you support the logoWidth parameter?

To be honest, I do not see much value in the results of a custom logoWidth (as currently implemented), but perhaps I am simply overlooking a use case.

[paulmelnikow]

Shields supports setting custom SVG logos which can be any width, but Shields needs to be told the width in order to leave the correct amount of space. (At least I think that's the reason!)

[sbrannen]

OK. That would be such a "use case" that I overlooked. ;-)

[paulmelnikow]

As I mentioned above:

I'm sensitive to the desire to make these look a certain way. However I think probably we should not do this. Shields was created to make the badges look consistent and allowing callers to override the spacing works against that.

There are a few vendors which ship badges with alternative spacing, like Greenkeeper and Gitlab, and they don't look good.

[RuRo]

Can you please maybe reconsider? I don't quite understand your reasoning. To me

Shields was created to make the badges look consistent

sounds like an argument for allowing users to specify the badge width, not against it? My current badge layout looks like this:

The last 3 lines of badges are all created by anybadge, which does allow you to pad label and value text. The pypi badge and all the Docs badges are provided by shields.io. I've tried my best to make all my badges look as consistent as possible, but I can't get a 100% uniform look due to the dynamic width of the shields.io badges and it's driving my OCD INSANE.

Can you at least allow adding leading and trailing whitespace in the label, so that we can pad them to the right width without changing the content of the label?

[PyvesB]

Can you please maybe reconsider? I don't quite understand your reasoning. To me

Shields was created to make the badges look consistent

sounds like an argument for allowing users to specify the badge width, not against it?

As I see things, we want two badges that convey the same information on two different READMEs to look alike. Allowing users to override the text is fine, as that will lead to conveying different information (e.g. badge translated in another language). Similarly, adding a logo will convey more information. Our colours are also meaningful, i.e. they have a good/bad/informational concept associated. We have a limited number of custom styles available, some of which for legacy reasons, but ultimately we still impose what the badges will look like.

Allowing users to add arbitrary padding does not convey different or additional information, and creates infinite variability for two badges that have the exact same meaning. You could well imagine users coming up with wildly different paddings, I can even foresee some trying to make badges that fit the entire width of the README. This defeats our consistency promise, and goes against the visual specification of our badges.

If you really want to do this, you can add leading and trailing padding using the workaround described by @RedSparr0w - contrarily to what you said, it is allowed. But I'm broadly in agreement with @paulmelnikow, I wouldn't want us to surface any padding-specific options in the UI and encourage users to come up with inconsistent badges. 😉

[RuRo]

@PyvesB

As I see things, we want two badges that convey the same information on two different READMEs to look alike.

Well, it's not like slightly changing the padding of the badges makes them that different. Most users probably wouldn't even notice unless the badges are right next to each other. I guess, I can see, where you are coming from, but I still think that improving the consistency between multiple badges on the same page trumps the possibility that somebody might use the custom padding on purpose to create non-consistent badges.

---

If you really want to do this, you can add leading and trailing padding using the workaround described by @RedSparr0w - contrarily to what you said, it is allowed. But I'm broadly in agreement with @paulmelnikow, I wouldn't want us to surface any padding-specific options in the UI and encourage users to come up with inconsistent badges.

1. Baseline
2. logoWidth doesn't seem to do anythin if there is no logo.
3. Leading and trailing regular whitespace doesn't change the badge appearance for me.
   Only whitespace between the words changes the spacing, which is not possible, if the label is supposed to be one word.
4. Also, for some reason, adding spaces between words also changes the spacing between the letters.
   (Note, that I added spaces only between foo and bar here, not between individual letters)
5. %A0 and %7F both render as actual characters for me.

1) ![](https://img.shields.io/pypi/v/a?label=foo)
2) ![](https://img.shields.io/pypi/v/a?label=foo&logoWidth=8)
3) ![](https://img.shields.io/pypi/v/a?label=%20%20%20%20%20%20foo%20%20%20%20%20%20)
4) ![](https://img.shields.io/pypi/v/a?label=foo%20%20%20%20%20%20%20%20%20%20%20%20bar)
5) ![](https://img.shields.io/pypi/v/a?label=A0:%A0) ![](https://img.shields.io/pypi/v/a?label=7F:%7F)

1. 
2. 
3. 
4. 
5. 

Screenshot:

---

Edit: interestingly, changing img.shields.io to raster.shields.io produces very similar results, but the A0:%A0 badge returns an empty image:

1. 
2. 
3. 
4. 
5. 

[PyvesB]

Try experimenting with the following, you'll probably get better results:

https://img.shields.io/pypi/v/a?label=%7F%20%20foo%20%20%7F

[RuRo]

@PyvesB As I already mentioned, %7F gets displayed as an actual character.

Screenshot:

And in case you think, that this is a problem specific to my machine, here is how this badge looks, when rendered by raster.shields.io:

[PyvesB]

Here's an example of what I get:

I've tried with all the following browsers:

• Firefox on Windows.
• Edge on Windows.
• Chromium on Windows.
• Opera on Windows.
• Firefox on Android.
• Firefox on macOS.
• Safari on macOS.

None of them end up with %7F getting displayed as an actual character.

The only browser I've been able to fault and reproduce the problem is Chrome on Android. Possibly a bug to report there, doesn't seem right that it behaves differently from all others.

I would also suggest giving other whitespace characters a go, if you haven't done so already.

[RuRo]

I've tried Chrome on Linux and Chrome on Android and both have this problem. Also, raster.shields.io also renders it.

AFAIK, %7F is ASCII 127 which is the DEL/Delete control character. It is not a whitespace character (which is also why it doesn't get stripped from the string). It's a non-printable character, therefore relying on it not being displayed as a space is a horribly ugly hack.

I've tried all whitespace characters already and they all either just get stripped from the string or get displayed as some broken/missing character.

In my opinion, the current behaviour of shields.io wrt whitespace handling is very buggy (see, item 4 from my previous comment for example). I can (kind of) understand not wanting to introduce new query parameters for width control, but can you at least fix the whitespace stripping and spacing issues.

[calebcartwright]

@PyvesB -

I've tried with all the following browsers:

This also looks as expected for me in Firefox on Linux as well, though with Chrome on Android it does look off/I'm seeing the same issues RuRo reported (agreed that smells a bit like a potential Chrome issue).

@RuRo -

In my opinion, the current behaviour of shields.io wrt whitespace handling is very buggy (see, item 4 from my previous comment for example)

If there's something you think is a genuine bug (and not subjective opinion), then please open a new issue with pertinent details and context. A new issue would be a much more effective approach to sharing/diagnosing/resolving a bug as opposed to comments/asides on a largely unrelated issue that was closed more than two years ago. I don't really want to continue the off topic discussion any more here, but will note inline for context that your item 4 is different because the spacing characters are part of the label value, not leading/trailing, so it's a fundamentally different bit of text with corresponding letter spacing as well; that's by design, not a bug.

Can you please maybe reconsider? I don't quite understand your reasoning. To me
sounds like an argument for allowing users to specify the badge width, not against it?

I personally consider this matter settled, and closed. I wouldn't try to stand in the way if everyone else on the maintainer team was on board with this, but several objections have been shared already.

As P-Y shared previously, we have a specific consistency goal for the badges we produce, but you should not conflate with meaning we're aiming to allow users to define some other style/specification with which our service will also support consistency.

Infinite customization is very much an anti-goal of the project, and that's especially true for requests like this one which run directly counter to our design goals. I understand your point that you're unable to achieve your desired design using our badges and that's frustrating, but I hope you have a better understanding now of the divergence between those two and our corresponding posture.

Finally, I know it can be disappointing to not get the answer one was hoping for, but want to drop a gentle reminder to be sure to keep the conversation courteous and constructive.

[RedSparr0w]

If you don't want to use %7F then %E2%A0%80 is also another option which is not displayed in the raster link, although it is a bit larger.

svg:

https://img.shields.io/pypi/v/a?label=%E2%A0%80foo%E2%A0%80
png:

https://raster.shields.io/pypi/v/a?label=%E2%A0%80foo%E2%A0%80

Preview from my machine:

[RedSparr0w]

Also just a small note on the logoWidth, you can just use a transparent pixel as the logo, then specify logoWidth to prepend "whitespace":

https://img.shields.io/pypi/v/a?logo=data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7&logoWidth=40

Screenshot:

[RuRo]

If you don't want to use %7F then %E2%A0%80 is also another option which is not displayed in the raster link, although it is a bit larger.

Thank you, %E2%A0%80 does work, although it's indeed a bit too wide, but oh well. Apparently it's Unicode U+2800 which is "braille pattern blank". Again, this relies on the availability of Unicode braille characters in the label font, but it's definitely better than relying on the rendering of DEL. I would have preferred an actual solution to this problem, but since the maintainers seem so convinced, that stripping leading/trailing whitespace is not a bug but a feature, I guess I'll have to settle with using these workarounds.

If there's something you think is a genuine bug (and not subjective opinion), then please open a new issue with pertinent details and context. A new issue would be a much more effective approach to sharing/diagnosing/resolving a bug as opposed to comments/asides on a largely unrelated issue that was closed more than two years ago.

You are right, I'll open a separate issue for this bug. Edit: here it is #6510