Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we stop using the Google font service and host on our own? #1307

Closed
danyj opened this issue Nov 7, 2017 · 76 comments
Closed

Should we stop using the Google font service and host on our own? #1307

danyj opened this issue Nov 7, 2017 · 76 comments

Comments

@danyj
Copy link

@danyj danyj commented Nov 7, 2017

I opened a discussion about Montserrat latest unexpected font weight change and get a response from a " Google Fonts collection manager" as he called himself JulietaUla/Montserrat#60 (comment)

to host the font on my own if I wish. So basically we cant rely on Google fonts anymore and you dont care about the drastic changes the font developers make to the fonts we use.

So we can expect that any of them change their font to Comic sans, you would not care and would simply issue an update.

How is this ok ? Why is it that you dont review the changes and advise that the font should be either up versioned on Google font and dont allow the submission if the change is drastic.

Why do you employ people that are actually telling us NOT to use the Google font but rather host it on our own.

@007
Copy link

@007 007 commented Nov 7, 2017

Ref #1294

@serphen
Copy link

@serphen serphen commented Nov 7, 2017

By default fonts.googleapis.com/css is just a pointer to the latest version of the font.
You get the good updates (the ones you like visually), and the bad updates (the ones you don't like visually)

In a similar way <script src="http://code.jquery.com/jquery-latest.js"></script> always points to the latest version of jQuery and may break your website.

If you don't want these updates, you can just point to a specific version (or host your own copy if you don't want to be dependant).

In the case of Montserrat, the links have to be changed to:
v5: Mon, 04 Aug 2014 17:13:17 GMT
v6: Mon, 06 Oct 2014 20:35:53 GMT
v7: Thu, 19 May 2016 23:54:35 GMT
v8: Thu, 26 Jan 2017 20:49:58 GMT
v9: Thu, 26 Jan 2017 22:18:46 GMT
v10: Thu, 09 Feb 2017 01:15:44 GMT
v11: Wed, 11 Oct 2017 18:26:52 GMT
v12: Tue, 07 Nov 2017 15:24:14 GMT

I'm not so sure why the API doesn't support the version selector out of the box ( https://developers.google.com/fonts/docs/getting_started ) or why this is not exposed but this is a good idea.

@danyj
Copy link
Author

@danyj danyj commented Nov 7, 2017

@serphen how do you get the old version on google font ? add query string ( v=11) ?
but the issue is we have a selector that pulls the latest google version

@danyj
Copy link
Author

@danyj danyj commented Nov 8, 2017

@serphen

or host your own copy if you don't want to be dependent

this is not about being dependent , is about not being able to rely on Google fonts and that font devs can do as they please without caring about users.

Google font should be a middle man and make decision if the change is going to impact the users which in this and many other cases no one cared about.

@serphen
Copy link

@serphen serphen commented Nov 8, 2017

I agree with you. As a designer you don't really expect a font to significantly change over time and to break things.

I think it'd be great if the fonts could include version in the URL of the CSS API. Most people don't care, but those who do really do.

At the moment the only way is to set the version directly in the ttf or woff2 link and this is not ideal.

@serphen
Copy link

@serphen serphen commented Nov 8, 2017

At least you can download a specific version from a date in the past if you use my list.

@ghost
Copy link

@ghost ghost commented Nov 8, 2017

This is the second time this year the font weights have changed. It's really irritating because I have to update my code and replace the font-weight with the new ones thats closest to the previous style. JulietaUla/Montserrat#39

@davelab6
Copy link
Member

@davelab6 davelab6 commented Nov 8, 2017

Google font should be a middle man and make decision if the change is going to impact the users which in this and many other cases no one cared about.

I am a Google employee and it is my job to make the final decision about if each update we make is an improvement. I believe that the change to Montserrat Regular made it substantially better as a 'true regular' weight for long-running text.

If the design was totally different then I publish it as a separate family (such as the update made to Exo, which I published as Exo 2); I would not change a design from eg Montserrat to Comic Sans.

Most people don't care, but those who do really do.

And they can self host.

This is exactly right. I appreciate that some people really care to control the version of the fonts that their users see; however, I believe their best approach will be to self-host the fonts.

Most users do not care so much about this, they just want the latest & best version of the fonts.

I'm not so sure why the API doesn't support the version selector out of the box

We want everyone on the latest versions for caching reasons; we have actively considered and rejected the idea of offering version pinning.

At least you can download a specific version from a date in the past if you use my list.

Using the older versions is not a supported feature; please don't do that, if you do, you may experience "unexpected behavior." (Edit: as in these URLs may 404; only the API CSS URLs are supported.)

@danyj
Copy link
Author

@danyj danyj commented Nov 8, 2017

What is this , you covering your .. now , forgot that there are emails responses?
Anyway , this is your original response witch says much about you and the "job" you do wich I am about to forward to few of my friends at G.

screenshot_20

and this smrk on this post shows how professional you are and you are laughing in our faces where we now must spend countless hours to fix your bubu.

JulietaUla/Montserrat#60 (comment)

screenshot_21

. I believe that the change to Montserrat Regular made it substantially better

You believe , well I cold tell you something about that but no one said is better or worse , we all complain becuase it is drastically different and I showed you here

JulietaUla/Montserrat#60 (comment)

the design was totally different then I publish it as a separate family

It is totally different!!!!

Did you not care to compare large and smaller font sizes?

@DanielMcPhee
Copy link

@DanielMcPhee DanielMcPhee commented Nov 8, 2017

the design was totally different then I publish it as a separate family

It is totally different!!!!

Agreed.

@kizu
Copy link

@kizu kizu commented Nov 8, 2017

@davelab6

We want everyone on the latest versions for caching reasons; we have actively considered and rejected the idea of offering version pinning.

You can, and should embrace semver then and provide the fonts with the fixed major version and not fixed minor and patch. Most of the changes would often go into the minor versions then, and as users would get the updates for those, there wouldn't be any cache problems.

But making a change like mentioned in this and other issues is a major one. The weight is a public API of a font, and you've just changed it in a way it broke a lot of things for people. While I'd agree that this change shouldn't be published as a new family, with semver (and fixed major versions) you could do just increment the major version. That's why semver exists — because it provides a safe way to introduce breaking changes.

@esistgut
Copy link

@esistgut esistgut commented Nov 8, 2017

I'm here to report my experience with this change: we develop Angular frontends for specific e-commerce services and we deploy the same frontends to a large group of customers in a multi-tenant fashion. The font update totally destroyed every single installation. Version numbers exists for a reason, if you don't support the selection of the version you should avoid major breaking changes like this.
This is comparable to the leaf-pad npm disaster: left-pad/left-pad#4
Why a font designer should be given the power to manage a system-admin/developer/devops task like this one?

@NickvdMeij
Copy link

@NickvdMeij NickvdMeij commented Nov 8, 2017

IMO, if a version is published it should never be changed in any way possible. If there is a change, a new version should be released, instead of the old version being updated. Like @danyj proposed, a version query string in the URL would work perfectly.

We want everyone on the latest versions for caching reasons; we have actively considered and rejected the idea of offering version pinning.

@davelab6 IMO this is not a good argument. You can cache all specific version the same way you cache the fonts currently. If you can't, you might reconsider your design.
Sure, it would impact the performance a little since you increase the number of fonts available, but I can't imagine that everything breaks apart if you implement this... Furthermore, most people would probably use the latest version anyways.

PLEASE, listen to the crowd and implement versioning because things get really, REALLY bad and you got thousands of people complaining...

@sbrandwoo
Copy link

@sbrandwoo sbrandwoo commented Nov 8, 2017

Most users do not care so much about this, they just want the latest & best version of the fonts.

@davelab6 I would challenge this assumption. As a developer it's very important that changes can't happen to my web applications without me knowing.

If I am downloading a brand new font, then yes I want latest and greatest. But once I've deployed to production I don't want the site to arbitrarily break and require somebody to notice, fix, test and redeploy.

I believe the "users" in this situation are the developers and designers looking for a reliable online font hosting platform, which Google Fonts provides - making breaking changes to fonts removes this reliability.

I would ask - how do Google Fonts recommend we use their service? Are other fonts likely to change in the future? Is self-hosting the only option for long-living production applications?

@dreadedhamish
Copy link

@dreadedhamish dreadedhamish commented Nov 8, 2017

If the design was totally different

What is your definition of totally different? How about the appearance of thousands of sites? They look totally different now.

Please change it back and roll out a v2.

@nicolasmlv
Copy link

@nicolasmlv nicolasmlv commented Nov 8, 2017

You should add on the migration guide that the font-size are also modified.

So if you have font-weight: 400; font-size:14px;, you should modify it to font-weight: 500; font-size: 13px;

@PierBover
Copy link

@PierBover PierBover commented Nov 8, 2017

I believe that the change to Montserrat Regular made it substantially better as a 'true regular' weight for long-running text.

I know this pissed off a lot of people, but I agree with @davelab6 . Before, Monserrat at regular looked like medium, even almost bold, and this is something wrong that had to be fixed.

It's totally fair to be annoyed by having to change your CSS unexpectedly, but those that claim the change makes websites look "totally different" are blowing this out of proportion. Designers notice these details, but most users don't.

@danyj
Copy link
Author

@danyj danyj commented Nov 8, 2017

medium, even almost bold, and this is something wrong that had to be fixed

not a problem , we also like it , no one is arguing about the quality , but there should have been v2 issued since the new font is drastically different from the previous version and has broken many websites intended design.

@danyj
Copy link
Author

@danyj danyj commented Nov 8, 2017

are blowing this out of proportion.

is this out of proportion? left is old , right is new, new weights are almost half of what they were

screenshot_19

@PierBover
Copy link

@PierBover PierBover commented Nov 8, 2017

is this out of proportion? left is old , right is new

Most users (non designers) won't see the difference unless you point it to them.

@danyj
Copy link
Author

@danyj danyj commented Nov 8, 2017

please understand , the left project is for sneakers shop , intended to be bold and stick out , now it looks like it was designed for lingerie shop , sexy and thin.

@bhartvigsen
Copy link

@bhartvigsen bhartvigsen commented Nov 8, 2017

Using the older versions is not a supported feature; please don't do that, if you do, you may experience "unexpected behavior."

What? This doesn't even make sense. You prompted "unexpected behavior" by changing around people's fonts..

@esistgut
Copy link

@esistgut esistgut commented Nov 8, 2017

Most users (non designers) won't see the difference unless you point it to them.

Users are not supposed to notice the difference. Users are not even supposed to notice the change if I replace the font with Comic Sans. But they will experience an harder reading experience because this change makes the font less visible, and some of them will leave the site if I don't change something to adjust for the change. Of course this is, as most design and UX changes, something users will never talk directly about, they will just leave the site.

@PierBover
Copy link

@PierBover PierBover commented Nov 8, 2017

But they will experience an harder reading experience because this change makes the font less visible

@esistgut ¿Can you post an example of text being hard to read because of this change with a before/after?

@esistgut
Copy link

@esistgut esistgut commented Nov 8, 2017

Montserrat v11:
Montserrat v11

Montserrat v12:
Montserrat v12

Of course this does not make it "hard to read", it makes it "harder to read". But this is not the point here, the point is: who should make the decision?
And I have another doubt about this: does the use of Google Fonts affect SEO even in some very limited way? Should we decide to self-host will we experience an impact (how little it would be is not really relevant) on rankings because of page loading speed?
This whole story is beginning to look like this: "you can either choose to give us absolute power on your fonts or you will pay a price on search engines optimizations".
EDIT: Maybe the last part is not relevant to the issue, feel free to ignore it.

@esistgut
Copy link

@esistgut esistgut commented Nov 8, 2017

@danyj
Copy link
Author

@danyj danyj commented Nov 8, 2017

@esistgut thnx for this comparison , v12 looks like pressed from above, plain ugly now

@davelab6
Copy link
Member

@davelab6 davelab6 commented Nov 10, 2017

Here's a zoom on @m4rc1e 's "Desktop Windows 7 IE 11"

Before
google chromescreensnapz001

After
previewscreensnapz001

GIF
out

In the u the x height change is not visible at all

@davelab6
Copy link
Member

@davelab6 davelab6 commented Nov 10, 2017

The video shows that font is now stretching on odd number instead

Hmm. Thanks for your patient explanation - I'll discuss this with @m4rc1e and @juandelperal :)

@danyj
Copy link
Author

@danyj danyj commented Nov 10, 2017

Since you are testing can you please try px values , not pt , since I think that is why we see the bugs .

@ultrasquid
Copy link

@ultrasquid ultrasquid commented Nov 10, 2017

@horaceleung
Copy link

@horaceleung horaceleung commented Nov 10, 2017

and the new version be hosted with a different name,

Agree.. should have called it "New-Montserrat" !

@paulphin
Copy link

@paulphin paulphin commented Nov 10, 2017

Yeah, this has caused us a lot of headache. First - just trying to figure out what happened because we noticed right away but had no clue that google changing the font could be a possibility.

All of our page titles are much thinner and look smaller.

I suppose I should try to download an older version and self host.

@davelab6
Copy link
Member

@davelab6 davelab6 commented Nov 10, 2017

It would seem the proper thing to do when global design changes such as this are applied to a font that the previous version continue to be hosted, and the new version be hosted with a different name, even just appending "-New" or equivalent to the name.

We would have 12 Montserrats at this point, and continue to have more; publishing all 12 as separate families would be slow (less cache hits) and complex (most users don't know or case about versioning and just want the latest & greatest; some of the complexity can be mitigate with good UX.)

Google Fonts aspires to make web fonts fast, easy, and free. Free means not only $0 but also as in "living free," and everyone is free to self-host the fonts if you want to have total control.

All of our page titles are much thinner and look smaller.

I suppose I should try to download an older version and self host.

I recommend using the Medium (500) weight of the latest version, rather than a buggy older version. There are benefits to using 3rd party hosting services like the Google Fonts API, but total control is not one of them.

The designers of Montserrat make the 500 close to the older 400 in order to make the upgrade smoother for people.

@kizu
Copy link

@kizu kizu commented Nov 10, 2017

@davelab6 that's why you should embrace semver. Imagine code CDNs not having versioning and only giving users the latest version of all the libraries and frameworks. How good for caching it would be, wow! Such speed! Much fast!

And then when a major update that broke all the APIs would be there, you could discard any complains with “lol, CDN is free for you, self host”.

It is really regressive not to use proper versioning at Google Fonts. That already break some stuff and I guarantee, as things are now, it could break things more in the future.

@danyj
Copy link
Author

@danyj danyj commented Nov 10, 2017

@davelab6 I am doing my best to understand both sides but you are choosing to ignore the issues so many of us have reported

Free means not only $0

free does not give anyone the right to mess up so many websites

I recommend using the Medium (500)

according to this now all designers should come to google for advice what font weights to use in their designs

than a buggy older version

if it was buggy why did you approve it 9 months ago ? , why did you let us work with it , get used to it , make thousands of websites with it?

this has made such a stir for all of us involved and it was and still is a very easy fix, v2

@davelab6
Copy link
Member

@davelab6 davelab6 commented Nov 10, 2017

@davelab6 that's why you should embrace semver.

I recommend SemVer to designers for their internal font version keeping -https://github.com/googlefonts/gf-docs/blob/master/ProjectChecklist.md#versioning - although there are some caveats due to the nature of the OpenType font format.

However, the numbering of the font internals are not the same as the numbering of font updates on the Google Fonts API; many of the updates designers make don't effect visual output - fixing a bug in just 1 glyph, or adding new glyphs - and some of the API update are by Google Fonts, not the designers, where we make changes to the way the fonts are encoded to make them even faster (eg WOFF2.)

Imagine code CDNs not having versioning and only giving users the latest version of all the libraries and frameworks. How good for caching it would be, wow! Such speed! Much fast!

And then when a major update that broke all the APIs would be there, you could discard any complains with “lol, CDN is free for you, self host”.

It is really regressive not to use proper versioning at Google Fonts. That already break some stuff and I guarantee, as things are now, it could break things more in the future.

Initially (in 2010) we always onboarded single-style fonts as a 400 Regular -
eg https://fonts.google.com/specimen/Lobster was part of the initial launch collection.

When I joined in late 2011, I began onboarding fonts that were not a "true regular" in the 1 of the 18 weight slots that they "truly" belonged in - eg https://fonts.google.com/specimen/UnifrakturCook is slotted as 700 Bold and https://fonts.google.com/specimen/Buda is slotted as 300 Light.

But this broke both systems that assume all font families have a 400 Regular, and it was confusing for users where https://fonts.googleapis.com/css?family=UnifrakturCook:700 works but https://fonts.googleapis.com/css?family=UnifrakturCook does not work.

So we decided to go back to on-boarding everything as a "400 Regular", and we did publish some "v2" families, eg https://fonts.google.com/selection?selection.family=Lobster|Lobster+Two:700i and https://fonts.google.com/selection?selection.family=Shadows+Into+Light|Shadows+Into+Light+Two

When Roboto was redrawn, we decided to not publish that as "Roboto 2" but to update Roboto in place, because we don't want users to have to review all the versions and decide which is the right one to use.

We want to keep things simple.

So, almost always our updates aren't noticed by anyone, and in a few cases in the last year or two we have pushed updates that "reset" the 400 Regular style to be "true." There are trade offs with each approach to the problem, and we've decided this is the best way forwards.

if it was buggy why did you approve it 9 months ago?

Many hundreds of the fonts available in Google Fonts are "minimum viable products," so their quality ought to be improved over time, iteratively. We took that approach because we can update the fonts and bring everyone to the latest versions; we know this is radically different to traditional foundries, which have a print media culture, where they do not release fonts until they are "perfect" and then rarely change them because you can't update a printed document after it is published.

@kizu
Copy link

@kizu kizu commented Nov 10, 2017

because we don't want users to have to review all the versions and decide which is the right one to use.

That's not how the versioning systems work! You always can provide users with the latest version when they come to get it, but at the same time ensure that they would have that exact version (with only fixes or non-breaking updates like adding new symbols without redoing old ones) delivered automatically. The system shouldn't make users to choose the font they want to install unless they know what are they doing. Look at npm, for example: when you do npm install … you get just that: you get the latest version. But you won't get the breaking updates! That's what is entirely possible to implement for google fonts, and any cache issues would be unexistent as the major versions of fonts that break previous convencions is not something that happens a lot (hopefully).

@paulphin
Copy link

@paulphin paulphin commented Nov 10, 2017

@davelab6

We're already on 500. And honestly, after going through a few months ago and changing title font size and weight and getting it just perfect - this isn't what I want to be doing again.

It doesn't matter that it was "buggy", it's what we were using when designing, and what we felt like we perfected on our site.

I was unaware that google fonts is bleeding edge.

We'll look for another solution.

Thanks.

@davelab6
Copy link
Member

@davelab6 davelab6 commented Nov 10, 2017

@kizu,

That's not how the versioning systems work!

This is the case where there are no other engineering changes to the API's features, which is what some people are saying - they would prefer to see two families in Google Fonts, Montserrat (as it was) and Montserrat 2 (as it is today) where there are very small differences in the 100s and 900s, and the 400s and 500s are very close, but the 400 vs 400 has this change.

Of course a more sophisticated versioning feature might not present the "analysis paralysis" that we are wary of, such as a &semver=1.234 on the API URL that does what you expect, but the GF team doesn't currently plan to add this.

However, we appreciate everyone sharing their thoughts here, and when we review our roadmap I'll make sure this decision continues to be revisited.

People choose to rely on Google Fonts to take care of all the minutia of web fonts, and we currently believe auto-upgrading all users to the latest versions, that have improved quality and bug fixes, is the responsible thing to do, even if it introduces visual changes.

@paulphin,

We'll look for another solution

Cool - if you want control over updates, self-hosting is the best solution :)

I hear people saying that a recommendation to self-host is contradictory with the recommendation to use the Google Fonts API, but there are popular npm packages for these libre fonts which make self-hosting easy to manage; at a high level Google Fonts team wants web fonts overall to be successful, not only the API itself, which is part of the motivation to make the fonts fully libre instead of merely gratis.

Great things can come from self-hosting and taking full advantage of the fonts' licensing: When Gawker/Gizmodo wanted to adopt Merriweather, they decided to redesign the ? and quote marks, and renamed their version Elizabeth. Those changes have been taken by Merriweather's designer into the latest version as a OpenType Stylistic Set.

@IamManchanda
Copy link

@IamManchanda IamManchanda commented Nov 16, 2017

@davelab6 I would dare to say that one option could be google buying a separate domain, host it separately and with a different CDN (non google)
and host version specific font there!

Rest of service should be like before :)

@bhartvigsen
Copy link

@bhartvigsen bhartvigsen commented Nov 16, 2017

I think it's clear that the lesson to be learned is that nobody should be entrusting Google with any part of their infrastructure, no matter how small. From abruptly terminating services that folks have come to depend on, to anti-trust moves like firewalling email on GCE so that customers are forced to pay Google rather than use their own Exchange, to recklessly screwing around with layouts on millions of sites without so much as a warning, there are countless examples of this sort of behavior from Google. At this point I think Google has made its message clear and it's up to the development community to heed their activities as dangerous, anticompetitive, and not to be trusted with even the smallest piece of your company infrastructure. Fool me once, shame on you, fool me twice, uhh you can't get fooled again..

@iparr
Copy link

@iparr iparr commented Nov 16, 2017

This is a little frustrating. It's not as simple as "just re-host". I'm finding that if I self host the old version of the font, rather take it from Google, then my .woff2 downloads have risen from ~13KB per variant to ~62KB.

I'm not entirely sure what to do about this.

@paulphin
Copy link

@paulphin paulphin commented Nov 16, 2017

It is, I agree. I'm still trying to figure it out. I haven't touched the fonts on our site since the change even though they're way too thin (it also messed up formatting in a few places) - don't want to make extra work if we're going to self-host.

@davelab6
Copy link
Member

@davelab6 davelab6 commented Nov 16, 2017

@danyj
Copy link
Author

@danyj danyj commented Nov 16, 2017

@davelab6 , can you promise us that these weight will last or that you will do the best you can to protect us in case next such change comes around. Meaning that if dev issues another weight change in few months will you than go for v2 ?

@davelab6
Copy link
Member

@davelab6 davelab6 commented Nov 19, 2017

It is extremely unlikely that you'll see a "Montserrat 2" family published on Google Fonts. I can offer that I'm overseeing the development of much better update review tools, so that the GF team, font designers, and GF font-engineering contactors who bridge the two, can more closely evaluate updates; and I will do more to announce to the engaged community when updates are soon to happen - both in this issue tracker and on the GF Twitter.

It gives me no pleasure in you all being annoyed, but given the product values, GF will not offer version pinning, so if you want control, you'll need to self host (or, contribute to brick.im or other font hosting services that have different product values and thus offer pinning :)

@ghost
Copy link

@ghost ghost commented Mar 26, 2018

Reading all of this, then I'm truly amazed that you're still employed at Google @davelab6, any change to a font, regardless of how small it is, is a major one.

Do you imagine these changes flying by as easily as you're trying to make it if the change occurred on Google.com? You're extremely ignorant.

Google Fonts is supposed to simplify things, this attitude is making it complicated. You change the font as is to a new version thinking the change is minor and insignificant, but when you do it repeatedly, and always use the latest font to compare, then in the end, the latest font is completely different then first, original font.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests