From https://github.com/badges/shields/pull/812#issuecomment-298410104:
Please consider not adding the logo on "custom" badges (i.e. ones with labels, etc). Alternatively add logo images for all services (e.g. Travis CI).
I was the one to merge that change, though I'm open to reconsidering it.
The social badges have logos. Apart from those, 98% of badges do not. Only three badges do: Gitter, Bithound, and since yesterday, Appveyor.
Some options we could consider:
?logo=false)?logo=true)It's reasonable to maintain optimized logos, where they can be obtained, for the services we support, and ship them through shields. That's preferable to everyone encoding logos into their badge URLs, which seems totally unmaintainable. @techtonik I'm aware logos are important to you, and I think you're not alone. I'm certainly happy to accommodate any consumer who wants logos.
Should the logos appear by default though? Simplicity and uniform appearance are hallmarks of the badge design, which a lot of work has gone into.
I'm especially interested in what @espadrine has to say.
Thank you both @techtonik and @paulmelnikow for considering this in such a timely manner. Thank you @paulmelnikow for the comprehensive write up.
- Accept PRs to add logos to any badge. By default, hide the logo when the label has been customized. Show it otherwise. Consumer could override this as well.
+1 for this option.
Should the logos appear by default though? Simplicity and uniform appearance are hallmarks of the badge design, which a lot of work has gone into.
If uniform appearance is one of the primary requirements, then it follows that logos should not be included by default, simply because not all badges have logos (i.e. option (2)).
However I think a good compromise is option (3).
Logos shouldn't be on badges by default imo. From the spec:
non-promotional: badges should not advertise but instead provide value through information
How I interpret that is it shouldn't matter what service its built on, just that its passing/failing for a platform. Plus it stands out by quite a bit 馃槩

Edit: Currently the only way to hide it is to set &logoWidth=0.1, which still pushes the text to the right quite a bit due to the logo padding:

@wopian "windows" is not the default badge, so icon there feels a bit awkward, but on Appveyor badge it is logical to have this for a faster scan.
Anyway, I should open an issue to disable the logo first and then let discussion continue on whatever to implement logo hiding be default.
Anyway, this seems logical for me:
logo=false) if badge is customizedVery confusing if you have builds for win and linux/osx running...

Even if you try to customize them and write the os there, you don't get a uniform look because you can't disable appveyor logo then.
What you normally want is either:
Please add ability to disable logos and support more logos in general (esp. travis used by a lot and here is differentiation needed, maybe same problem for jenkins etc.)
+1 for option 2.
Here's a bit of a historical perspective.
I agree with @wopian; accepting having a logo by default for non-social badges was a weakness on my part during the review of certain badges.
I felt bad to accept the patches, and I shouldn't have. I would be OK with the removal of logos by default (except for social badges, where they are part of the tradition).
(By social badges I mean badges that use the social style.)
However, even for social badges, I wanted to have a way to block a default logo. Adding ?logo would do that, and I would welcome a patch that removes a logo that way.
Furthermore, we do have a few logos in /logo/, and currently adding logos to custom badges is harder than it needs to be; it would be welcome to also be able to specify logos by reference, eg. ?logo=twitter.
I opened #1092 which includes support for logos by reference a.k.a. named logos, while turning off logos by default, except for social badges, which can also be turned off if desired.
@paulmelnikow does that mean that logo= turns off the logo?
Most helpful comment
Here's a bit of a historical perspective.
I agree with @wopian; accepting having a logo by default for non-social badges was a weakness on my part during the review of certain badges.
I felt bad to accept the patches, and I shouldn't have. I would be OK with the removal of logos by default (except for social badges, where they are part of the tradition).
(By social badges I mean badges that use the
socialstyle.)However, even for social badges, I wanted to have a way to block a default logo. Adding
?logowould do that, and I would welcome a patch that removes a logo that way.Furthermore, we do have a few logos in
/logo/, and currently adding logos to custom badges is harder than it needs to be; it would be welcome to also be able to specify logos by reference, eg.?logo=twitter.