Will GitHub support our Retina badge endeavours?

[nathany]

The people #96 behind badge generation tools & services are here. We're ready to take badges to the next level: starting with Retina.

The main target for badges are the humble README files on GitHub. As we face new challenges, it would be very helpful to have the support of GitHub. @mojombo _Is there a GitHubber interested in seeing this project succeed?_

Here are some of the challenges and how GitHub could help.

SVG & Open Sans

SVG, as referenced by an <img> tag is the best option to support Retina & 4K displays now and into the future. Ideally we would like to continue using Open Sans, which remains legible at small sizes across platforms. #97 But there are some problems:

• Embedding Open Sans bulks up the size of every badge file, eating away bandwidth for both our servers and end-users (also consider mobile).
• Not all browsers support referencing external fonts from within an SVG file (apparently due to privacy concerns, so this is unlikely to change).

It would be much more efficient if GitHub, Travis CI @rkh, and other sites displaying SVG badges provided Open Sans on pages containing a badge. Something like this:

<!-- Open Sans is available for SVG badges from Shields.io -->
<link href='http://fonts.googleapis.com/css?family=Open+Sans' rel='stylesheet' type='text/css'>

Pixel Doubled PNGs & Markdown

While we consider SVG a better solution for Retina displays #102, if we did want to support Retina-ready PNGs, we would need additional attributes on <img> tags. #34

• Could Markdown itself be extended to support these attributes?
• If we ask end-users to embed <img> tags in Markdown, will these attributes be maintained when escaped? (not the case for srcset on GitHub).

If we were to pursue this path, how would we get the changes into GitHub's Markdown engine?

A year ago @vmg indicated that GitHub is using a private fork of Sundown. vmg/redcarpet#178 Has this changed? (say to the open source https://github.com/hoedown/hoedown descendent).

As we progress, there may be other situations where having a GitHubber involved on the Shields.io team would be very beneficial. Thanks for your attention.

P.S. Though not entirely related, it's sad that we haven't yet heard from GitHub Support regarding this issue. badges/buckler#27 😦
P.P.S. Financial support on https://www.gittip.com/Shields.io/

[vmg]

Hey! Cool looking project. I just found out about this right now. :)

It would be much more efficient if GitHub, Travis CI @rkh, and other sites displaying SVG badges provided Open Sans on pages containing a badge. Something like this:

I'm afraid this is not an option. In general embedding SVGs in READMEs is discouraged (they can get quite heavy), and embedding fonts inside of SVGs doubly so, as the images simply balloon in size. Serving the custom font ourselves doesn't solve anything and forces users to get even slower page load times.

Could Markdown itself be extended to support these attributes?

The right way to go about these extensions is to simply tell users to use the raw HTML feature of Markdown that allows them to embed whatever HTML they want in their READMEs.

If we ask end-users to embed tags in Markdown, will these attributes be maintained when escaped? (not the case for srcset on GitHub).

The sanitization code we use for <img> tags is open-source in the html-pipeline repository. You can propose the change and it can be discussed. :)

https://github.com/jch/html-pipeline/blob/master/lib/html/pipeline/sanitization_filter.rb

A year ago @vmg indicated that GitHub is using a private fork of Sundown. vmg/redcarpet#178 Has this changed?

No, we're still using the same private fork (which happens to be the vanilla code of vmg/Sundown with a custom API wrapper).

Though not entirely related, it's sad that we haven't yet heard from GitHub Support regarding this issue. badges/buckler#27

As you probably know, we proxy all non-https images with a daemon called camo to prevent mixed-content warnings. I'm not sure of why these badges are failing to resolve for camo, but it's probably because they are being dynamically generated. I'll see if I can prod somebody to look into this, but you can also try to reproduce the issue, given that camo is open-source too. https://github.com/github/camo

Much love!

[chadwhitacre]

camo is open-source too. https://github.com/github/camo

That's 404. I guess https://github.com/atmos/camo?

[chadwhitacre]

Serving the custom font ourselves [...] forces users to get even slower page load times.

@vmg It's possible that there are enough badges on GitHub READMEs that preloading Open Sans would decrease page load times overall, because once the font is loaded it would stay in browser cache for a long time, and SVG badges without the font embedded are smaller than SVG with the font embedded (of course), but also than PNG.

E.g.:

format	bytes
SVG + font*	61,004
PNG	1,756
SVG*	805

* SVG versions are here and were produced by @Mikulas' and @espadrine's code, respectively.

If Shields goes with PNGs, we have to at least triple-size them to account for Retina, so un-font-embedded SVG is going to be even more of a win from a size standpoint.

[espadrine]

@vmg Can you help me figure out how to modify GitHub so that it shows SVG files from the repo as images, just like it does with PNG files? Which repo handles that?

For instance, ![alt](file.png) works in a Readme, but ![alt](file.svg) doesn't seem to work.

See for instance https://github.com/espadrine/ass/blob/601a7027d1874010a8b333ac98ae2084f10e0e74/example/README.md (with SVG) and https://github.com/espadrine/ass/blob/601a7027d1874010a8b333ac98ae2084f10e0e74/README.md (with PNG).

In this case, I am trying to have a small SVG badge stored alongside the project, in the repo.

[chadwhitacre]

The answer here seems to be, "no."