p {border-bottom: 2px solid black;margin-top: 0;margin-bottom: 20px;}
我们有几个段落,每个段落底部有 2px? 边框,并且它们之间有 20px? 边距 。请注意,我们对两者都使用 px 单位 。
如果你放大或缩小,元素的大小和距离保持相对不变 。也就是说:你放大得越多,那条线就越粗,段落之间的间距就越大 。
为了方便起见,这里有一张截图,显示了同一支笔的400%缩放 。文本、线条和间距都变大了4倍;它们相对于彼此的大小保持不变:
文章插图
当涉及到缩放时, px? 、 em? 或 rem 之间没有真正的区别 。但缩放并不是用户使网站更易用的唯一方法 。
如前所述,用户还可以指定默认和/或最小字体大小 。当他们这样做时,功能开始分歧 。
在下面的截图中,我已将Firefox的默认字体大小设置为 64px 。看一下:
文章插图
将屏幕截图中的文本与其上方的文本进行比较 。请注意,这一次,行并没有变粗,段落之间的边距也没有成比例增加 。只有文本本身变大了 。因为边框宽度和边距都是在 px 中设置的,它们保持不变,不会缩放 。
但是请注意,如果将CSS中的 px? 更改为相应的 rem 值,会发现线条和间距确实变大了!(zh-Hans)
文章插图
所以,这里的总结是:
- 当用户更改字体大小时,px 值不会缩放 。
- em 和 rem 的值会随字体大小成比例调整 。
选择哪一个因此,知道 em? 和 rem? 会随字体大小缩放,但 px? 值不会,那么我们该怎么办?我们应该永远不使用 px 吗?
虽然我认为如果你选择这条路,你可能会没事,但我仍然认为 px 有其存在的意义 。
我们知道当用户调整字体大小时 px 值不会改变,这意味着像素单位实际上是某些美学元素的不错选择 。也许我们有一定的间距,我们不希望在字体大小变大时变得更大 。(如果默认情况下是一个大块的负空间,也许允许它缩放到更大的尺寸是没有意义的 。)
也许有一些边框大小我们不想改变,或者页面上有用 CSS 创建的装饰元素,在更大的字体大小下看起来效果不佳 。也许我们不希望填充随着字体大小的增加而膨胀 。在所有这些情况下,px 仍然是一个不错的选择 。
我个人建议使用 rem? 来设置所有的大小 。我只在想要与当前字体大小成比例的东西(例如,与一些文本旁边的图标应该与字符的高度完全相同,并且在一侧有半个字符的情况)中添加em。我不会在任何地方使用 px ,除非是明确不想随字体大小缩放的设计元素 。
永远不要用 ?px 单位中设置 font-size ,除非你非常确定你在做什么,它会如何行动,以及在你这样做时它是否仍然可访问 。
关于媒体查询的重要说明出于与上述所有原因相同的原因,重要的是要避免在 @media? 查询中使用 px? ;当用户缩放时,它将正常工作,但是使用 px 的媒体查询将在用户自己设置更大的字体大小时失败 。
@media (min-width: 800px) {/* Changing font size does NOT affect this breakpoint */}@media (min-width: 50rem) {/* Changing font size DOES affect this breakpoint */}
这是因为随着字体大小的增加, 50rem? 会根据用户的偏好变成不同的值,而 800px 则不会 。很可能,当我们为较大的断点编写CSS时,我们认为有足够的屏幕空间让元素扩展 。如果用户设置了非常大的字体大小,则可能不是这种情况,将媒体查询设置为 rem? 而不是 px 可以帮助我们避免这种假设并响应用户的偏好 。
我在这个网站上遇到了这个问题;我把所有的断点都设置在 px 上 。然而,当我将默认字体大小设置得更大时,我的媒体查询没有响应,因为它们仍然只查看屏幕的像素宽度 。因此,我仍然有一个微小的侧边栏,里面塞满了难以辨认的巨大文本,因为我没有考虑用户的偏好 。在那之后,我立即改为 rem,问题得到了解决 。
推荐阅读
- Go 语言切片是如何扩容的?
- 为什么 Python、Go 和 Rust 都不支持三元运算符?
- 配置 Linux 环境变量的六种方法
- AI生成的合成图像泛滥且真假难辨 政策监管势在必行
- 没有光盘怎么修复系统
- 防盗连、隐藏版本号、防嵌套等 Nginx基本安全配置
- 郑爽|郑爽曾在粉丝群,曝景甜张继科事件细节
- 文玩|文玩鬼市,从唐朝到现在
- 国企|10年前父母帮我买的国企工作太值了,现在两倍的钱都找不到这么好单位
- 魏璎珞|《延禧攻略》是古代职场升职记?魏璎珞教你如何在后宫做人