First-party fonts support #1033
Replies: 14 comments 31 replies
-
|
Love the idea of this! I always use I would actually love something like the Image API, where it will download and optimise remote fonts into a local, self-hosted font! |
Beta Was this translation helpful? Give feedback.
-
|
This is the plan! I have a POC that caches fonts on demand (or on build). I didn't want to get too much into the details since it's only a Stage 1 RFC ;) |
Beta Was this translation helpful? Give feedback.
-
I think there should be some TS support or a way to prevent the user from using the wrong font! |
Beta Was this translation helpful? Give feedback.
-
|
Yes! There's a runtime check in my current implementation but we need to see if stuff can be done at the type level using codegen |
Beta Was this translation helpful? Give feedback.
-
I feel like this should be one of the responsibilities of the proposed provider function. I.e. the provider should also have a list of all available fonts, which should make it possible to generate a type for the font name property. |
Beta Was this translation helpful? Give feedback.
-
|
Getting my usual comment, please make it runtime agnostic, it should e.g. work on Cloudflare without any compatibility flag. |
Beta Was this translation helpful? Give feedback.
-
|
My current POC should work on cloudflare, we can discuss the details on the stage 2 rfc |
Beta Was this translation helpful? Give feedback.
-
|
Some previous discussion is here #106 |
Beta Was this translation helpful? Give feedback.
-
|
Could this support automatic subsetting? https://amberwilson.co.uk/learn/font-subsetting/ |
Beta Was this translation helpful? Give feedback.
-
|
I don't think it will be automatic, but rather an option in the astro config per family |
Beta Was this translation helpful? Give feedback.
-
|
Of course - having it be an option would be really nice. It would need some strategy, I imagine configurable/pluggable, to determine what glyphs to include. |
Beta Was this translation helpful? Give feedback.
-
|
Why implement the Nuxt version instead of the Next version? |
Beta Was this translation helpful? Give feedback.
-
|
Nuxt version is vite based (just like Astro) and is runtime agnostic. Next.js version downloads stuff at runtime which doesn't work on Cloudflare. I also like its API less |
Beta Was this translation helpful? Give feedback.
-
Good reasons |
Beta Was this translation helpful? Give feedback.
-
|
Will I get the option to keep the font's like Nuxt fonts does? |
Beta Was this translation helpful? Give feedback.
-
|
Have an example/link? |
Beta Was this translation helpful? Give feedback.
-
|
Big fan of this. Return of the |
Beta Was this translation helpful? Give feedback.
-
|
I like nuxt fonts defaults option: we can provide sensible defaults and make those properties optional on families (eg. only weight 400 by default) |
Beta Was this translation helpful? Give feedback.
-
|
Nuxt detects the font in CSS, which is pretty impressive. |
Beta Was this translation helpful? Give feedback.
-
|
Zach has a brilliant article for fonts and rendering them. Since the |
Beta Was this translation helpful? Give feedback.
-
|
We'll probably use https://github.com/unjs/unifont now that it's finally public! The timing is perfect and it was not even made on purpose |
Beta Was this translation helpful? Give feedback.
-
I was about to recommend that. Nice to see you watching Vite Conf |
Beta Was this translation helpful? Give feedback.
-
|
I feel a bit uneasy to use a library that was just announced. How production ready is it? |
Beta Was this translation helpful? Give feedback.
-
|
I think it's good, or it will be by the time I start working on the actual code. FYI the providers are extracted from the nuxt/fonts module, and Daniel Roe will be working on reworking nuxt/fonts to use unifont. That will also be a great opportunity to see how it's done and contribute fixes upstream IMO |
Beta Was this translation helpful? Give feedback.
-
|
PR at nuxt/fonts#315 |
Beta Was this translation helpful? Give feedback.
-
|
I like this too. I also share some concerns that it's a little verbose. Do we need a I also wonder if the |
Beta Was this translation helpful? Give feedback.
-
|
I think that could look like so export default defineConfig({
fonts: {
local: {
directories: ['./custom'] // defaults to ['./<srcDir>/assets/fonts'] or whatever
},
// that would be the actual default value but you get the idea
defaults: {
provider: 'google',
weights: [400]
// ...
},
providers: [adobe({ apiKey: "" })],
families: [
{
name: "Roboto"
},
{
name: "Inter",
provider: "local"
},
]
}
}) |
Beta Was this translation helpful? Give feedback.
-
|
It would be nice if there was a shorthand syntax where it could be something like: families: [
"Roboto",
"Lobster",
{
name: "Inter",
weights: [800]
},
]Could it default to checking each of the providers to find a font when the provider hasn't been specified? |
Beta Was this translation helpful? Give feedback.
-
|
I'm fine with the shorthand syntax, although I think in practice you'll likely tweak each font.
Is there a benefit over only using the default provider? (and vice versa) |
Beta Was this translation helpful? Give feedback.
-
|
The proposed options shape feel too large to me. I think we should:
The final shape will look like this: fonts: {
families: ['Inter']
}Or even better, it could look like: {
fonts: ['Inter']
} |
Beta Was this translation helpful? Give feedback.
-
|
I have mixed feelings about that but I'll share more on the Stage 2 RFC |
Beta Was this translation helpful? Give feedback.
-
|
Super excited to see this go live! I wonder how are we planning to support ssr first environments? If we are able to bundle the font in a SSR first project, that'd be ideal I think. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think we'll support such usecase. The goal is to handle fonts at build time, because that's the most efficient way and it's runtime agnostic. If people want to do more runtime things (eg. a font name that comes from a DB), they'll have to use something else. I think this usecase is rare enough so we don't need to care about it in core. To be clear, SSR users will still be able to use the fonts feature of Astro, just not use that for runtime usage |
Beta Was this translation helpful? Give feedback.
-
|
So to confirm: the |
Beta Was this translation helpful? Give feedback.
-
|
Yes |
Beta Was this translation helpful? Give feedback.
-
|
I like this idea! What would be the purpose of having a |
Beta Was this translation helpful? Give feedback.
-
|
2 reasons:
|
Beta Was this translation helpful? Give feedback.
-
|
Makes sense! |
Beta Was this translation helpful? Give feedback.
-
|
That's great idea. I hope that it will fully-support SSR as well. |
Beta Was this translation helpful? Give feedback.
-
|
See the thread at #1033 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Proposal moved to Stage 2! #1037 |
Beta Was this translation helpful? Give feedback.
-
Body
Summary
Have first-party support for fonts in Astro.
Background & Motivation
Fonts is one of those basic things when making a website, but also an annoying one to deal with. Should I just use a link to a remote font? Or download it locally? How should I handle preloads then?
The goal is to improve the DX around using fonts in Astro.
Fontsource is great! But it's not intuitive to preload, and more importantly, doesn't have all fonts. The goal is to have a more generic API for fonts (eg. you want to use a paid provider like adobe).
Goals
Example
This RFC is highly inspired from https://github.com/nuxt/fonts and https://github.com/rishi-raj-jain/astro-font.
A new
fontsobject would be available on the astro config:We could register providers:
And specify font families:
We could then use a
Fontcomponent and place it in the head:Then specify the font family (we may provide a css variable):
Beta Was this translation helpful? Give feedback.
All reactions