Add Modern Font Stacks

[Jothsa]

Let me know if there's anything else I need to do. I think it might be nice to have an explanation of the benefits of using these props over an external font, but I'm not sure where it would fit. Thanks!

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[argyleink]

Look at all that tucked into nice little props 👍🏻
I do wonder if we need to break these modern font stacks into their own import?

wonder if we should put ^ these behind a summary details so they don't take up so much space? was cool when there were a few, but now there's a lot.

[argyleink]

overall the PR looks great! i've got a couple open questions to consider:

1. are these fonts better as an optional import rather than being part of the default bundle?
2. is the typography documentation section overwhelming now with all the typography example blocks? we could consider using the <details> element OR make a switcher that lets people choose a font prop from a dropdown, which updates an example or all the typography examples
3. how can we give @danklammer and Modern Font Stacks more cred for the values?

i'll pose it to the group in discord and see how folks feel about it

thanks for this, i'm excited about it 🙂

[Jothsa]

Good point about giving them more credit. I think it would also be nice to have some information explaining why people would want to use these over an external font. Maybe that explanation and better credit could be in a paragraph after the "Font Families" heading?

[Jothsa]

I've got finals this week and next week so I won't be able to do much here until after that

[argyleink]

I've got finals this week and next week so I won't be able to do much here until after that

hope finals went well! let us know if you need help closing this out. it's a sweet addition.

[Jothsa]

They did (still waiting for some results though 😶)! Thanks! So sorry for the delay— life’s been coming at me and my ADHD has had me hyperfixating on another project (built with open-props) lol. I’ll get back to this pr soon!

[Jothsa]

I think these fonts would work best as a separate import. However, I think that the font-weights, sizes, etc should remain in the default bundle. Do you think it would be confusing to have the font-families separate from the other font props? Should the font family props be in a separate import, should all the font related props be in a separate import, or should they remain in the main bundle?

[Jothsa]

Alright, I think that's everything except if you want them split into a separate import. Do you want to keep --font-system-ui? It's from modern font stacks, but I think it's unnecessary. It is set to system-ui, sans-serif

[argyleink]

Alright, I think that's everything except if you want them split into a separate import. Do you want to keep --font-system-ui? It's from modern font stacks, but I think it's unnecessary. It is set to system-ui, sans-serif

rad ty! i'm just returning from conferencing and ready to review this. I do think it's a good idea to include that prop as it's often missed by folks and ChromeOS for example doesn't yet support system-ui while it does sans-serif. healthy fallback habit. Thanks for asking!

I'll give this a review now 👍🏻

[argyleink]

looks great! i made 1 little suggestion which i think i can just inject/accept and this is g2g. appreciate the work!

[argyleink]

actually, 1 more comment, as changing these names means i need to make a breaking change release. alternatively, we could keep these same names or just keep the original props, that way it's a minor version bump and no one's apps break.

which is better?

1. keep the previous props in additional to the new ones
2. create vars that map the old names to the most relevant new ones
3. keep the previous props and make the new ones an additional/optional import

i'll toss this into the discord too, see what folks think!

[aslak01]

I think option 1 or 2 is best. I kinda prefer 2 but I appreciate the hesitation to have breaking changes so I'd not complain at either. In my opinion these are small enough that I don't think we need to hide them behind a flag, and I love the idea of having the prototyping power of these well thought out props easily available. Also most people who care about the css weight should probably be using jit.

[Jothsa]

My vote is to map the old props to the new ones and remove them in the next major version. Maybe add a deprecation notice to the doc site?

[mobalti]

I think we should consider the overall approach for introducing new props in the library:

• Should we add them to the main import, as we did with Static Sizes and Drawn Borders? (While they are great, I'm still not convinced they should be in the main bundle.)
• Or should we keep everything as separate imports from now on?

[SanderElias]

I think we should consider the overall approach for introducing new props in the library:

• Should we add them to the main import, as we did with Static Sizes and Drawn Borders? (While they are great, I'm still not convinced they should be in the main bundle.)
• Or should we keep everything as separate imports from now on?

When the added props are entirely new for the current release, they should be imported separately. I fully agree with this.
However, as those in this PR are touching existing stuff, it must be in the main. Otherwise, it would be breaking.
And then, as proposed, fix this in the next version.
I suggest proceeding with the current plan.
For completeness, that is:

• map the old props to the new
• add all into the main import
• add deprecation notice in docs (as needed?)
• move everything into its self-contained import in the next version.

[Jothsa]

I've added the old values and mapped them to the new ones. Will postcss-jit-props be able to handle that correctly? Do you think a deprecation notice is needed?