Inline SVG for Retina

[nathany]

(Afaik) We don't yet have a good solution for Retina PNGs, as we cannot inject CSS into the page and Markdown processors don't support specifying image dimensions #34.

It seems like the best bet may be Inline SVG: <img src="some.svg">

Inline SVG requires IE9+ and Android 3+ but otherwise works everywhere. http://caniuse.com/svg-img We wouldn't be able to do a fallback, which requires JS.
Personally think this is fine, given the target audience (developers).

I'm not clear on how typography works with SVG. Do we have to rely on the end-user having Arial, or do we ship Open Sans outlines down for the specific text shown?

As far as an image server, it seems best to offer up both PNG and SVG. Service providers then have the option of what they offer. So Travis CI may offer both SVG and PNG options to their users, or opt for just one.

[olivierlacan]

Playing around with inline SVG using an image tag it seems feasible although I somehow remembered GitHub not allowing inline SVG from third party sites for security concerns. Guess I misremembered.

<img src="http://upload.wikimedia.org/wikipedia/commons/0/02/SVG_logo.svg" width="50" />

outputs:

@ackerdev might have a fresher memory regarding font rendering in SVG but I do remember it being an issue as well.

[bcherny]

+1

[sindresorhus]

👍

[espadrine]

I have done some work over at https://github.com/espadrine/gh-badges since a couple of days ago, along with @mathiasbynens and @alrra, and we have support for delivering SVG, PNG, JPG and GIF, although the main focus is SVG (because it is so fast to deliver, so easy to compress, and plays better with retina displays.)

We can deliver pretty much any badge, with a URL format highly similar to img.shields.io.

We have Travis-CI, Coveralls and Gittip support as well. On that note, while the code has nothing to do with Shields.io, this project helped a great deal, and I'd love to list @olivierlacan as a contributor, if you're ok with that.

The website for it is here. I hope we can work together to bring unified GitHub badges everywhere!

[chadwhitacre]

@espadrine Thanks for chiming in here! Your comment is eerily similar to #15 (comment). :-)

How can we work together? Would you be up for a Google Hangout to discuss?

[espadrine]

@whit537 Oh wow, can't believe I missed that thread. Tbh, I saw h5bp/lazyweb-requests#150, thought it was an interesting challenge, and by the time I noticed others were trying to do the same thing, I already had something decent.

I'd love to do a hangout, but I can't today, and probably can't until tomorrow afternoon CET, ~5pm ish. Can we do that then?

There's probably a notion of goals to discuss. The idea behind (what will become) http://b.adge.me is to push existing badge services to support SVG by showing how easy it is. I'm running on a free Heroku instance, and if it gained traction, … well, I'm doing this for free with no job on the side. That said, earnestly, I'm proud of the ideas I developed, and I'd love to discuss the tech side of things too.

[chadwhitacre]

Okay, so we have http://shields.io/, http://badgr.co/, and now http://b.adge.me/ all doing basically the same thing. We've already got http://badgr.co/ well on it's way to being folded into http://shields.io/. I think it's in the best interest of the open source community as a whole to do the same with http://b.adge.me/. In other words, we should add SVG support to http://shields.io/. Do you agree, @espadrine?

I'm in UTC-5, and I believe CET is UTC+1 (yes?), in which case how about a call at 5pm your time tomorrow? :-)

[olivierlacan]

NB: http://everytimezone.com/

[chadwhitacre]

Thanks @olivierlacan. :-)

[espadrine]

What I want to see is something that is fast, pretty everywhere and, if possible, consistent across vendors, although having nearly everyone using the very same thing is improbable.

The part about "pretty everywhere" is why I started with SVG and went downhill from there. Technically, adding SVG support to something designed to output PNG sounds difficult, whereas I've already solved the problem of converting SVG to PNG & cie with a pretty consistent result. I am not sure how we can fully merge the two projects, but I still have little knowledge about what is implemented in Shields and what plans lie ahead, even after sifting through a few issue threads and through the code. Obviously, the techniques used on one project can be beneficial on another. There certainly was a big duplication of efforts, but all those efforts helped in the end.

So there's that issue of merging, and there's the issue of picking a unique DNS name. Right now, I have b.adge.me for a year, and I can't cancel that. It works, to the point that I'd consider it ready for use. On the other hand, I agree that it has the same purpose and goals as Shields, I agree that shields.io is a pretty cool name (although I had never heard of the term "shield" used for that before), and I agree that having two competitors and two domains to choose from undermines the potency of the whole effort.

Overall, I believe we need to discuss how tractable a merge is technically (to be honest, I have struggled to look at Shield's code; I'm not even sure where I'm supposed to look! I'd love to have a walkthrough…) and what decisions would need to be made. If impossible, we need to pick a codebase. For that we need quantitative measurements and a qualitative list of feature goals, with information about how easy they are to meet (if they are not already met). In any case, we need to steal ideas from each other.

About the hangout, if you want later than 9am Chicago time, I can totally do it! (Up until 10pm CET.)

ps @olivierlacan that is so really cool I wish I knew about it before!

Edit: rather, 11am New York time. I guess even the greatest app can't help against misreading. In other words, 5pm CET, 11am EST, is great.

[chadwhitacre]

@espadrine Let's go for a Hangout at 11am EST (Pittsburgh! :D ) == 5pm CET (to be clear, Hangouts are live-broadcast on the Internet and end up on YouTube).

@olivierlacan @nathany Any chance you can join us at that time?

[nathany]

@whit537 I'll try to make it. Please do send me an invite.

[nathany]

@espadrine We are planning to setup and organization #88 for all things Shields and "badges as a service".

Perhaps we can move your JavaScript code, @jbowes Go code (Buckler) and @whit537 Python implementation all there to get organized and review our options.

We had selected Go because of the existence of Buckler and PNG support in the standard library. But now it looks like you are further along, as we haven't even begun researching SVG libraries for Go.

Since we are operating this based on donations, and trying to serve a potentially very large audience, efficiency (and therefore cost) of the solution will be important. Go and Node.js are both pretty good choices for that, though we can certainly measure them for our use case. We'll have to sort out our other goals as well.

In any case, your experience with SVG in the browser is invaluable. I see you list a few known issues on http://b.adge.me/.

[mathiasbynens]

I see you list a few known issues on http://b.adge.me/.

Actually, most of those issues were discovered while making b.adge.me :)

[Mikulas]

I did not read the whole thread, but in case you are still looking for the svg template, I made one (http://badges.github.io/).

As far as gradients go, that's supported well in every browser that supports svg in the first place. Embedded fonts are pain in the ass though. The only working solution is probably embedding base64 versions. Ref: http://stackoverflow.com/questions/20905026/cross-browser-embedded-font-in-svg-image It's not all that bad, the full image is like 30kB after gzip or so. With aggressive caching on both server and client side, it's totally doable.

[mathiasbynens]

@Mikulas Ah, looks like http://b.adge.me/ and your project solve the same problem! b.adge.me output seems to be more optimized, though. Would be good to merge the projects together somehow.

With aggressive caching on both server and client side, it's totally doable.

That’s the problem with these badges: you can’t cache them too aggressively because their status can change at any moment.

[Mikulas]

Indeed it is the same. Badge.me are not so silimar with the original though. It seems more optimized as far as size goes, but browser compatibility should be the same on both services.

As far as caching goes: the idea would be that each service would have it's own image server as it does now, but instead of serving png, it would redirect to a 3rd party service. That means that while the url stays the same, browser loads static images with canonical url. Travis does not do this, but for example Coveralls do (ex https://coveralls.io/repos/Mikulas/csfd-api/badge.png?branch=master redirects to https://s3.amazonaws.com/assets.coveralls.io/badges/coveralls_96.png which can be cached). Thus 1kB vs 30kB svg does not make important difference in the long term.

[mathiasbynens]

@Mikulas Ah, gotcha. Thanks for explaining.

[chadwhitacre]

@nathany Cool, will do.

@espadrine I'll send a link to join the Hangout to thaddee.tyl@gmail.com (per your GitHub profile) at 5pm your time (~40 min). See you soon! :-)

[chadwhitacre]

Anyone else who'd like to join the call, drop me a line chad@zetaweb.com and I'll include you in the invite.

[chadwhitacre]

@nathany I sent the link to git@nathany.com per your GitHub profile.

[chadwhitacre]

Call is ended, picking up the conversation on #94.

[chadwhitacre]

With #108 we are now using gh-badges, which means we have SVG now!