Add flat style SVG
Opened this issue · 7 comments
Lots of people prefer flat style badges as seen on shields.io. It really looks awful when only one or two badges stand out of the line by not being flat.
I started looking into how to change this before I actually looked into the issue...
I'm pretty sure the badges already are the flat style... at least the ones on http://www.repostatus.org/ appear to be, and the ones in the code snippets appear to be. What badge URL are you using?
The shields.io section on custom badges says, "The following styles are available (flat is the default as of Feb 1st 2015):". The repostatus.org badge generation scripts don't explicitly specify a style, so they changed when shields.io changed the default:
- 0.1.0 - plastic:
- 0.9.9 - plastic:
- 1.0.0 - flat:
- 1.1.0 - flat:
- latest - flat:
My recommendation would be to use the latest versioned badge URLs, specifically http://www.repostatus.org/badges/1.1.0/<status>.svg. Personally I use badges/latest/ on my own projects, but I understand that most people probably want to pin to a specific version so the badges will not change over time.
Please let me know if that fixes the issue for you (perhaps you are using the 0.1.0 or 0.9.9 versioned URLs?). If not...
As to adding support for multiple styles... the specification is explicitly based on using the badge/image URL as the status identifier, and is specified as /^http[s]?:\/\/.*repostatus\.org\/badges\/(.+)\/(.+)\.svg$/ where the first capture group is the specification version, and the second is the status name. The only way I can think of supporting user-specified styles would be a query string appended to the image URL (?style=<whatever>) which should work (and will work with all of the parsers, and would have to work with any parser that's markup-agnostic)... but right now repostatus.org is hosted on GitHub Pages (free...) and there's no way to support that. I suppose it would be possible, though exceedingly ugly, to maintain compatibility with the current specification by using badge filenames like STATUS_NAME.svg.flat.svg or STATUS_NAME.svg.plastic.svg...
First of all, thanks for your detailed response, much appreciated.
Secondly, I am truly sorry, I was misleading. When I said flat, I actually meant flat-square.
Of course I understand the hosting concerns.
I also know that the URL is actually meaningful in this case, but maybe you could consider "integrating" repo status badges into shields.io.
Ah, ok. No worries.
I'm curious how you mean integrating them into shields.io... I imagine that would require both support from them, and changing the URLs (which are essentially the whole specification)?
While it's ugly, if there's interest from others, using URLs/filenames like <status>.svg.<style>.svg for non-default styles would meet the spec and allow them to continue being served from static content...
I'm curious how you mean integrating them into shields.io...
Well, to be honest I don't necessarily see the URL parsing useful at the moment, so what I am going to do now is to just add the badges, and don't really care about URL parsing. As such, for me it wouldn't matter if the badge comes from shields.io or repostatus.org
That said, I understand that it's not the intent.
One possible solution for the URL matter might be placing a free CDN (like Cloudflare) in front of the Github Page repo to introduce some dynamic content. Not sure if that would work, but might be a start.
I could see how people would like to set a style to use to match all other badges they already have in their readme to make it visually coherrent.
As @jantman said the best solition would be a query parameter, much like shields.io does it themselves. However that would require a different hosting and with projects like this it is always difficult to do that because that hosting needs to be in someones hands and ideally that would be some sort of organization that runs the project rather than a single person.
Adding <status>.svg.<style>.svg could be a valid option though I think it would break current parsers as <sttatus>.svg.<style> would be captured as the second group. As the RegEx currently matches until the end of a URL. A way to keep the old RegEx working could be to differentiate between styles by subdomain but that just seems so wrong.
I am rather okay with breaking compatibility to move towards something better. As long as that is really woth the effort. And I am not sure how big of a use-case this really is. Thus I would vote to leave it be for the time but change it should more people want this. Or maybe keep this in mind should something like a next major version be planned to use that break to also introduce capability for this feature.
I may have a solution for the hosting problem: recently I found Netlify which provides FREE Pro tier for OSS projects (besides the already cool Free plan, which allows using Let's Encrypt certs which already beats Github Pages to the ground, just my 2 cents).
It has a feature called "Redirects and Rewrites" which even supports some Query Param magic. I haven't checked it in details, but it looks awesome and might serve as a solution to the hosting problem.
I've come across this issue whilst looking at CodeMeta. The developmentStatus attribute is based on the status' outlined within this project.
Similar to the above though I would also prefer to use the flat-square style of badge.
Possible options for consideration:
- release a v2.2.0 which changes to the flat style
- release a v2.1.0-flat which contains the flat style (i.e. use git tags to maintain the existing url schema)
- release a v3.0.0 which updates the parser regex to something like
/^http[s]?:\/\/.*repostatus\.org\/badges\/(.+)\/(.+)(?:\-(?:flat|flat\-square|for\-the\-badge|plastic|social))?\.svg$/ - release a v3.0.0 which updates the parser regex to something like
/^http[s]?:\/\/img\.shields\.io\/badge\/repo%20status\-(.+)(?:\-.+)?$/