For whoever was wondering:
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Fira Sans", "Droid Sans", "Helvetica Neue", Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
I've had this saved as a snippet in my editor since that great medium article on system fonts a while ago.
Any chance you could supply the link to that article?
If you'd like to get some background on using system fonts, watch this short video
I'm sure I'll get used to it, but right now it feels a bit wide
EDIT: Sacha's right
Downside to that kind of change is that it'll affect everyone, regardless of the font being rendered. We'd have to scope that to just versions of macOS with San Francisco available.
Definitely something that should be handled by an extension like Stylish, not suggesting a global change! Hopefully there's a fix in the work somewhere. Oddly, I'm not seeing the issue on this super secret site I'm working on, despite using a very similar stack.
Really only affects Chrome honestly, and they're looking into it. https://bugs.chromium.org/p/chromium/issues/detail?id=627609
At first it was a bit weird, but that's a normal feeling when you've been used to seeing the same font year after year. I have quickly gotten used to it, however I haven't seen how it looks on other systems than macOS.
Looking great. I'm a big fan of San Francisco on iOS/macOS and like seeing more web sites/apps allow its use.
How the heck do they deal with alignment and vertical rhythm? Every font will have different vertical metrics. Anybody see any bad cases of alignment yet?
Relative units (
em) are your friends, if you learn how to use them properly.
I don't think they'll help in this case. rem/em don't update with changes to font-family, only font-size.
We're not using relative units in any place save for our Markdown files (to make our rendered Markdown scale easily for mobile, issue comments, and readmes/blobs).
The few cases of misaligned icons are being fixed as bugs. Overall, we haven't seen too much funkiness across the browsers as the main system fonts are pretty similar size-wise.
Thanks for the response, that's super interesting. I assumed the vertical metrics would be very different, but didn't bother to check.
Are the misaligned icon issues font agnostic, or are you having to find a way to make font-specific fixes?
Most are agnostic to any particular font. Haven't run into anything egregious that would require browser-specific overrides yet.
Oooo...so they did change the font...and I thought it was just me...
Maybe they'll update it later, but Roboto now feels a bit weird on: https://github.com/home
After a little while you start to notice the niceness, yesterday I wasn't sure but today I love it
No problem using Roboto at all, just mentioned because the lack of consistency.
Agreed about Roboto btw! Our team is talking about it—we'll probably stick to Roboto or something for headings, but we'll likely remove it for the body text and go to this new font stack.
Not an A/B test, just a (slightly) slow roll out :).
Ahhh, that makes sense. Nice! :D
Why this choice? Is it just for performance?
Also curious about why this roll out decision
We feature flag just about every change we do for ease of implementation. It gets our code into production faster for us to test and makes for a smoother release thanks to our internal tools. When we're ready to ship, we just select what percentage to enable that feature flag for—1, 5, 10, 25, 50, 75, or 100%. Goal is to not make the site explode for our users :).
For a font change like this, that wasn't the major concern, but rolling it out incrementally did give me a safety blanket of sorts. In other changes, where we might overhaul a view or unveil a new feature, we want to make sure we don't trigger tons of exceptions inadvertently. A slower rollout means it's easier to respond to those things before they get out of hand.
Hope that helps!