The provided usage example is bad for accessibility: the name of the icon, e.g. ”check_circle”, will be announced by screen readers. If there is other contextual information that explains the icon, the icon can be hidden from screen readers using aria-hidden=”true”. However, in cases where the icon appears stand-alone, it needs to contain a human-understandable text that explains its meaning.
Also, never use Google’s CDN for loading fonts or icons — always self-host them. The CDNs are used to track your users.
And special-purpose-font/script CDNs don't improve load times any more because browser caches are partitioned by domain nowadays. So using a CDN for fonts or scripts just increases your downtime probability and your GDPR headaches.
I guess it depends on where you're currently hosting your site and if you're using a CDN already. For smaller/private projects, a potential downtime of Google's CDN and GDPR are probably not too much of a concern.
“Check-circle” is exactly the amount of information that the able reader has. Sight-deficient users are as much used to those weird words as able users are used to unintelligible icons.
No. A sighted user can perceive the placement of the icon within its context, e.g. a checked circle within a row in a table, and deduce that it represents confirmation of whatever information the column of the table represents in the context of the row. This information is not available to a screen reader user unless the visually hidden text makes it explicitly available to them.
By the way, your comment shows an ableist bias: an analogous assumption would be that a person who cannot walk is content because they are used to a wheelchair.
If the image stands alone such that sighted users must parse it, then your logic is correct. But if the image is merely decorative due to adjacent text such that sighted users gloss over the image, aria-hidden affords users of screen readers that exact same efficiency instead of wasting their time.
In other words, eyes can skip over decorations without the developer needing to flag them as such, but audio can't auto-skip.
All text being skipped unless the author tags it for inclusion doesn't seem like a failsafe default, assuming that excessive information is generally preferred over insufficient information.
No the reader has "account_balance_wallet" (no dashes). It will read as "account_balance_wallet account balance wallet."
It would be trivially easy to use ARIA attributes to indicate which span is the icon's label. Not something most people consider, but this is Google. At least they have an accessibility icon?
2. Obviously mostly yes, but in hn people just assume that you're a somewhat good person who wouldn't knowingly restraint internet access to people with disabilities
Of course that's up for the developer to decide. You can't force a developer to make a website accessible to all people regarding of their capabilities.
But you have to remember the initial goal of why the Internet started as open and what was the initial goal, to make all information accessible to everyone, that's why accessibility standards were there since the beginning.
That was the entire goal of the web, to be open and accessible to EVERYONE.
But if you want to go full head on capitalism and argue it doesn't matter for business, accessibility is literally search engine optimization, which is great for business. Googlebot is blind and doesn't use a mouse to surf the web.
From any perspective Accessibility is a requirements for any website or web application. Of course, nobody can force developers to make websites accessible.
No - in most western countries it's decided in law that reasonable efforts should be made to support most people, those with disabilities like visual impairment included.
I design websites that are to be used with primarily desktop screens. If you want to use an unsupported configuration such as a tiny screen or with no screen then it is not my fault if it does not work well.
Similarly, if I make a VR game I am not going to design it in a way that makes creating a pancake version of the game easier to use. If someone does create a pancake mod for the game, they should not complain about how weird the controls are or how they can only use one hand. They should take those issues up with the pancake mom developer and not with me. If people find it hard to use my website through a screen reader then they should complain to the screen reader developer to improve it. It's not my fault if there software sucks at what it is trying to do.
> I design websites that are to be used with primarily desktop screens. If you want to use an unsupported configuration such as a tiny screen or with no screen then it is not my fault if it does not work well.
In lots of countries you are obliged to make the site accessible for what you call "unsupported configurations". E.g screen readers, heavily zoomed sites etc. So yes, it will be your fault, and you are liable for what you deliver. If you're a professional web developer, this should be known.
Sure, throw me in jail for not wanting to waste my time developing stuff I have no use for in websites that are freely accessible. If countries want me to develop and support stuff that I don't want to they should pay me for it.
Again, assuming you're a professional that's just part of the job. So you will get paid for it, just include it in the estimates/your quotes. It's not optional. And really, it's not that hard to do..
VR versus pancake typically has nothing to do with disabilities. Display versus screen reader does. It's fine to exclude people who can choose to be included, but it's good to avoid exclusion when choice is not part of the equation.
If you're talking about building something that couldn't possibly be of any use to a blind person, that's one thing, but most websites do not fall into that category.
>VR versus pancake typically has nothing to do with disabilities
Keyboard and mouse as inputs leave you essentially physically disabled. Not having a full range of motion is just an much of a disability as being blind.
No, my response is that your screen reader sucks. For example a bad screen reader might require that an image of an apple has to be labelled apple for it to work, but a good one could just see that image and recognize that it is a picture of an apple.
Ok, and what does that change? Are you gonna invent that software for those people? If it already exists, are you gonna give them a license? All because you didn't feel like spending half an hour thinking about accessibility.
It's not my job to work on your screen reader. Complaints about its effectiveness should go towards the developers of the screen reader software. If everyone's screen leader software sucks then there is likely a business opportunity for someone to make a better one. Also you are trivializing it by saying half an hour. Even if that was true it would be half an hour for every single website in existence. That doesn't scale. What scales is making a better screen reader.
I design websites that are to be used with primarily desktop screens. If you want to use an unsupported configuration such as a tiny screen or with no screen then it is not my fault if it does not work well.
It's good that you're this steadfast in your righteousness. That way you know why so many businesses don't consider hiring you.
I make websites in my free time for fun. I don't find it fun spending time developing and testing for configurations that I won't personally use. I have better things to do in my life than fiddle with CSS.
Seems they have request logs and publish the aggregate statistics. There's no indication of tracking otherwise.
> Google Fonts logs records of the CSS and the font file requests, and access to this data is kept secure. Aggregate usage numbers track how popular font families are, and are published on our analytics page. We use data from Google’s web crawler to detect which websites use Google fonts. This data is published and accessible in the Google Fonts BigQuery database.
Yeah, seconding this. The main benefit of using a Google CDN is that there is a huge chance it's already cached on the client device. Which would mean that there is less useful tracking information.
I would have expected it to work like the fonts, where you only query the things you need, and not everything. For performance reasons I assume people would still make a custom font/SVG set with only the icons they need.
> The icon font weighs in at only 42KB in its smallest woff2 format and 56KB in standard woff format. By comparison, the SVG files compressed with gzip will generally be around 62KB in size, but this can be reduced considerably by compiling only the icons you need into a single SVG file with symbol sprites.
Are Google serious? Simultaneously pushing websites to be highly efficient (Core Web Vitals), at the same time as introducing the methods that can make them less efficient.
Also, about these icons, they mention "please don’t try to sell them", immediately followed by "Apache license 2.0". Well, Google, which is it? Do they actually mean to say "you have permission to sell them, but please don't?"
I don’t care since the icon font approach is technically inferior to SVG icons: it’s monochrome only, whereas SVG supports colors and transparency.
Icon fonts also suffer from a plethora of rendering issues across platforms because fonts are usually rendered with speedy display of long text in mind.
It’s strange Google would invest in a years-old kludge tech.
It's incredible that one of the biggest companies in the world can't manage to appropriately license their stuff.
Apache 2.0 is also a strange license for anything that's not code, too; it refers to "source" and "object" form throughout. I imagine they could've chosen it for license simplicity & compatibility reasons, but again, if they just wanted these to be used as widely as possible, they could've just gone CC0.
All Google is saying is don't scam others by reselling the same stuff that is freely available. Licensing it under something more restrictive (or custom) would make this a non-starter for other companies to reuse or remix.
Not every undesirable behavior can be blocked by firm rules without catching non-problematic behavior. Using a license which that errs on the side of being permissive rather than restrictive at the boundary and using social pressure to try to mitigate undesirable behavior in that boundary area seems a reasonable approach. (True for law, too, and lots of other domains.)
There's some domains where you need to (given that perfect calibration is unattainable) err on the side of being restrictive, but that's definitely not always the right choice.
AFAIK it hasn't "added support". We've used material icons for a year or two now from Google Fonts. Good to see this getting adoption but it's been available for some time
When developing, the fact that icon fonts follow the size and color of the surrounding text is nice, though. E.g. when tweaking the text color of a button.
That SVG does have to be inline though, which drastically increases your HTML page’s size. You cannot style an SVG loaded in an IMG element.
Imagine rendering 50 rows with each 6 icons, 1kb each. There are 6 unique icons, so it’s only 6kb each loading them from the server, but inline you’ll have 300kb of SVG icons
Took me a while to figure it all out, but it works surprisingly well. I have been using https://icomoon.io/ to generate the sprites. They also provide a JS polyfill to support IE.
You can export your SVGs with fill="currentColor" and your color attribute onto the SVG tag or its container would work.
Since at $JOB i'm using SVG icons with more than one color, i use fill="var(--svg-color-base)" or fill="var(--svg-color-accent)" so i can precisely set which color i want, in a perfectly scope-able manner.
The greatest advantage is that you can reference externally your svg with xlink.href on top of your website: you have to make one more request, but it's cacheable. Pick your tradeoff :)
Or something of this manner? Haven't encountered this, but sounds awesome; especially since you'd get the power of both inlining and caching the asset.
Either fill: currentColor or fill: var(--iconColor, currentColor) should do the trick.
I prefer the 2nd one because it lets me change iconColor whenever I find it appropiate
Linux desktop app is free, macOS desktop app costs 9.99 USD (one-time payment), web app costs 9.99 USD / year (no cloud services) or 9.99 USD / month (with cloud services). The complete pricing table is shown in the footer area of the home page when you open it with a Chromium-based browser.
To illustrate an issue this article describes, https://i.imgur.com/TzMXgUd.png is what the linked page looks like with a forced/limited font selection on Firefox.
Raw icon names (that you cannot influence) often don't make a good replacement for proper alt text. Quite often they should not be read out at all. Furthermore, people forcing websites to use a font like OpenDyslexic will see these non-descriptive icon names instead of the real icons.
Just to complement other's responses, accessibility is a spectrum.
We ought to believe someone chooses to use an icon for aesthetics AND usability reasons. If the icon can't be rendered at all, it defeats it's purpose despite it having a "description".
Ultimately, if a well designed, user-friendly system doesn't work the way it's intended to, it is an accessibility issue of some degree. Albeit, some times more trivial than others.
That's not the solution. The solution is adding the correct attributes to the markup. Attributes that are universally recognized and already work with a11y tools.
In this example we'd add an aria-labelledby to the button which references the span with the correct info.
Every single reasons for switching away from icon fonts mentioned in that article is still valid. Icon fonts were already a bad idea in 2016, and they still are a bad idea in 2021.
not true. many design their sites THOUGHTFULLY and as a result they can be accessed without js. case in point: site i,m writing this comment on. counterpoint: almost anything on google.com domain these days.
Something I still find hilarious is that after a product I worked on started to enforce a content security policy, the #1 blocked source was always for google font resources. Of course users could whitelist the domains, but many didn't and anyway their sites looked fine.
where the font is expected to ligate the characters 'f', 'a', 'c', 'e' into a single <face> glyph.
This can be problematic on the web, as it means that if a user doesn't get your webfont for any reason (download failed, browser settings that disable webfonts, accessibility options that override fonts for clarity, etc) the entire word will appear in a fallback font, often totally disrupting the layout. (Can your site adapt nicely to a word, or even an entire phrase -- e.g. "format list bulleted" -- appearing in the toolbar where you expected a single icon?)
In which case the layout may survive, but I expect the "labels" that appear when the icon font fails will be cropped to their first couple of letters or so: not a great fallback in terms of helping the user understand what they're meant to be.
Also, most of the time icons should instead fall back to nothing (and should be hidden from screen readers). The main exception that one will observe in reality is a toolbar of icons only with no labels; it’s well understood in usability circles that that’s a dangerous pattern at best—text labels and icon-and-text labels both almost always simply work better.
I deem the ligature approach bad because it encourages leaving something in the document and accessibility tree that shouldn’t be there, and most commonly in a non-semantic way (e.g. a send button might end up showing something like “paper airplane”, which is terrible, or with this specific font, “Learn more →” might become “Learn more arrow_right_alt”), or with semantics that you’ll definitely break at some point (e.g. report_problem is , but if you use that for an alert icon it’ll mislead anyone that ends up reading report_problem; in short, any new semantics you desire for an icon, you need to create a new ligature for it if the user can possibly ever be exposed to it).
What if instead of trying to destroy the web [1], Google tried to become the very best company for web developers? You know, take a play from Microsoft's "Developers Developers Developers" playbook after it was handed off to Nadella. The hip Microsoft that built VSCode, bought Github, and has the #2 cloud.
Maybe a first class web has "native apps" that work on desktop and Android and don't require an App Store. That might handicap their rival Apple, because writing for web once targets two of the biggest three platforms.
Get "distribution/promotion" through Search. Their ecosystem works, ties together, and makes sense.
If Web wins and Google is #1 at it, then nearly all of their foes lose power. They can sell tools, build a flywheel, moat, all in one. And they wouldn't even have to be assholes anymore. All the cool kids stop hating.
I don't expect their leadership to come up with this grand idea, however. We're just going to get more of the same. More wood behind all the arrows, none of which hit the target and all of which get cancelled in two to five years.
[1] (Chrome, AMP, killing adblock, knee-capping HTML5, ruining semantic standards, making search a hard problem)
Not a fan of how the entire page is squished when clicking on an icon. All the icons get displaced and it's a pain to find where you were in the list...
The real benefit here is that you can export these as SVG. Please do this instead. Icon fonts are convenient, but they're really bad for web performance. It needs to download the entire font even if there's only a handful of icons on a page.
SVGs have excellent browser support, and decent CMS support. You can enable them in Wordpress for example with a little tinkering. If you want to make your site faster (and I hope you do), then definitely consider SVGs.
Good point about DOM size. I wonder if using external SVGs would have had the same effect? I don't know enough about browser rendering to know if that matters.
Semi related but there was a HN post a few weeks back about a tool that would scan your site and then modify the font file to only include the characters or icons you actually used. I still think SVGs are a better option.
This will probably end up left unfinished like Google Fonts’ variable font support.
I don’t understand how they commission high-quality fonts from professional foundries, then turn around and neuter them in the Google Fonts UI – take a look at the family called Commissioner: https://fonts.google.com/specimen/Commissioner
Can you tell from this page that the font contains italics? Or that it has a semi-serif flared-terminal variant? These are additional axes that simply aren’t supported, so there’s no way to know they exist unless you visit the foundry’s GitHub page.
I worked on Google Fonts, and you’d be incredibly surprised how few people run the entire service. If I recall correctly, ether ratio is something like one Google Fonts team member is responsible for the equivalent opt hundreds of millions of requests a day.
The main focus they had in the variable fonts roll out was making the internet faster. The process of choosing when to/not serve variable fonts behind the scenes was oriented around the font-weight axis, so they could reduce the number of requests, and hence speed up everything from Google searches to YouTube and every other website using Google Fonts.
Sadly the UX around displaying axes isn’t straight forward. Since the Google Fonts wants to setup a conservative interface, that doesn’t result in users requesting an entire variable axes with every request, especially when it’s not being used - there needed to be more work than just showing the font’s design space on a specimen page.
There is an incredible amount of behind the scenes effort from an incredibly talented team.
Maybe. They have a Facebook one and a few for some other social platforms. I'm not sure why there isn't one for Twitter and GitHub. I'm not saying there is any strategy going on, it's just interesting to see what is and isn't included in icon sets.
This looks like it was created for Android app developers. Having a single set of most used icons across different apps improves consistency, which will be welcomed by the users.
Wow. I wonder what this means for the future of Font Awesome.
I know plenty of people are anti-Google, and also prefer SVG's over icon fonts for valid reasons (though you can download these as SVG's as well).
But now that this is easier to embed than Font Awesome, has basically the same number/range of icons as Font Awesome's free tier, doesn't come with the 10K pageviews/mo. restriction that Font Awesome's free tier comes with, and so many sites already use Google Fonts for their display and/or body text...
...I'd be very surprised if this doesn't quickly become the new de-facto standard icon font.
Font Awesome’s product has long been destined for commoditization. Which is probably why they have diversified to offering custom icons and other differentiating behavior.
I suspect google won’t be the only one to offer icon sets like this, so in general I agree this will continue to erode FA’s market share.
Fwiw, It has felt like FA’s most recent release fell far behind schedule.
189 comments
[ 3.9 ms ] story [ 234 ms ] threadAlso, never use Google’s CDN for loading fonts or icons — always self-host them. The CDNs are used to track your users.
By the way, your comment shows an ableist bias: an analogous assumption would be that a person who cannot walk is content because they are used to a wheelchair.
In other words, eyes can skip over decorations without the developer needing to flag them as such, but audio can't auto-skip.
It would be trivially easy to use ARIA attributes to indicate which span is the icon's label. Not something most people consider, but this is Google. At least they have an accessibility icon?
Why? It's the screen reader's job to inform users of what's on their screens. It's not my job to give descriptions to things.
>The CDNs are used to track your users.
Do you have any evidence to support this claim?
2. Obviously mostly yes, but in hn people just assume that you're a somewhat good person who wouldn't knowingly restraint internet access to people with disabilities
But you have to remember the initial goal of why the Internet started as open and what was the initial goal, to make all information accessible to everyone, that's why accessibility standards were there since the beginning.
That was the entire goal of the web, to be open and accessible to EVERYONE.
But if you want to go full head on capitalism and argue it doesn't matter for business, accessibility is literally search engine optimization, which is great for business. Googlebot is blind and doesn't use a mouse to surf the web.
From any perspective Accessibility is a requirements for any website or web application. Of course, nobody can force developers to make websites accessible.
Wait, yeah they can:
* https://www.reuters.com/article/us-usa-court-dominos-pizza/u...
Similarly, if I make a VR game I am not going to design it in a way that makes creating a pancake version of the game easier to use. If someone does create a pancake mod for the game, they should not complain about how weird the controls are or how they can only use one hand. They should take those issues up with the pancake mom developer and not with me. If people find it hard to use my website through a screen reader then they should complain to the screen reader developer to improve it. It's not my fault if there software sucks at what it is trying to do.
In lots of countries you are obliged to make the site accessible for what you call "unsupported configurations". E.g screen readers, heavily zoomed sites etc. So yes, it will be your fault, and you are liable for what you deliver. If you're a professional web developer, this should be known.
If you're talking about building something that couldn't possibly be of any use to a blind person, that's one thing, but most websites do not fall into that category.
Keyboard and mouse as inputs leave you essentially physically disabled. Not having a full range of motion is just an much of a disability as being blind.
Response: "It's not my fault you're blind. Ticket closed."
It's good that you're this steadfast in your righteousness. That way you know why so many businesses don't consider hiring you.
Seems they have request logs and publish the aggregate statistics. There's no indication of tracking otherwise.
> Google Fonts logs records of the CSS and the font file requests, and access to this data is kept secure. Aggregate usage numbers track how popular font families are, and are published on our analytics page. We use data from Google’s web crawler to detect which websites use Google fonts. This data is published and accessible in the Google Fonts BigQuery database.
https://developers.google.com/fonts/faq#what_does_using_the_...
Any evidence of this claim? Also, given that the Google CDNs allow caching for 24h, it seems extremely ineffective even if it was done.
https://blog.mozilla.org/security/2021/01/26/supercookie-pro...
Is there evidence of this or is it just your conjecture?
I'm surprised this question was even raised because vector graphics is the most size efficient way to do simple graphics on the web.
> The icon font weighs in at only 42KB in its smallest woff2 format and 56KB in standard woff format. By comparison, the SVG files compressed with gzip will generally be around 62KB in size, but this can be reduced considerably by compiling only the icons you need into a single SVG file with symbol sprites.
So not that large, but I still prefer SVG icons.
Also, about these icons, they mention "please don’t try to sell them", immediately followed by "Apache license 2.0". Well, Google, which is it? Do they actually mean to say "you have permission to sell them, but please don't?"
Icon fonts also suffer from a plethora of rendering issues across platforms because fonts are usually rendered with speedy display of long text in mind.
It’s strange Google would invest in a years-old kludge tech.
Apache 2.0 is also a strange license for anything that's not code, too; it refers to "source" and "object" form throughout. I imagine they could've chosen it for license simplicity & compatibility reasons, but again, if they just wanted these to be used as widely as possible, they could've just gone CC0.
Fonts are code. And very often have a clear source vs. object form.
There's some domains where you need to (given that perfect calibration is unattainable) err on the side of being restrictive, but that's definitely not always the right choice.
At least in my limited frontend experience.
Imagine rendering 50 rows with each 6 icons, 1kb each. There are 6 unique icons, so it’s only 6kb each loading them from the server, but inline you’ll have 300kb of SVG icons
Since at $JOB i'm using SVG icons with more than one color, i use fill="var(--svg-color-base)" or fill="var(--svg-color-accent)" so i can precisely set which color i want, in a perfectly scope-able manner.
The greatest advantage is that you can reference externally your svg with xlink.href on top of your website: you have to make one more request, but it's cacheable. Pick your tradeoff :)
So what you're describing is having site.com/page1 which has markup: <body> <svg id="icon-1"> ... </svg> </body>
and then on site.com/page2 having
<body> <svg> <use href="/page1#icon-1"> </svg> </body>
Or something of this manner? Haven't encountered this, but sounds awesome; especially since you'd get the power of both inlining and caching the asset.
Dora anyone know? I'm not going to sign up for something without knowing what I'm getting into.
Looks like they're using the experimental CSSStyleSheet() constructor [1] to display the pricing table. Ugh.
[1] https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleShe...
https://www.npmjs.com/package/construct-style-sheets-polyfil...
That said, if you have a single page app already, you can render as many icons as you want, since you’ll only download them once anyway.
Using a fresh in stall of Firefox, the linked page displays the icons correctly.
We ought to believe someone chooses to use an icon for aesthetics AND usability reasons. If the icon can't be rendered at all, it defeats it's purpose despite it having a "description".
Ultimately, if a well designed, user-friendly system doesn't work the way it's intended to, it is an accessibility issue of some degree. Albeit, some times more trivial than others.
There are no ARIA attributes that link any of the text to the buttons.
In this example we'd add an aria-labelledby to the button which references the span with the correct info.
I added these lines to uBlock:
Occasionally some icons break on a few sites, but mostly it's plain sailing.thanks
this font is quite small
This can be problematic on the web, as it means that if a user doesn't get your webfont for any reason (download failed, browser settings that disable webfonts, accessibility options that override fonts for clarity, etc) the entire word will appear in a fallback font, often totally disrupting the layout. (Can your site adapt nicely to a word, or even an entire phrase -- e.g. "format list bulleted" -- appearing in the toolbar where you expected a single icon?)
I deem the ligature approach bad because it encourages leaving something in the document and accessibility tree that shouldn’t be there, and most commonly in a non-semantic way (e.g. a send button might end up showing something like “paper airplane”, which is terrible, or with this specific font, “Learn more →” might become “Learn more arrow_right_alt”), or with semantics that you’ll definitely break at some point (e.g. report_problem is , but if you use that for an alert icon it’ll mislead anyone that ends up reading report_problem; in short, any new semantics you desire for an icon, you need to create a new ligature for it if the user can possibly ever be exposed to it).
I've got a wild idea.
What if instead of trying to destroy the web [1], Google tried to become the very best company for web developers? You know, take a play from Microsoft's "Developers Developers Developers" playbook after it was handed off to Nadella. The hip Microsoft that built VSCode, bought Github, and has the #2 cloud.
Maybe a first class web has "native apps" that work on desktop and Android and don't require an App Store. That might handicap their rival Apple, because writing for web once targets two of the biggest three platforms.
Get "distribution/promotion" through Search. Their ecosystem works, ties together, and makes sense.
If Web wins and Google is #1 at it, then nearly all of their foes lose power. They can sell tools, build a flywheel, moat, all in one. And they wouldn't even have to be assholes anymore. All the cool kids stop hating.
I don't expect their leadership to come up with this grand idea, however. We're just going to get more of the same. More wood behind all the arrows, none of which hit the target and all of which get cancelled in two to five years.
[1] (Chrome, AMP, killing adblock, knee-capping HTML5, ruining semantic standards, making search a hard problem)
Did anyone convert them to SVG yet?
SVGs have excellent browser support, and decent CMS support. You can enable them in Wordpress for example with a little tinkering. If you want to make your site faster (and I hope you do), then definitely consider SVGs.
For example, this[0] page loads too slowly on low-end mobile, even though each individual SVG is aggressively optimized to be a tiny file size.
I need to replace them with PNG/WebP. The file sizes would increase, but overall performance would be better (I have tested this).
Now these are illustrations, which are more complex than icons.
0 - https://justtrivia.fun/categories
Use SVGs.
I don’t understand how they commission high-quality fonts from professional foundries, then turn around and neuter them in the Google Fonts UI – take a look at the family called Commissioner: https://fonts.google.com/specimen/Commissioner
Can you tell from this page that the font contains italics? Or that it has a semi-serif flared-terminal variant? These are additional axes that simply aren’t supported, so there’s no way to know they exist unless you visit the foundry’s GitHub page.
I worked on Google Fonts, and you’d be incredibly surprised how few people run the entire service. If I recall correctly, ether ratio is something like one Google Fonts team member is responsible for the equivalent opt hundreds of millions of requests a day.
The main focus they had in the variable fonts roll out was making the internet faster. The process of choosing when to/not serve variable fonts behind the scenes was oriented around the font-weight axis, so they could reduce the number of requests, and hence speed up everything from Google searches to YouTube and every other website using Google Fonts.
Sadly the UX around displaying axes isn’t straight forward. Since the Google Fonts wants to setup a conservative interface, that doesn’t result in users requesting an entire variable axes with every request, especially when it’s not being used - there needed to be more work than just showing the font’s design space on a specimen page.
There is an incredible amount of behind the scenes effort from an incredibly talented team.
Huge props to each of them.
The PNG are all in several subfolders...
What would a generic icon for a tweet be that differs from a "message" icon?
https://material.io/blog/google-fonts-material-icons
Tons of SVG icons from popular packs and using ES6 imports, you only bundle the icons you use.
I know plenty of people are anti-Google, and also prefer SVG's over icon fonts for valid reasons (though you can download these as SVG's as well).
But now that this is easier to embed than Font Awesome, has basically the same number/range of icons as Font Awesome's free tier, doesn't come with the 10K pageviews/mo. restriction that Font Awesome's free tier comes with, and so many sites already use Google Fonts for their display and/or body text...
...I'd be very surprised if this doesn't quickly become the new de-facto standard icon font.
I suspect google won’t be the only one to offer icon sets like this, so in general I agree this will continue to erode FA’s market share.
Fwiw, It has felt like FA’s most recent release fell far behind schedule.