使用例如Mike Riethmuller使用calc()实现从最小字体大小到最大字体大小的流畅过渡,从calc()返回并显示在浏览器中的结果令我有些困惑(并非意料之中) )。以下代码如何以25rem至80rem的视口大小为h1返回此结果? (我也为html字体大小添加了calc(),因为它也与h1成比例缩放)
结果:
h1 calc(0.450091rem + 3.38364vw)
代码:
html {
font-size: 1.125rem;
}
@media screen and (min-width: 25rem) {
html {
font-size: calc(1.125rem + 0.25 * ((100vw - 25rem) / 55));
}
}
@media screen and (min-width: 80rem) {
html {
font-size: 1.375rem;
}
}
h1 {
font-size: 1.296rem;
}
@media screen and (min-width: 25rem) {
h1 {
font-size: calc(1.296rem + 1.861 * ((100vw - 25rem) / 55));
}
}
@media screen and (min-width: 80rem) {
h1 {
font-size: 3.157rem;
}
}
当我们进入视口的最小宽度为80rem并达到最大字体大小为3.157rem时,结果是“跳跃”的非流体过渡。
答案 0 :(得分:1)
由于您要更改font-size
元素的html
,因此您还要更改rem
的值。这有点棘手,但让我们逐步了解代码和计算。
最初,我们在font-size
中将有一个1.125rem
等于html
,对于font-size
,我们将有一个h1
等于1.125 * 1.296 * 16px = 23.328px
。对于媒体查询,我们将有25rem = 25*16px = 400px
和80rem = 80*16px = 1280px
1 。
在400px
(第一个媒体查询)之后,这变得很棘手,因为我们将使用html
具有font-size的动态值,因此font-size
的{{1}}将是像这样:
h1
哪里
(1.296* P *16px + 1.861 * ((100vw - (25 * P * 16px) ) / 55))
现在,当我们到达下一个媒体查询( P = (1.125 * 16px + 0.25 * ((100vw - 25 * 16px) / 55))
)时,我们将得到1280px
等于100vw
(而不是我们想像的1280px
!)和{{ 1}},因此考虑到在之前 80rem
之前的论坛的结果将是P = 1.375rem
。
考虑到{strong>之后 1280px
之后的公式的结果将是1.296 * 1.375 * 16px + 1.861 *((1280px - 25 * 1.375 * 16px)/55) = 28,512px + 24.7px = 53.21px
。这就解释了为什么您没有过渡,而罪魁祸首是等于1280px
而不是3.157 * 1.375 * 16px = 69.454px
的{{1}},所以您想获得100vw
的意图结果/ p>
根据您发现的公式,我们将得到相同的结果:
h1 calc(0.450091rem + 3.38364vw)
在1280px
,80rem
将是(80 - 25)/55 = 1
,而80rem
将是100vw
,而1280px
将是3.38364vw
,总计43.13px
。
结果也是合乎逻辑的,因为0.45rem
将简化公式以将所有相同的单元分组在一起:
0.45 * 1.375 * 16px = 9.9px
1 为什么在媒体查询中我们不乘以html中使用的值?
考虑以下计算,我们可能认为在媒体查询中,我们还应该考虑相同的逻辑,因此53.03px
和calc
也应该是动态的。 the specification中没有详细介绍媒体查询的情况:
媒体查询中的相对长度单位基于初始值,这意味着单位永远不会基于声明的结果。
因此,calc(1.296rem + 1.861 * ((100vw - 25rem) / 55))
calc(1.296rem + 1.861 * (1.8181vw - 0.4545rem)
calc(1.296rem + 3.3834vw - 0.8459rem)
calc(0.4501rem + 3.3834vw)
中使用的25rem
的值是多少,我们将始终考虑媒体查询中80rem
的{{1}}的初始值。
由于一些舍入,使用不同方法获得的值之间会有一些细微差异。目的不是提供精确的计算,而是解释计算。