-
Notifications
You must be signed in to change notification settings - Fork 42
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
Update font-stack in design tokens #136
Conversation
- replaced `Segoe UI Display/Text` with `Segoe UI` - added `Roboto, Helvetica, Arial, sans-serif` to the `sans` block - added explicit emoji support for `Display/Text` - added `Menlo` to `Code`
This pull request is being automatically deployed with Vercel (learn more). hds-flight-website โ ./๐ Inspect: https://vercel.com/hashicorp/hds-flight-website/B7MqaevS3u6NWERJdJeLq9CxUZpc hds-components โ ./๐ Inspect: https://vercel.com/hashicorp/hds-components/EHTgbQR26yJiPioHn2fj7TWK4EQK |
๐ฆ Changeset detectedLatest commit: e8a860c The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
- replaced `SF Mono` with `ui-monospace` (itโs the only way to access โSF Monoโ on Mac via CSS, see here https://qwtel.com/posts/software/the-monospaced-system-ui-css-font-stack/#:~:text=worth%20expanding%20on%3A-,ui%2Dmonospace,-Future%20system%20monospace; notice it works only for Safari (https://caniuse.com/extended-system-fonts)
[question] does design need to sign off on this decision? |
I prefer to have a second eye on this (expecially considered that @heatherlarsen has a good eye for details, and background as front-end developer too) :) |
Was doing a bit of research on this as the list is getting pretty lengthy and wanted to share an article I found about GitHub's explorations with font stacks. This article is a bit dated, but it's still linked on the Primer website, so seems relevant. I specifically wanted to note that GitHub originally started by including Thankfully we're not including that full list, but what do you think about removing Also wondering if we need to specifically call out "SF Pro Display" and "SF Pro Text"? I may be misinterpreting this, but it seems like we may be able to just rely on |
- โSF Pro Display/Textโ was useless, `-apple-system, BlinkMacSystemFont` already do the job - โUbuntuโ and โRobotoโ can cause issues (see this https://markdotto.com/2018/02/07/github-system-fonts/)
@heatherlarsen I have updated the font stack according to your suggestions, they all make sense. As it is now, our font stack will be almost identical to the one in GitHub, so we should be confidently safe enough :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me! โจ It'll be awesome to use these in DevDot. ๐
@heatherlarsen if you can have a last look and give me thumbs up, I can merge and release these changes |
--token-typography-font-stack-text: -apple-system, BlinkMacSystemFont, SF Pro Text, Segoe UI Text, Ubuntu, sans-serif; | ||
--token-typography-font-stack-code: SF Mono, Consolas, Ubuntu Mono, monospace; | ||
--token-typography-font-stack-display: -apple-system, BlinkMacSystemFont, Segoe UI, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol; | ||
--token-typography-font-stack-text: -apple-system, BlinkMacSystemFont, Segoe UI, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[question] --token-typography-font-stack-display
and --token-typography-font-stack-text
are now the same. Are we able to simplify them down to the same token or no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer not to, if that's OK for you. Reason being that 1) would require some refactoring on our side (not big deal) but potentially from our consumers (not great) but more importantly that 2) if in the future we want to differentiate for some reasons the two, having two separate tokens will make it seamless (we just release a new version of the package and that's it) while if we have a single token will require to manually check all the use cases where it's used and decide if it's a text
or a display
(maybe it's easy, maybe it's a nightmare).
The cost of maintaining both is zero now (there's not even performance problems). The potential cost of unifying them is unknown (and in the worst case could be pretty high).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, thanks for clarifying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
๐ Summary
This resolves #128 - see the issue for more details on what problem we're trying to solve with this PR
๐ ๏ธ Detailed description
In this PR I have:
SF Pro Display/Text
inDisplay/Text
-apple-system, BlinkMacSystemFont
already do the jobSegoe UI Display/Text
withSegoe UI
inDisplay/Text
Helvetica, Arial, sans-serif
to thesans
block inDisplay/Text
Roboto
but then decided to remove it (reference)Ubuntu
for thelinux
platformDisplay/Text
SF Mono
withui-monospace
inCode
monospace
in the browserMenlo
toCode
๐ How to review
๐ Review by files changed
Reviewer's checklist:
๐ฌ Please consider using conventional comments when reviewing this PR.
๐จ Percy visual regression tests failing
All the visual regression tests in Percy are failing. There is not much we can do. The reasons are multiple:
Display
andBody
sans text is exactly the same, while the difference is only on theCode
monospace (and it's for the reason mentioned above, that the previous implementation was not using the right font declaration).