Proposal for a modern Sass integration via Sass Modules

[thasmo]

Based on the discussion in #356, this is my (initial) proposal for a modern Sass integration based on Sass Modules. For now, this is "just" a static draft of how the Sass integration could look like for the Fonts Recursive, Open Sans and Roboto. Proper integration into Fontsource would be another step after the initial proposal/draft has been fine-tuned based on feedback etc.

Documentation is still lacking; please have a look at the code or clone and build the project. 😃

https://github.com/thasmo/fontsource-sass-integration

Feel free to try it out and chime on on the discussion. 👍

Thanks a lot!

[thasmo]

Updated the introductive post and optimized the README of the proposal.

[thasmo]

Thanks a lot for your thoughts, @DecliningLotus, @codegain, @davidjb, @cbirdsong and everyone else! 👍

[thasmo]

Rather than @include recursive.faces(), do you think @include recursive.set() makes better naming sense?

That's definitely not the final name. set sounds like a worthy contender, but I wouldn't want to finalize the names of mixins/functions/filenames for now anyway. But better names are the goal. 👍

If you wish to choose multiple specific weights, would you write $weights: (400, 500) to generate those specific subsets?

Yes, that's already working. Allowed values would be all, and a list of weights:

$weights: all
$weights: 400, 500
$weights: (400, 500)
$weights: [400, 500]
$weights: 400

Also, it will/should only render font-face declarations for valid/available weights.

The default behaviour for $subsets should be all of them. Developers must consciously make a decision to select a specific one.

I would argue that using the single "default" subset by default is a stronger reason for developers to choose (other) subsets. Using all as the default, would also (depending on the font) render a lot of font-face declarations which, depending on the project's content, are not needed at all because the content is not available in the languages which need the characters of these subsets. Also having one single subset as default matches the behavior of weight and style which also (for the moment) have a single default value.

A discussion on variable fonts. Does the $axes selector choose between wghtOnly and all or do you have it set to individually select specific axes?

The $axes option is probably the one option which is finalized the least. At the moment it allows passing a list of font axes, and it will render a @font-face declaration per axis. This would only make sense if every @font-face declaration has a different font-family value declared; otherwise (I guess?) the browser can't select the "correct" @font-face declaration anyway. So basically, the output is non-working.

I wonder if it does really make sense to generate combinations of all the axes. Although the number of files would exponentially go out of control with all the possible combinations, especially for Recursive which has 5 axes. I wonder if there is a compromise to be made?

To be honest, as I do not have too much practical experience with variable fonts, I'm not totally sure. As much as I know about the topic, the way to use a variable font is to use one font-file which includes all needed axes. Basically this means the full version of the font-file is the best choice, except when the project really only needs a single axis. So it's either full or a single axis in my opinion. Of course the optimal solution would be to craft all possible combinations and let the developer choose a combination-file which fits the requirements perfectly, but that would probably make font generation and the Sass mixin quite complicated and time-consuming. So, I would opt for maybe scraping the idea of supplying multiple axes and provide an axis (singular) option, to choose a single axis or, ofc, full. But as I said, I'm not totally sure this would be the best solution, covering real practical requirements - although I think it probably is. 😄 And as the font-files of variable fonts should be quite small anyway, the full option is probably the best option in most of the cases.

[thasmo]

One thing which came to my mind. There are the standard axes wght, wdth, slnt, opsz, ital and custom axes, which are capitalized. So, I think it would be nice to have these variable font files generated:

• full (all axes)
• standard (standard axes only)
• custom (custom axes only)
• single (one file per axis)

That would mean for e.g. Recursive there would be 8 files:

• full
• standard
• custom
• slnt
• wght
• CASL
• CRSV
• MONO

[ayuhito]

I would argue that using the single "default" subset by default is a stronger reason for developers to choose (other) subsets. Using all as the default, would also (depending on the font) render a lot of font-face declarations which, depending on the project's content, are not needed at all because the content is not available in the languages which need the characters of these subsets. Also having one single subset as default matches the behavior of weight and style which also (for the moment) have a single default value.

A reason I would prefer this mixin default to be all is because that is the default behaviour project-wide and I think it makes sense to keep things consistent. We pretty much emulate exactly how the Google Fonts API serves its CSS and I'd rather not deviate from that. The purpose of unicode-range doesn't load in the font if the characters don't exist on the page, whilst dynamically loading it in if it suddenly comes in. e.g. user inputs or people translating pages etc. Language support "should just work" unless specifically chosen.

I hate to add more to the already monumental work you've done, but this reminds me of another situation that would need to be supported. Have you tried the mixin with Noto Sans JP and see if it matches the CSS already in the package? For large languages, such as Japanese, Google splits the font into hundreds of numbered subsets.

Essentially the numbered subsets solution is also a variance of all subsets, another reason why it should be kept default. We'd need to consider ignoring language specific subsets when loading all if the font has numbered subsets.

That would mean for e.g. Recursive there would be 8 files:

• full
• standard
• custom
• slnt
• wght
• CASL
• CRSV
• MONO

Regarding this, I thought about it and I think it makes sense to to generate variable font files for each axis. However, wght is included in all of them by default regardless. It wouldn't make sense to generate individual font files per weight for each other axis.

• full
• wght
• slnt + wght
• CASL + wght
• CRSV + wght
• MONO + wght

The addition of standard and custom sounds interesting. I like the idea of standard, but custom feels so niche (who would use 2 or more of those axis) that I can't imagine it being worth pushing that extra file to the 1000+ packages we have. I'd just substitute that for full or any other axis by itself.

[thasmo]

A reason I would prefer this mixin default to be all is because that is the default behaviour project-wide and I think it makes sense to keep things consistent.

I understand; that makes sense!

We pretty much emulate exactly how the Google Fonts API serves its CSS and I'd rather not deviate from that. The purpose of unicode-range doesn't load in the font if the characters don't exist on the page, whilst dynamically loading it in if it suddenly comes in. e.g. user inputs or people translating pages etc. Language support "should just work" unless specifically chosen.

I'm aware of that; my thought was that depending on the supported subsets, the size of the generated raw CSS for all the @font-face declarations could be rather large. But, I guess, the user/developer has the choice to configure the actually needed subsets anyway.

I hate to add more to the already monumental work you've done, but this reminds me of another situation that would need to be supported.

All good. :) I rather prefer to get feedback than to lose a proposal due to communication stagnation. :)

Have you tried the mixin with Noto Sans JP and see if it matches the CSS already in the package? For large languages, such as Japanese, Google splits the font into hundreds of numbered subsets.

I did not know that and I'm going to review Noto Sans JP. Are there any other "special" cases you can think of worth trying out?

The addition of standard and custom sounds interesting. I like the idea of standard, but custom feels so niche (who would use 2 or more of those axis) that I can't imagine it being worth pushing that extra file to the 1000+ packages we have. I'd just substitute that for full or any other axis by itself.

True!

Regarding this, I thought about it and I think it makes sense to to generate variable font files for each axis. However, wght is included in all of them by default regardless. It wouldn't make sense to generate individual font files per weight for each other axis.

wght is included in all files by default? Even wdth has wght included?

The addition of standard and custom sounds interesting. I like the idea of standard, but custom feels so niche (who would use 2 or more of those axis) that I can't imagine it being worth pushing that extra file to the 1000+ packages we have. I'd just substitute that for full or any other axis by itself.

True. In that case the files could be this:

• full (standard + custom)
• standard (wght, wdth, slnt, opsz, ital)
• wght
• wdth + wght
• slnt + wght
• opsz + wght
• ital + wght
• CUSTOM + wght

[ayuhito]

I did not know that and I'm going to review Noto Sans JP. Are there any other "special" cases you can think of worth trying out?

Nothing else unique, it should affect all fonts that support Japanese, Chinese or Korean. Not sure about others.
I can foresee this might need updating in the future, however. When Google finally introduces a variable font that also uses this numbered subset approach. I have no clue if they might change things up then.

wght is included in all files by default? Even wdth has wght included?

I believe so? It's a core axis and I can't see us generating wght 100,200,...,800,900 variants of each variable font anyways.

True. In that case the files could be this:

• full (standard + custom)
• standard (wght, wdth, slnt, opsz, ital)
• wght
• wdth + wght
• slnt + wght
• opsz + wght
• ital + wght
• CUSTOM + wght

I'll make an issue for this later which should be part of the 5.x milestone then.

[thasmo]

I've updated the codebase; improved the API, refactored it into separate functions/mixins and also fixed various issues mostly related to different edge cases along the way.