Ensure all families have regular:400 styles about fonts

[rsheeter]

As this reproduces with Google Fonts without the webfont loader I'd say this is the right place. Thank you for the report.

[davelab6]

The Google Fonts API doesn't support the FVD syntax in any way, but it has a default response.

If you look at the contents of http://fonts.googleapis.com/css?family=Open+Sans:i5 then you see only the i4 is returned; anything without an i (http://fonts.googleapis.com/css?family=Open+Sans:whatever) returns the r4.

these font URL's resulted in 404's

They don't have regular:400 styles, and they ought to :) When a family only supports non 400 weights, the weight needs to be specified.

[mrbinky3000]

@davelab6 and @rsheeter Thanks for looking into the 404 issue! I didn't notice that FVD just returned the n4 version of each font. Any chance that might get supported in the future?

[davelab6]

My personal opinion is that any secondary CSS API syntax is unlikely to be supported, because it would mean reducing the maximal caching that comes with a single primary syntax. However, I'm personally curious to better understand your motivation for using the FVD syntax. Why is this syntax better? :)

[mrbinky3000]

Unless I'm missing something, I don't think this would alter caching? Google responds with a css file that contains a @font-face definition which, in turn, contains src url's to the font. Calling https://fonts.googleapis.com/css?family=Buda:n3 shouldn't change what's declared in the CSS that I know of (but I really don't know how that random string used for the font src is generated)

FVD is just a nice format that I thought TypeKit and Google worked on together? It's supposed to be "A way to unambiguously, compactly and clearly describe a set of @font-face properties." But above all that, it's less characters and I'm a lazy typist. :-)

[rsheeter]

WRT caching, if you visit site 1 that uses family=Buda:n3 and site 2 that uses family=Buda:300 you would produce a cache miss for the CSS even if the font file got a cache hit. Accordingly, we do not currently intend to support FVD in the /css API (unless a presently unknown compelling reason emerges I suppose).

[davelab6]

it's less characters and I'm a lazy typist

I can recommend tools like https://github.com/tekezo/Karabiner (mac) and https://github.com/AutoHotkey/AutoHotkey (windows) for helping with that :)

[mrbinky3000]

Again, I don't think you're taking a caching hit. The CSS file returned by Google is only 4 lines of text per font returned. That's only about 200 bytes per font. That CSS file contains a src css attribute that points to another URL (like to a woff2 file). If that src URL is the same for FVD and non FVD, then the font is still cached. I don't know how that FVD url is generated though. Perhaps you would have better insight into that.

So, every call to a Google web font font results in two queries. The first is very tiny, the second contains the font file itself.

On another note: Karabiner looks cool :-)

[davelab6]

I don't think you're taking a caching hit

I guess that it can seem odd to want to avoid losing the caching of the css :) I hope you'll find this more reasonable if you consider the scale of Google Fonts; at http://www.google.com/fonts#Analytics:total you can see that the single most popular family, Open Sans, has a CSS request served by Google Fonts API 17,789,030,914 times a week, or 2,541,290,131 times per day. So these very tiny pieces of CSS add up, and caching them is important for making web fonts as fast as possible :)

[davelab6]

BTW, over in typekit/fvd#6 (comment) Bram says typekit is moving away from fvd.