How should themes use fonts?
RunDevelopment opened this issue · comments
We have a lot of themes and they use fonts differently. Some use Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace (this is why we use over at PrismJS/prism), some Menlo, Monaco, "Courier New", monospace, and others use completely different fonts.
I don't think that we should disallow themes to use custom fonts but:
- Most themes only use generic fonts. It looks like they don't care which one it is specifically.
- Custom fonts (that the user likely hasn't installed) should probably be
@imported.
My question is: How should themes use fonts?
- Should they
@importtheir (main) font? - Should (most or) all use the same set of generic fonts?
In my case (Coldark author), point 1 is correct. I could have chosen a specific font, but:
- A font file must be included with the theme to be safe (while checking the license allows it) or the user must provide the font himself. It can make a project heavier just for one font.
- The themes are generally declined for several tools and it is not always possible to include the font or even to specify a font inside the theme.
Finally, I'm a Linux user so it can affect my way of seeing things. I rarely have the font chosen by a site ("Helvetica" for example), so I use one of the fallbacks defined by the creator. That does not bother me. As a creator, usually, I don't want to impose a font to the user. In the case of a theme, i think it is there primarily to offer a color scheme, the font used is secondary or even insignificant.
Since all themes defined a font, I thought it was necessary. So, I defined a font list by looking at what was done for the other themes. In other variations, the font is not specified.
So, to answer the question:
I am not against the first idea, but I am not convinced this is the best choice. I think the second idea is the most reasonable solution. Prism define a default font, which is easy to override if desired by the user. If a theme wants to recommend a font, it can do so in its docs / comments and users decide if they want to use it.
The first thing I do when I install a new IDE/text editor is to change the font used (and also the colours/theme). In making my own site, I would also load the selected font so users will see that instead of some other random font. Personally, despite having specifically defined fonts for One Dark and One Light based on what Atom defined, I would probably override it with another monospace font that I like/fits the site better (to be honest, I installed Fira Code just for the screenshot, haha), and I would think others would want to have that same flexibility.
So in a way, the main focus of themes would be the colours, and the font selection is merely a suggestion, if even supplied. This separation of fonts and themes is consistent with the behaviour of the IDEs and text editors I have used so far.
As such, I don't think themes should import custom fonts, but I don't know if using the same set of generic fonts (together with font recommendation in the docs/comments as what @ArmandPhilippot suggested) is the way to go.
I think it would help if we know if users immediately override the font selection, are surprised that the font they see doesn't match the image in the README and import the missing font themselves, are content with the supplied options and do not care to override nor import custom fonts, or don't even realise that the font is different on their site. (I'd like to think that most people pay at least some attention to fonts, but who knows, really.) But maybe this is complicating things too much.
If I had to choose, I think I'd stick to the principle of separating font choice from themes. Maybe not as far as to unset or not even declare the property (just in case, I guess), but it should be made clear how a user can override the font so at least they will be aware of it.
I don't think we have to lock themes down to a specific font stack. They're going to need to define it anyway cuz we don't have a way to share that across themes.
I'm mildly opposed to @import because it denies flexibility, and perhaps mildly opposed to allowing a stack that includes something that needs to be loaded at all, although including a font no one has and falling back to a system font is probably fine and the theme user can load the special font themselves if they want to use it.
They're going to need to define it anyway cuz we don't have a way to share that across themes.
Couldn't we use Sass or Less? Using a preprocessor would also enable us to move all the boilerplate out of the themes themselves.
We could, although that would be a lot more work than the question posed here. Possibly something to consider for V2.