Icon font display on local and live

[meiqimichelle]

To use the font file on gh-pages, we have to specify the full path to the files. Usually this is done through a Jekyll mustache dealy so it can be easily switched for local versus live. However, for the font as it is currently structured, there is a path in a css file, which Jekyll does not parse. This means we have to hard-code the entire path and choose whether to have it working locally or live. It is currently set to work live.

This deserves further thinking around how to make this better. There may be a way to move the font file to Sass, which Jekyll does parse and compile.

File in question: https://github.com/18F/dashboard/blob/gh-pages/assets/css/fonts.css

[gboone]

Is this a related problem? I get the following console message about the font file on a local build:

Font from origin 'http://18f.github.io' has been blocked from loading by 
Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' 
header is present on the requested resource. Origin 'http://0.0.0.0:4000' 
is therefore not allowed access. 0.0.0.0/:1

[meiqimichelle]

Probably, since we're currently telling the font file explicitly to load from github.io rather than local.

[gboone]

This is done, right?

[meiqimichelle]

Well, we just gave up on running it locally ;) The code to comment/uncomment if you do want to see it locally is in there tho (if we didn't delete it).

[konklone]

I actually think this is workable -- I believe that CSS references to external files are relative to the location of the CSS file itself. So the CSS should be able to say url(../fonts/18f-font.ttf) and that should work in local, staging, and production, regardless of whether the site is mounted at /dashboard or /.

[meiqimichelle]

Right -- the issue is that the font is on the 18f.gsa.gov repo, not /dashboard. This is related to the 'how to we keep all the subpage styles in sync with main 18f styles if we're running in separate repos' problem.

[meiqimichelle]

Oh, sorry -- I see what you're saying @konklone . Maybe -- we can try!