基于 Rem 的布局,chrome 上的缩放不一致,PX 与 REM

Rem-Based Layouts, Zooming on chrome is inconsistent, PX vs REM

我一直在为这个问题绞尽脑汁,google 搜索并没有真正提供太多帮助,甚至没有记录这个问题,但它极大地影响了我目前向移动设备的转换-友好的设计。

无论我走到哪里,每个人都在吹捧使用基于 rem 的布局作为新的黄金标准,从表面上看,这种方法的优点似乎很理想(对基于参考像素的缩放和字体的完全可访问性支持尺寸缩放以支持许多 DPI 和许多屏幕尺寸/设置)。

但是我 运行 遇到了一个相当大的障碍,我发现 Chrome(可能还有所有 webkit 浏览器,但我没有 mac atm测试)似乎与其他人不一样。

初始设置如下:

html { font-size: 62.5%; }
body { font-size: 1.6rem; }

我们应该能够使用 1/10 的像素大小来设置我们所有的测量值:

.my-element { height: 15rem; } /* 150px */

我创建了一个简单示例来说明我的问题:https://jsfiddle.net/gLkpz88q/2/embedded/result/

当您使用 Chrome 并以这种方式向外缩放时,请注意布局如何停止缩放但内容会继续。

将此与 Firefox、IE11、Edge 进行比较,您根本看不到这种行为,它们都一致且持续地缩放。

这是(左上角:Chrome,右上角:IE11,左下角:Edge,右下角:FireFox)并排显示:

如您所见,如果 rem 单元的缩放比例与其他所有单元不同,这会对布局产生一些可怕的影响。

我不确定如何处理这个场景,因为看起来 WebKit/Chrome 已经决定以完全不同的方式处理扩展,这需要质疑所有未来的扩展场景。

有很多文章提倡只使用像素,因为 CSS 参考像素 很好地处理了移动缩放:

然而,这些往往会忽略字体缩放问题,认为这是不太可能发生的情况。

我快速浏览了一些大型移动 friendly/friendlyish 网站,这些网站是我能想到的大型成功公司的网站,似乎大多数网站都只使用像素来满足其所有布局需求。 (Google, Facebook, Wordpress, Twitter, Bootstrap 3, [在某种程度上 Bootstrap 4], MDN, and WebPlatform)

Chrome 是新的 Standards-Busting IE 吗?还是我做错了什么?为了保持一致性,我很想在这一点上只使用像素。

那是因为Chrome设置最小字体大小的行为,所以如果你缩小,chrome会将最小字体大小设置为6px(中文和日文为12px)版本)。所以你的 div 将有一个最小宽度,因为它取决于你的基本字体大小(不能小于 chrome 的最小值)。

另请参阅:

Chrome will increase the font size when zooming out

[编辑] 附加信息:

关于此主题的 Chromium 票证和讨论:

https://bugs.chromium.org/p/chromium/issues/detail?id=16875 https://bugs.chromium.org/p/chromium/issues/detail?id=36429

-webkit-text-size-adjust 已放弃支持,因此此行为的可行解决方案不再可靠:

https://trac.webkit.org/changeset/145168/webkit

不要使用这个 CSS { font-size: 62.5%; } body { font-size: 1.6rem; } 它会导致更多问题,这是值得的,因为在使用不同基本字体大小的浏览器上您会得到不同的结果。只需使用此站点来计算正确的 rem 值。 http://pxtoem.com/

这应该会给您一致的结果。 https://jsfiddle.net/WizardCoder/gLkpz88q/3/

更新 https://jsfiddle.net/WizardCoder/gLkpz88q/5/

我将首先解决您的结束语来开始我的回答,纯粹是因为它引起了我的注意(除了巨大的赏金)。

"Chrome 是新的 Standards-Busting IE 吗?还是我做错了什么?为了保持一致性,我很想在这一点上只使用像素。"

是也不是。与在任何其他主流浏览器引擎中相比,我在 WebKit 浏览器中遇到的问题更多,但在调查个别问题后,我通常发现这是因为 WebKit 比其他人更严格地遵守 W3C 提供的规则。

大多数其他浏览器引擎似乎对开发人员非常宽容,我喜欢他们这一点,但我们不能一定要因为遵守规则而将 WebKit 钉在十字架上。

为了将上述陈述扩展到您问题的其余部分,我浏览了 W3C document regarding relative font lengths。在 rem units 的标题下,您会注意到第一行说明:

Equal to the computed value of ‘font-size’ on the root element.

不幸的是,font-size 本身对浏览器引擎的解释相对开放。

Cyrix 的回答是正确的,因为 Chrome 会根据引擎内置的 最小值 font-size 调整您的字体大小。为了轻松解决您的问题,您可以在容器元素上使用 text-size-adjust or the newer font-size-adjust 规则来防止这种情况发生:

* { /* Replacing "*" with ".my-element" would probably be better for the rest of your site*/
    -webkit-text-size-adjust: none;
    -webkit-font-size-adjust: none;
}

但是问题是旧版本的 Chrome 不接受 font-size-adjust,而新版本只接受 font-size-adjust 而且只有当实验性功能 已启用。

最后,为了回答您的其余问题,如果您正在处理实际的文本内容等,remem 是一个很好的度量单位。请按照以下行思考:

  • 如果您希望 <h1> 的文本总是比 body 文本大 25% h1 { font-size: 1.25rem; }
  • 如果 header 栏的高度必须始终是其中文本行高度的 3 倍 .header { height: 3em; }

但是,如果您正在使用需要在内部容纳指定内容块的容器类型块,那么使用更稳定的东西总是更好。请记住,稳定性并不意味着无响应

以此为例:

.my-element {
  width: 95%;
  margin: auto;
  max-width: 600px;
}

这将使您的元素很好地浮动在页面中间,同时保持元素的大小适合其中的内容,并且如果屏幕尺寸减小到小于您的 .my-element 高度,它会相应地调整。

简而言之

  • 是的,Chrome 破坏了一些让 IE 嫉妒的东西,但这没关系。
  • 是的,很多人确实尝试使用相对字体单位作为最好的做法,但是与他们所说的相反,您不需要对所有事情都使用它。
  • 您的最终结果应该是响应式网页。您实现此目标的方式将根据您拥有的内容而有所不同。
  • 字体缩放是一个很可能会存在一段时间的影响因素,如果您担心它会如何影响您的网页,请确保只有 需要的元素 将根据您的字体缩放,将随您的字体缩放。
  • “我很想在这一点上只使用像素来保持一致性。”在大多数情况下这是合乎逻辑的结论,所以去吧:)