decide whether PNG or SVG is primary

[chadwhitacre]

This came to a head on "Inline SVG for Retina" (#80), and is tightly related to "Font for badges" (#97).

[nathany]

IMO both should be supported. An API request for build-passing-brightgreen.png provides a PNG and build-passing-brightgreen.svg provides an SVG.

This leaves it up to the service (Travis CI, etc.) to decide which to use based on the pros/cons that we present for each, or they can in turn offer that choice to their end-users.

I think there will be reasons to offer PNG for the foreseeable future:

• to transition existing users from one of the badge APIs
• for companies that want to support older browsers

So if I can reword the question, should PNG or SVG be our primary Retina strategy? Should we pursue pixel-doubled (or tripled) PNGs at all (#34)? Or do we offer PNGs merely for compatibility and focus on SVG as the forward-looking approach.

[espadrine]

I agree with @nathany that both should be supported. However converting the SVG to PNG yields better image consistency easily.

(That said, if @nathany want to try to do a Go process that returns exactly the same image, the data for the gradient is in template.svg and the color schemes (green, red, …) are in colorscheme.json, and the system assumes you have a copy of Verdana.ttf sitting in root. Making it communicate with the node server will probably be cake.)

Also, to me, SVG should definitely be the Retina strategy, because of 3x Retina already in the market.

Also, if we do go ahead with starting with b.adge.me code, that's what we get.

[nathany]

Srcset does support having 2x and 3x PNGs, but we would need to test browser compatibility.

<img src="badge.png" srcset="[email protected] 2x [email protected] 3x">

Reference: At long last, browser makers adapt to Retina-quality images

Another alternative is to always send 3x PNGs with a height specified.

It shouldn't be hard to add to gh-badges if we want to support this option (as well). But there could be issues with Markdown processors in how they escape things.

[espadrine]

@nathany That was before they decided that srcset was not generic enough. They then chose to implement src-n, but I believe they are still fighting with <picture> to this day, see eg this.

We really cannot compare the state of SVG implementation with srcset implementation (or rather, draft work) in browsers. We have to use SVG as the primary Retina solution, and do some patch work for PNG images.

[nathany]

Yah, srcset is probably too new. That other alternative is to serve a pixel-doubled PNG with a fixed height. I don't know how nicely it will render on non-Retina displays. #34 (comment)

I'm pretty confident that we can find a workable solution for font in SVG #97 and with Lonely Planet adopting SVG it's certainly ready for prime time.

So I'd prefer to use SVG as our primary (and only) strategy for Retina.

We do need consistency between the two. Obviously there will be some difference to someone using a Retina display if there is a mix of old PNGs and new Retina-ready SVGs.

Perhaps @olivierlacan can speak to the key factors for consistency between the two (baseline, colours, gradients, legible font...).

[chadwhitacre]

With #108 we are using gh-badges, meaning SVG is primary.