Should we stop using the Google font service and host on our own? #1307
Comments
|
Ref #1294 |
|
By default fonts.googleapis.com/css is just a pointer to the latest version of the font. 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: 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. |
|
@serphen how do you get the old version on google font ? add query string ( v=11) ? |
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. |
|
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. |
|
At least you can download a specific version from a date in the past if you use my list. |
|
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 |
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.
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.
We want everyone on the latest versions for caching reasons; we have actively considered and rejected the idea of offering version pinning.
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.) |
|
What is this , you covering your .. now , forgot that there are emails responses?
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)
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)
It is totally different!!!! Did you not care to compare large and smaller font sizes? |
Agreed. |
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. |
|
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. |
|
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.
@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. PLEASE, listen to the crowd and implement versioning because things get really, REALLY bad and you got thousands of people complaining... |
@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? |
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. |
|
You should add on the migration guide that the font-size are also modified. So if you have |
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. |
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. |
is this out of proportion? left is old , right is new, new weights are almost half of what they were
|
Most users (non designers) won't see the difference unless you point it to them. |
|
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. |
What? This doesn't even make sense. You prompted "unexpected behavior" by changing around people's fonts.. |
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. |
@esistgut ¿Can you post an example of text being hard to read because of this change with a before/after? |
|
Montserrat v11: 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? |
|
Linked HN discussion: https://news.ycombinator.com/item?id=15651320 |
|
@esistgut thnx for this comparison , v12 looks like pressed from above, plain ugly now |
|
Since you are testing can you please try px values , not pt , since I think that is why we see the bugs . |
|
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. There should be some alert that the
designer doesn't want to further update the previous version, if that
should be the case.
…On Thu, Nov 9, 2017 at 4:22 PM, Dan ***@***.***> wrote:
Since you are testing can you please try px values , not pt , since I
think that is why we see the bugs .
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1307 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABtEiZRTxj8CRaoauEMKYnBqLPnhqGquks5s05dcgaJpZM4QVhNU>
.
--
--
Jason Pagura
zimbach at gmail dot com
|
Agree.. should have called it "New-Montserrat" ! |
|
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. |
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.
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. |
|
@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. |
|
@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 does not give anyone the right to mess up so many websites
according to this now all designers should come to google for advice what font weights to use in their designs
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 |
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.)
Initially (in 2010) we always onboarded single-style fonts as a 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 But this broke both systems that assume all font families have a 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
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. |
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 |
|
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. |
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, Of course a more sophisticated versioning feature might not present the "analysis paralysis" that we are wary of, such as a 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.
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 |
|
@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) Rest of service should be like before :) |
|
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.. |
|
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. |
|
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. |
|
If you want to use the Google Fonts API hosted version of Monserrat, and
have the same weight as the 400 was last month, use the 500 weight.
…On Nov 16, 2017 11:15 AM, "paulphin" ***@***.***> wrote:
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1307 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAP9y9U8I6tbd8CjCdsRT79RaSWIg5Eyks5s3F8tgaJpZM4QVhNU>
.
|
|
@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 ? |
|
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 :) |
|
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. |
and others
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.
The text was updated successfully, but these errors were encountered: