sindresorhus / modern-normalize

🐒 Normalize browsers' default style

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Provide system fonts

sindresorhus opened this issue · comments

Are there any downsides to setting this by default?

body {
	font-family:
		'-apple-system',
		'system-ui',
		'BlinkMacSystemFont',
		'Segoe UI',
		'Roboto',
		'Helvetica Neue',
		'Arial',
		'sans-serif',
		'Apple Color Emoji',
		'Segoe UI Emoji',
		'Segoe UI Symbol';
}

Users then get good defaults but can override it with their own body selector if they want.

Alternatively, if this gets a lot of resistance, we could provide a CSS variable, so users who want it can just do:

body {
	font-family: var(--system-fonts);
}

Thoughts?

(If you 👎 please also share your thoughts on why)

@anselmh Are you downvoting including system fonts by default or also just as a variable? And why?

Sorry, voted first, now here are my detailed two thoughts on it. Note that I’m not 100% convinced whether my thoughts are correct, so take it with a salt of grain:

  1. A normalization codebase should do exactly and only what the name says: normalize things. Setting system fonts is an opinionated base style but no normalization—in fact quite much the opposite.

  2. Having to override this is, regardless of how it can be done, not what I want from a normalize script. One of the things I never really liked about the original normalize.css is that most of the rules in there are not used in a project, resulting in dead code. I think the goal should be to eliminate this and this rule would not achieve this goal.

2.1 If this makes it into the codebase I like the idea of setting it as CSS custom property and only on demand.

A normalization codebase should do exactly and only what the name says: normalize things. Setting system fonts is an opinionated base style but no normalization—in fact quite much the opposite.

Browsers already ship with a default font family, this just normalizes it. That's how I look at it at least.

Browsers already ship with a default font family, this just normalizes it. That's how I look at it at least.

Well but shouldn’t the goal be a visual equal look? This would mean something like font-family: Arial, sans-serif as the probably most common wide-spread family. I know normalize.css does not set this either and I’m actually more keen to have the system font stack over plain sans-serif for specific elements only.

I personally see normalization as a strive for parity which in this case is not the goal if system fonts are set. Maybe my thoughts are erroneous as most people would prefer to have sans-serif set and then I’d say the system font stack makes more sense.

I realize my proposal will not result in full normalization, but it is better than the browser default. At least setting the font-family means consistent fonts for all browsers per OS, unlike the browser default which can result in different fonts for browsers on the same OS. It also makes it look better by default, which means we have a chance to make the web on average look better (For all those that don't set a font-family). I imagine at some point in the future browsers will default to font-family: system-ui.

In which case I think best would be to set this directly, as originally suggested by you and not provide an opt-in via CSS Custom Property. Thanks for this discussion, it actually changed my views on this. 🙂

@sindresorhus Did you see @mdo's blog post on Shipping system fonts to GitHub.com?

They've changed the defaults for various reasons mentioned in the post:

body {
	font-family:
		'-apple-system',
-		'system-ui',
		'BlinkMacSystemFont',
		'Segoe UI',
-		'Roboto',
-		'Helvetica Neue',
+       'Helvetica',
		'Arial',
		'sans-serif',
		'Apple Color Emoji',
		'Segoe UI Emoji',
		'Segoe UI Symbol';
}

(See https://github.com/primer/primer/blob/454a8841469de50df97daf70e3cee370443a7d0f/modules/primer-support/lib/variables/typography.scss#L36)

@khellang It's a good read, but it's missing specifics. The system-ui issue might be fixed by now. It doesn't say why they switched from Helvetica to Helvetica Neue.

PR is up. I could use a review: #16

@> It doesn't say why they switched from Helvetica to Helvetica Neue.

This is done because on Windows, users will never get Helvetica as it’s aliased to the Arial font family. As it’s only available as a fallback, it’s extremely unlikely that someone will see Helvetica at all so Helvetica Neue which is the more commonly font-family today (if bought or on macOS) makes more sense here. It’s mentioned shortly in the notes inside the article.
Please disregard, it seems I’m not understanding the blog article explaining the changes at all.

I think adding font related properties shouldn't be a part of normalization css files.

@Altug Please read the whole discussion. The argument is that it is a normalization.

The standard and non-standard ways to select system fonts are too much in flux IMO to offer a specific solution in a “normalize” stylesheet.

I also like the @font-face method a lot more. It lets users reuse your system font definitions.

My blog post was written over a year ago, so there's some stuff that's off and already changed since then. Did my best to call those out where I could. We had issues with system-ui and our international audiences if I recall.

The font stack and my post don't match up though with what's there currently with Helvetica vs Helvetica Neue. I will say that from experience, Helvetica Neue has much different behaviors with vertical alignment compared to Helvetica. It's a superior font for macOS IMO, but clearly something was jumbled either on my end or the stack itself. Definitely needs looking into as my gut tells me we should have Helvetica Neue and Helvetica in there given Windows aliases Helvetica outright to Arial.