Draft PR for discussion: transition to CSS varaibles only. #1044
Conversation
| @@ -10,73 +10,41 @@ | |||
| .mzp-u-title-2xl { | |||
| @include text-title-2xl; | |||
| font-family: $title-font-family; | |||
There was a problem hiding this comment.
Maybe font-family should be part of the @include text-title-n declaration?
| --title-xs-line-height: 1.166; | ||
| --title-2xs-size: 1.25rem; | ||
| --title-2xs-line-height: 1.2; | ||
| --title-2xl-size: 3.5rem; |
There was a problem hiding this comment.
I've been toying with the idea of variable names that make it clear that they morph with media queries. Alternative name ideas:
--scale-title-2xl-size: 3.5rem;(colours could usetheme, nice because it gives a clue of the variable value)--let-title-2xl-size: 3.5rem;(javascript reference: const vs let, mostly nice because its short, we should not have any const CSS vars, they should be Sass vars)--find-title-2xl-size: 3.5rem;(nice because all dynamic variables can use the same prefix)
There was a problem hiding this comment.
But if we follow the rule that CSS variables should ONLY be used for dynamic variables then maybe the prefix is unnecessary? But then, is there value in making it explicit for contributors and users of the system who don't know the rules?
| line-height: var(--title-2xl-line-height); | ||
| } | ||
| } | ||
| font-size: var(--title-2xl-size); |
There was a problem hiding this comment.
Would putting the CSS variable into a Sass variable help with readability and authoring speed? Or would it add to confusion?
It would be SO NICE to just type --title-2xl-size.
stephaniehobson
force-pushed
the
css-vars
branch
from
f3f82aa to
1d59bc4
Compare
Draft PR for discussion.