You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This comes up specifically with our font() mixin. Looking at this, it's not clear what property the font-size is: @include font(sans-display, title-desktop, jumbo, medium, 0.53, 74px);. It's probably jumbo or medium, but it could even be one of the last two.
Alternatively we could do something like this: @include font(sans-display, ft-title-desktop, fs-jumbo, fw-medium, 0.53, 74px);
This wouldn't be necessary if used directly with map-get(), but with the mixin we lack clarity.
Related concerns:
Honestly it's not clear to me if the font-size type layer is doing much more than adding a layer of obfuscation since most of the sizes seem to be are shared between groups. The benefit is avoiding having to think of 8 reasonable names for sizes (e.g., medium-small), though I'm seeing some of that happening anyway (e.g., small, smallest, micro in Moore. Smallest isn't the smallest).
The example above is from a particular project, but it displayed an additional issue: line-height, besides also being unclear which it is, can be passed through as a pixel value, rather than relative value, without stylelint catching it. It's also harder to catch in QA due to the layer of obscurity. Variables, could have the same problem, but it's easier to see that a lh-normal variable is set to 24px and catch that error.
What does the font() mixin really help with that the CSS font property doesn't? The mixin adds letter-spacing. Is that worth the layer? The font property seems better constructed to indicate purpose (e.g., font-size and line-height as 24px/1.4) and is a standard.
It's possible that these are problems specific to Moore, but I don't know if we've stated practices around this.
The text was updated successfully, but these errors were encountered:
To be clear, the specific proposal is to specify that map variables should be semantically named (e.g., fs-small for font-size: $small. The rest are related discussion points that could have bearing.
This comes up specifically with our
font()
mixin. Looking at this, it's not clear what property the font-size is:@include font(sans-display, title-desktop, jumbo, medium, 0.53, 74px);
. It's probablyjumbo
ormedium
, but it could even be one of the last two.Alternatively we could do something like this:
@include font(sans-display, ft-title-desktop, fs-jumbo, fw-medium, 0.53, 74px);
Then your font weight map might look like:
This wouldn't be necessary if used directly with
map-get()
, but with the mixin we lack clarity.Related concerns:
type
layer is doing much more than adding a layer of obfuscation since most of the sizes seem to be are shared between groups. The benefit is avoiding having to think of 8 reasonable names for sizes (e.g.,medium-small
), though I'm seeing some of that happening anyway (e.g.,small, smallest, micro
in Moore. Smallest isn't the smallest).lh-normal
variable is set to24px
and catch that error.font()
mixin really help with that the CSSfont
property doesn't? The mixin adds letter-spacing. Is that worth the layer? Thefont
property seems better constructed to indicate purpose (e.g., font-size and line-height as24px/1.4
) and is a standard.It's possible that these are problems specific to Moore, but I don't know if we've stated practices around this.
The text was updated successfully, but these errors were encountered: