search

jossef / material-design-icons-iconfont

Material Design icons + Development Experience
https://jossef.github.io/material-design-icons-iconfont
Apache License 2.0
455 stars 58 forks source link

mixin to generate font-face and .material-icons #83

Closed jaschwartzkopf closed 2 years ago

jaschwartzkopf commented 2 years ago

I'm working on an angular library project that is adding support for @use.

We'd like to be able to control when/where/if CSS is generated. To do that it would be nice if there was a mixin that wrapped the SCSS in material-design-icons.scss so we could @use _mixins.scss and not generate any CSS until/unless we call the mixin.

The reason we want this is we don't want angular components accidentally regenerating the font face, etc. every time they @use our library. With the way the angular cli handles rewriting asset paths, it's hard to get the path right if we just try to generate the font-face ourselves.

jossef commented 2 years ago

best I can think of is adding a @main mixing to the _mixings.scss file and the material-design-icons.scss will invoke it. on the other hand, you can simply use the mixing directly from the _mixins.scss file.

WDYT?

jaschwartzkopf commented 2 years ago

The main problem we had was with the font-face, since the way the Angular CLI re-writes CSS urls makes it hard for us to write it ourselves (but works when it comes from you SCSS, something to do with were the files are relative to the SCSS file). Currently the @font-face is not in a mixin (neither is the .material-icons class).

A @main mixin would work for us.

clshortfuse commented 2 years ago

Sass itself provides no code-splitting options and it's not part of any of their goals:

https://github.com/sass/sass/blob/main/accepted/module-system.md#non-goals

Despite many libraries exporting top-level rules like this one, it's not suggested by the Sass developer:

https://github.com/sass/sass/issues/2875#issuecomment-649884318

The take here is for the default material-design-icons.scss file to just import from others:

@include mixins.fontFaceMixin();
.material-icons {
  @include mixins.classRulesMixin();
}

Then custom implementations can pick and choose how often they load where as the default implementation stays top-level as expected. But as the sass dev comment says, it can be brittle if you don't have an API strategy (ie: want to change _mixins.scss).