logoColor is ignored for specific icons #6208
Comments
Andre601
added
the
question
|
That's because we use a custom logo for PayPal, not the one from Simple Icons https://github.com/badges/shields/tree/master/logo There was some lengthy discussion in #2510 around cases where we were using custom logos to identify places where the SI icon was deemed to be subpar compared to the custom logo, and the custom logos were kept in those handful of cases with PayPal being one such instance. IIRC, the custom logos that take preference over the SI ones do not support the color override by design. I'm not sure the underlying calculus has changed here to the extent that we'd stop using our existing logo for PayPal and use the SI one instead. If you'd really like to get a white-colored version of the SI icon, then I'd suggest considering using the https://github.com/badges/shields/blob/master/doc/logos.md#custom-logos |
|
That's understandable. A reason could perhaps also be branding or similar. For example: Would then result in: The reason why this would be useful to have is simple: The above example is a horrible, extremely long URL that is not pretty to look at, especially on GitHub, when f.e. reviewing the Raw of a Markdown file (And according to Your site is there even the chance that it won't work when the Base64 code/the file(?) becomes too large) Having this little prefix could help us for sure. Btw. I tried the Base64 one as seen above, but it seems that the |
Indeed. Some of these were provided by the upstream service/platform, one of which in particular has raised objections in the past to their logo being modified (which isn't all that surprising)
I might be receptive to something like this, provided sufficient justification can be provided which clearly outweighs the drawbacks of doing so. That threshold hasn't been cleared yet for me though, and I don't know how other maintainers would feel about such an enhancement in general.
To be frank, I don't find this argument compelling at all. A badge url is something that gets generated once and then tossed in a file. It's not something one has to remember, nor type/paste in a browser on a regular basis, nor regularly review/modify/etc. I typically find using markdown reference links to be beneficial in all but cases with the shortest of links, but you'd almost certainly want to use reference links for a badge url that had a custom logo, and you'd stick the second portion (which contained the full url value) somewhere else out of the way and likely never look at it again. The aesthetics of a url seem quite irrelevant here.
I'm not sure if there's an intended question here. Please feel free to follow up, and elaborate, if there is and it's not answered below Our docs from here: state:
The cap on the request size headers is something that's enforced by Node.js itself, not us. I think it's unlikely you'd manage to hit this limit using one of the simple icon logos, but the easiest way to find out would be to actually try.
We intentionally do not support processing of arbitrary/unknown input provided for custom logos, and we're not going to change that. When using custom logos it's the user's responsibility to generate/retrieve their desired logo with whatever sort of modifications you want; we won't do that on the fly. If you want an all-white colored version of the Simple Icons PayPal logo then you'll need to do that yourself, and then generate the encoding value that you could then provide for the |
To make sure we're discussing icons with the latest changes in mind, I've regenerated a table containing our custom Shields.io icons, the Simple-Icon that led us to prefer the custom Shields.io at the time, and the latest Simple-Icon:
The Bitcoin Simple-Icon doesn't seem to have changed, but I feel that pretty much all other Simple-Icons have improved compared to ~3 years ago. Given this, and given that maintaining custom icons causes confusion with users every now and again (latest in date being #7576), do we think there still is a compelling enough reason to not fully rely on Simple-Icons? I'd personally be leaning towards simplification and removing all our custom icons. If some users felt strongly about one icon or another, they can always provide their own encoded one via the |
|
To avoid any potential confusion for future readers, #6208 (comment) includes a response to part of something I said in #7576 (comment), with that response being posted here in an effort to consolidate threads. Thanks for pulling together an updated table @PyvesB, definitely helpful to have the visual inline along with the corresponding updates.
Absolutely yes, and I don't think it's possible to drop all of our logos. I think the foremost reason for this is that some of the custom logos we maintain are based on asks/requirements from the upstream services. For example, #2931 for Dependabot, and the Travis folks reached out directly to one of maintainers in the past to explicitly request their logo be left as-is and not modifiable with our custom coloring. I believe at least one or two others were as well, but those are the two that always come to mind for me. Secondly, while we're obviously deep into subjective territory, I think most of the SI logos still look quite comparatively inferior in our particular badge context. I agree that several of the SI icons look better today than they did before, but I still think we have to compare them to our existing badges/what our users are actually seeing because that's the delta that would be experienced. I think such a change would prove quite jarring in its own right, not to mention our goal of not changing existing badges (I can't see any possible way we could categorize any such change as a "bug fix"). In general, I think that logos which heavily rely on multiple colors for identification/differentiation as part of their default branding really do not lend themselves well to the SI monochrome version, especially when our own custom coloring is applied via
I might be able to convinced we could drop one or two of these custom logos, but I just don't see a way we could drop all of them for the reason above. That IMO removes any simplification opportunities since we'd still have to deal with both kinds. While I agree that questions/confusions about this do occasionally recur, I feel like it's relatively rare especially compared to various other things that seem to pop up nearly weekly/monthly. The encoded custom logo option can also used for those that want the SI version as I'd noted above and on the other thread. Perhaps if we were starting from scratch we could go a different route, but at this point I'd be opposed to forcing the SI logos on all our existing users and forcing them to have to go the custom route especially since I feel none are an objectively clear win and most/all are arguably a step backwards compared to what folks see on their badges today. |
|
Whilst I do understand and share some of your concerns on this, I think it's worth pointing out that things are not quite the same today. If I'm reading things correctly in #1276 and #3047, the main reproach at the time was that using the Simple-Icons Travis icon violated their branding guidelines; in particular the mono-colored aspect was an issue back then. However, the situation seems to have evolved, given that they've since then themselves discussed and contributed a new mono-colored logo to the Simples-Icons project (see simple-icons/simple-icons#2842). Relying on the Simple-Icons version would effectively now leverage a logo which was provided and sanctioned by their own designer, for consumption in third-party projects. As far as Dependabot goes, the situation is also different to what it was back then, it's now part of GitHub and the whole branding and communication around the product has changed. If this icon ended up being the last remaining blocking one, would there be any harm in simply raising the point with their team and see what's their opinion on Simple-Icons vs. Shields.io icon today? They contributed the icons to both projects, they may be receptive to a consistency argument.
I was under the impression that we had explicitly chosen not to follow that goal for logos. We've delegated the logo maintenance to the Simple-Icons project and, unless I'm missing something, regularly bump versions without second-guessing the content of updates. My above table highlights how much badges can change without us even noticing, or caring for that matter. Aside from the two special cases we've mentioned, it seems odd to me that we apply a special policy to a tiny subset of the 2000+ icons Simple-Icons provides nowadays, and shy away from reconsidering what is mostly a personal opinion made by Paul (#2510 (comment)), said opinion being stale as based on the 2018 versions of the icons. Don't get me wrong, I don't want to get rid of this at all costs, especially if other maintainers think it's a terrible idea. But on the other hand I don't think it hurts to revisit decisions made years ago if the reasons underpinning them might no longer be fully valid. |
|
I personally would like to go ahead and give the following point now, which may be interesting to consider: If a brand, company, you name (I call them "brands" from now for simplicity) contacts you and requests changes to their specific logo, which in the end makes it a non-monochromatic SVG, why even bother keeping it? Personally, I believe that Simple Icons shouldn't bother with catering towards a few specific cases here. Of course, that's quite an extreme approach, depending on how you view it, but considering the benefits over the drawbacks, could this perhaps be better. Something that could be considered here is how and where the icons are mostly used. The first thing that comes to mind for me is Shields.io, but there sure are other places where the logos are used. And the question there would be "How much is logo X used to justify keeping it?" Keeping popular logos around may seem logical, but also keeping around logos nobody uses doesn't seem useful either, no? Anyway, enough of my ted-talk here. Just wanted to share an idea/thought that went through my mind for a while. |
|
Thanks @PyvesB you make some compelling points in your rebuttal. However, I'm a little puzzled by one theme/thread 👇
There's certainly no harm in the discussion! I'm not sure what would've caused that inference. I have absolutely been considering your proposal, I just have a different opinion. I think most of the new SI logos look significantly worse than what we have today. That's my own personal opinion from Feb 2022 and not dictated by Paul's personal opinion from 2018 whatsoever. As such it seems unfair to characterize what I've said as a hesitance to reconsider or based on someone else's opinion. You make good points on the vendor front, certainly with Dependabot and Travis (although maybe some vaguely adjacent types of convos on the vendor-preference front happening over there too? simple-icons/simple-icons#6544). Regardless, I do think you're spot on that it's worth chatting with those folks for a more recent perspective vs. taking past directives as being permanently etched in stone or making any assumptions on our end.
I think this is also fair push back, at least to a degree. Where I feel there's some important nuance though is that we have explicitly communicated the SI side including that it's a Shields feature coming from a dependency, along with how we update that particular dependency in https://github.com/badges/shields/blob/master/doc/logos.md#simpleicons. We also take some extra steps with major version bumps of the package (certainly compared to our other deps). The difference, again informing my opinion, is that we're talking about changes to Shields vs. changes to a 3rd party lib Shields consumes. Yes, both types of changes can manifest themselves to the user, but IMO dependencies getting updated are a different story. That certainly doesn't mean it's impossible to make any changes, but I don't fully agree that dependency updates gives us an automatic license to change something else either. Perhaps this is just because we're looking at it from different sides of the coin, but I tend to look at this more from the lens of "why should we make a change that impacts our existing users" as opposed to why not It seems to me that the arguments in favor of/benefits of change would be:
A+B are both genuine, realizable benefits IMO, with B only being beneficial for the Shields maintainers. C is, unequivocally, deeply subjective, and as I've stated a few times, untrue in my opinion. I feel it's safe to assume that some non-zero portion of our existing and perhaps future users will share my opinion on C. Some subset of those would in turn then need to go back to the same As such, I don't know how well we'll be able to qualify C based on our own individual, and differing opinions on whether the SI logos look bad vs. great vs. sufficient enough to warrant a change. This is a case where I'd think we'd first need to at least attempt to solicit some user feedback (very difficult given our current inability to mass communicate with our users in a meaningful way) to get a feel for what the impacted users actually think. If we get confirmation from the vendors that they don't care/prefer SI, and some high percentage of our users tells us they don't care/prefer SI then that makes things especially clear, and easy to move forward. If we can't manage to get any feedback, then I feel like we should at least find a way to get to a high degree of confidence that the benefits of such a change outweigh the potential impact. You've definitely started tipping those scales for me towards your side (particularly on the vendor front), but I'm still not all the way there just yet 😆 |
Certainly would be useful information @Andre601, but not information we have and I doubt ever would have. By design, we do to not capture and store that level of metadata around things like query parameters on the requests that we receive. I think the challenge with the second piece of your comment is that we don't have that level of tracking and in the absence of data, should not ever look at things from the presumption of "no one uses this, or no one cares, so let's delete it" Other maintainers will likely disagree with me, but I personally believe there's been cases where we were a little too willing and a little too quick to make a change, typically in response to a request from one recent/load voice, and that in turn had a negative, and wider impact on our existing users. I realize change is inevitable, but I'm definitely in the more change-averse camp |
I'll just respond to the human bit for now, as that's the most important. Long day on my side (in a good, but tiring way), and I ended up being over zealous in trying to make the corners extra round. The intent was to lay out a basis for a good discussion, but this visibly came across as suggesting you were ~stubborn or averse to any reconsideration. Apologies as this was not what I meant. I'll get some sleep now. :) |
|
No worries! Go catch some 💤 😴 |
I should also take sleep, because looking at my message, I'm embarrassed, because I honestly thought this was the simpleicons repo rather than shields.io.... 😅 |
Agreed. Shall we do this before talking to vendors? If it turns out users are massively in favour of keeping our custom logos, there's limited value in bugging vendors and investing time in those conversations. I'm thinking of doing something similar to #4564, along the following lines:
I think we need to be extra transparent on the next steps we'll be taking. For example, imagine an unlikely scenario where folks vote in favour of the Simple-Icons version for 9 out of 10 logos. Do we bar ourselves from fully sunsetting our custom logo functionality just for that one logo? These are the kind of rules I have in mind:
How does this sound? |
Good point, I think that sounds like the right path forward.
I need to think on this for a bit. I definitely agree with the transparency angle, but I also want to be careful to not give anyone the impression that this will be a purely democratic decision (at least I'm operating under the assumption that it wouldn't be). The rules you've outlined sound like a perfectly reasonable framing to me, but would need to ruminate a bit if we'll have determine and communicate a value for X ahead of time which we'll then be locked into. |
I roughly had 6 in mind for X, as that basically means more than half of our custom logos look better in Simple-Icond nowadays. If we don't want to lock ourselves into a value of X, we can also word things as "if there is a significant drive towards Simple-Icons for several logos, we'll discuss whether aesthetics concerns for the remaining ones outweigh the gains that could be achieved by a full removal. We'll consider the votes carefully to inform our decisions, but the maintainer team will be solely responsible for making the final call." |
I'd be good proceeding with this approach today. My reason for wanting to take some time to consider the value for X route is how we'd handle an extreme reaction to one particular icon. In essence getting back to the question you raised earlier of how to handle the hypothetical of an overwhelming majority to move 9/10 to SI, but a similarly large type of support for keeping one of the existing custom logos. I'm not sure what the right X would need to be to trump a similar large support for any particular icon. Something that's also likely a safe assumption, but worth confirming, is that all of our existing custom logos could indeed be used with the base64 |
I've just checked this. Our custom Travis icon is too complex and is above the limit. All other logos seem fine. |
|
Thanks for checking, and glad we did as I assumed those would be fine. This could potentially be a wrinkle if there ends up being a sizeable number of users that both are using the current icon and feel strongly about it vs. the simple icons version. I wonder if there's a sufficiently clever search query that we could run on GitHub to find such badges in readmes (realize that's not a magic wand but could be useful info) |
|
I open a pull request #8263 that fixes this issue and finds a compromise for Simple Icons or custom Shields logos? #7684.
|
|
We've just merged and deployed #8263 which implements a compromise for this: In cases where we hold a custom (multi-coloured) logo, that one will be used in preference to SimpleIcons.
This does represent a behaviour change for any existing badges using a custom logo with |
Are you experiencing an issue with...
🪲 Description
Some specific logos/icons seem to ignore the
logoColoroverride when applied.In my case does this happen with the
paypallogo.The SVG icon provided by SimpleIcons seems to be a single-coloured SVG.
I can't tell if the icon actually is single-coloured tho, or if either shields.io or SimpleIcons override this default SVG colouring when requested.
🔗 Link to the badge
Example:
https://img.shields.io/badge/Donate%20with-PayPal-blue?logo=paypal&logoColor=white
Result:
💡 Possible Solution
If any override is used to alter the colour, or if the PayPal icon is actually a different one (Not from SimpleIcons), should it either respect the logoColor option, or not have the override at all.
If this is a SimpleIcons bug, let me know and I'll report it to them.
The text was updated successfully, but these errors were encountered: