Open simevidas opened 8 years ago
To focus on this problem (also defined in the article): the media queries used are expressed in em
and refer to the UA's base font size (16px
for most browsers and devices except a few eReaders and smart TVs; potentially changed to a different value through user preferences).
What you need for X in the (100vw - X)
expression is a value that has exactly the same width as your breakpoint. But if you use the em
unit here, it will refer to:
font-size
property).So 20em
in your media query and 20em
in your calc()
function may end up resolving to slightly or wildly different values.
As it stands, this plugin's output only works for elements whose font-size (or whose parent's font-size) is exactly the same as the UA's base font-size. If it's smaller or bigger, the lock will break.
Using rem
limits — but doesn't negate — this problem. The lock can still get broken if some style redefines the root element's font-size
.
If the root element's font-size is changed proportionally (e.g. :root { font-size: 125% }
), it's still possible to make a working lock, but the calc
has to incorporate that factor:
@media (min-width: 20em) and (max-width: 60em) {
/* 1rem = 125% of base font size */
h1 { font-size: calc( base_value + increase * (100vw - 20rem/1.25) / (60 - 20) ); }
}
@fvsch forgive me if Im overlooking something, but it seems to me that it would be ideal if all sizing on a site would be relative to rem, so a user's root font preferences scale not just fonts, but the whole site in proportion, no?
(Also thanks for the really excellent article)
Edit: Re-read your response. I mistakenly thought you were advocating just ems.
I don’t know the details, but using
rem
instead ofem
in the calculations may be “less dangerous”, according to this tweet:The user has written a lengthy article on CSS locks here.