Replies: 4 comments 3 replies
-
|
Thanks for sharing your idea! I think it's pertinent to link to our existing documentation and posture on logos for readers. I've noted this elsewhere, but I'm adamantly opposed to our team taking the ownership responsibility of any new icons and strongly believe we should only support those icons which we can readily and easily get from prominent, well known npm packages, e.g. what we already do with Simple Icons. I'm not necessarily opposed to incorporating other icon-producing packages, but obviously there would be a lot of requirements such a hypothetical package would have to check and a lot of considerations around things like consistency and collisions between anything new and our existing support. All that being said, I remain thoroughly unpersuaded by the long/large url argument for the logo query param and am not convinced a change is worthwhile just for the benefit of having prettier badge urls (similar discussion back in #6208 (comment)). From my perspective there is some merit to the url friendliness in cases like the Dynamic badges which often contain gnarly parameters (like json path queries) which do have to be manually typed/read/debugged/etc. by humans on occasion, and Paul's convinced me that we shouldn't exacerbate the url/param complexity in those cases for those reasons. However, for me that does not apply to a base64 logo query param; it's a one time copy/paste of a value that myriad free tools can generate instantly. If someone can make a compelling case that the current Simple Icons based feature is insufficient for our community at large (not just bespoke cases) and that additional icons are needed along with a practical way of doing that, then I'm certainly open to considering such a proposal. However, I'm not onboard with doing it simply to avoid a long query param for custom logos. I think one viable way for helping folks better deal with custom logo desires might be some documentation/collation of examples which we could link to and/or include in our Awesome Badges material |
Beta Was this translation helpful? Give feedback.
-
|
Has been a while since I made this, so I'll respond real quick...
Octicons is available as a NPM package (Amongst other distribution types I believe) and since it's the official Icon set of GitHub that is made from and used by GitHub would I say this checks the "prominent, well-known npm packages".
I beg to differ. I take an example with Java. In Java, you can - like with so many other languages - write documentation which can be rendered into readable HTML pages. And while I can do this... /**
* Some description with <b>HTML stuff</b>
* @param firstParameter The first parameter
* @param secondParameter The second parameter
* @return Some text stuff I guess
*/...and that would render just fine because the Javadoc.exe couldn't care less about spaces, new lines, etc., is it not common to do, simply because it makes reading it from source a more difficult task. The same applies for markdown files here. A smaller URL such as... is easier to read than its Base64 counter-part ...since it's much more clear to understand what And when you as a first-time contributor have to update the readme, or any other markdown file for that matter, and you get greeted by this chunk of text, you sure won't feel that happy about it. You will probably worried as you could break stuff, especially when your goal is to actually update that particular URL. With a smaller URL would it be more clean and easy to see which part is what.
If I had the knowledge would I have made a simple site setup that would have an octicons parameter and essentially does the work of getting the SVG, applying a proper fill, encoding it and putting it as logo info, before returning the SVG, but as of now I do not have the time nor real interest in figuring this out by myself. |
Beta Was this translation helpful? Give feedback.
-
|
I feel like you're still missing the bigger picture here because you're looking at it from the perspective of your particular use case, whereas we have to look at the entire user base and the platform itself. The problem is all the associated negative side effects and snowball potential of making a change to provide shorter urls for one icon set. You want this particular set of icons, but if we include the one you've asked for, why shouldn't we include Material as you also suggested as well as any and every future request for yet another set from any other user? As I noted previously, slugs are unique per package, but not across, so how would we handle conflicts where a slug reference exists in multiple sets? Would we have to extend our own API surface? It's not that we wouldn't like to be able to give you a shorter url, but the reality of possible drawbacks significantly outweighs any potential benefit for what in my opinion amounts to nothing more than a slight convenience.
I don't want to continue to be too sidetracked on the url piece you're continuing to focus on but will respond because I still feel the context of your argument is predicated on the notion of not using core, common markdown constructs like reference-style links. I can add a badge to a readme with the inline url syntax: And yes, if I have a lot of images with long references at the start of my readme that can add a lot of up front material to the raw markdown. However, I could (and I'd argue should) instead use a reference-style link which I can stick anywhere in the document, including at the very bottom, for example if it's a long url. I've been a fairly active contributor to projects over the years and I'm not sure if I've ever needed to modify the readme badge of any project as a casual contributor. Much less can I imagine this being a common occurrence for contributors, or needing to look at the raw markdown form of a readme and getting intimidated or turned off from contributing because the readme source included a long url/string/etc. Again, a shorter url would be nicer, but the hypothetical of a project refusing to use something as trivial as reference-style links, or even using them and the presence at the bottom of a document in turn having contributor impact is an incredibly fringe edge case that it's just not compelling in the slightest. |
Beta Was this translation helpful? Give feedback.
-
I did mention a solution: And about the icon thing (when or IF one should be adde):
Debatable. With the solutions I gave would the drawbacks be fairly small if not even non-existent.
I am well-aware of the reference style URL (btw you can do This doesn't fix the issue and at most push it under the rug for others to deal with.
It's something that still can be scary because it's not directly visible where the URL would end.
To be honest: Your opinion. So far I only saw you doing the comments and not everyone else. |
Beta Was this translation helpful? Give feedback.
-
|
While I appreciate it can be frustrating to not get the desired answer or to have folks disagree with you, I'm still surprised by the tone you decided to take in your response. I have to say I found it unnecessarily patronizing and flippant, and I did not appreciate it. In my experience, decisions/considerations around technology-related topics rarely have an easy and ubiquitously obvious answer. It's not that a technical solution doesn't exist, but instead it's more about the set of trade offs with individuals weighing the pros and cons of each option and then expressing their opinion or making a decision based on how they view those tradeoffs. I believe your ask is a canonical example of that paradigm. It's not that it's technically impossible, but as I've stated a few times, from my perspective the drawbacks of your ask significantly outweigh any benefits. You obviously feel differently, and that's perfectly alright! Shields is a community project and all are welcome to participate in discussions, share opinions, and agree/disagree, regardless of whether they're a user, maintainer, or neither. That includes you, and that also includes me. As such, do not to presume to tell me,nor anyone else, otherwise simply because they are expressing opinions that differs from yours. It's also not my responsibility to try to solicit opinions from others which align with your own. I can assure you that if any maintainer feels strongly enough to comment they will unequivocally do so, regardless of any other opinion that's already been expressed. Similarly, our users do not hesitate to join in on discussions about things they feel passionately about, even when it's something we've already explicitly, and officially, refused. This particular discussion was created more than four months ago, and while one maintainer (myself) has expressed their opinion, the topic has still been left open and unresolved for any additional discussion. Obviously no one else has chimed in yet to agree/disagree with either of us, but as stated earlier, are welcome to do so (though will note there's not much value in anyone stating the obvious, uncontroversial notion that a shorter url is preferable to a longer one). I'm always open to changing my mind/opinion, especially when new information becomes available. However, I haven't yet seen any sufficiently persuasive or new information on this topic, and I remain. I also don't have the energy or bandwidth to keep rehashing the same topic, so unless new information and/or perspectives are added, this will likely be my last comment. |
Beta Was this translation helpful? Give feedback.
-
|
I've not fully read this wall of text, but I'm not convinced on adding another icon set, be that OctoIcons, FontAwesome, a set of flags or some other icon set (all things someone has suggested at some point). Incorporating SimpleIcons has probably been a net gain for us because we've used it as a way to stop accepting PRs for custom logos into core, but it also shows that pulling in an external icon set generates a non-zero maintenance/support overhead even if someone else maintains the library. |
Beta Was this translation helpful? Give feedback.
-
|
I'm generally quite keen on the "keep things simple" principle, and incorporating a new icon package with a bespoke As mentioned by @calebcartwright , it also sets a precedent and opens the floodgates for any random icon package requests. Lastly, I'm not a fan of the whole idea of using Octicons, as they are an official GitHub icon set. Even though Shields.io is popular in GitHub Readmes, it's also widely used in many other places, and increasingly so. I like the implicit openness that comes from using a neutral icon set like Simple Icons, rather than a vendor-specific one.
This would seem like an ideal way forward. |
Beta Was this translation helpful? Give feedback.
-
The issue
Shields.io doesn't seem to have support for using GitHub's Octicons without the utilization of Base64-encoded SVG-data.
I love using Octicons as they're the official icons used on GitHub and fit perfectly in my README's and other documentation files.
But with having to use Base64-encoded SVG-data do I always end up with unreasonably large URLs that are an eye sore to look at when viewing the raw Markdown file.
The idea
Shields.io should offer direct support for GitHub's Octicons in the
logoparameter.To achieve this while not breaking or conflicting with existing SimpleIcons SVGs could the name be prefixed with
octicons:to allow a clear distinction of the Octicons from SimpleIcons.Example
Here is an example Badge I currently use:
The current, full Markdown with the Base64-encoded SVG icon would be this:
With the proposal implemented would the new URL look like this (if the SVG Logo allows coloring that is):
This would open up a lot of new possible icons to use, while the overall length of the URL stays small, which may or may not be important, depending on where or for what you want to use the badge.
If doable and useful could this system also be expanded to other (open source) Icon collections such as Material Design Icons
Beta Was this translation helpful? Give feedback.
All reactions