Chrome 浏览器上的 100vh 行为
由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！
在我使用的一款 WordPress 主题中，文章和页面的特色图片会铺满整个屏幕。它们作为背景图片，标题则垂直和水平居中显示。屏幕底部有一个小箭头图标，点击（或轻触，如果您使用的是触摸屏设备）即可滚动到页面顶部。
在 CSS 中，可以通过以下方式实现 100% 的高度：
min-height: 100vh;
（我最初使用的是高度，但我发现过长的标题在手机和平板电脑等小屏幕上会被截断。通过使用最小高度，我可以确保过长的标题在需要时会自动将高度推至大于 100%。）
问题
由于 Cover2 是一个响应式主题，我尽量确保它在各种浏览器和屏幕尺寸上都能呈现良好的效果。但我注意到，在安卓版 Chrome 浏览器中，情况并非如此。
安卓版的 Firefox 和 Chrome 都有这样的功能：向下滚动页面时，浏览器地址栏会向上滑动，直到你向上滚动页面才会再次显示。（这实际上和 Cover2 实现的导航栏方式很相似。）不过，这两个浏览器处理屏幕高度的方式有所不同。
在 Firefox 中，当地址栏可见时，完整高度（100vh在 CSS 中）是指地址栏到屏幕底部的距离。当地址栏隐藏时，完整高度是指屏幕顶部到底部的距离。
在 Chrome 浏览器中，完整高度是指屏幕顶部到底部之间的高度，无论地址栏是否可见。
解决方案
我之前写过文章表达我对用户代理嗅探的厌恶之情。（有趣的是：我最近发现我妻子觉得这个词特别搞笑。）然而，这次的情况我恐怕无法避免。
解决方案是降低 Chrome 的全屏高度，这样地址栏就不会被计入其中。地址栏的高度56px（根据我反复试验得出的结果）是……，但我仍然需要只针对 Android 上的 Chrome 浏览器进行优化。
WordPress 已经具备一定的用户代理检测功能，并会根据检测到的用户代理为标签分配类<body>。例如，在我的电脑上，它会分配 `<a>`os-windows和`<a>` 类browser-gecko（如果你好奇的话，这是 Firefox 浏览器）。但问题在于：WordPress 会browser-android为Android 系统上的所有浏览器分配该类，包括 Chrome 和 Firefox，而不仅仅是 Chrome 成为主流浏览器之前 Android 自带的浏览器。这显然行不通，所以我需要找到更精确的方法。于是，CSS 的 ` @supports@at` 规则就派上了用场。
我更喜欢使用特征查询，所以我将其与专门针对 Chrome浏览器的 hack@supports结合使用。单独使用这种方法会同时覆盖 Chrome、Safari、Edge 和 Opera 浏览器，所以我将其与 WordPress 自带的用户代理 OS 类结合使用：
.page-header {
@supports (-webkit-appearance:none) {
.os-android & {
min-height: calc(100vh - 56px);
}
}
}
这样一来，Chrome 的导航栏就实现了正确的全高显示效果。
本文最初发表于eichefam.net。
文章来源：https://dev.to/peiche/100vh-behavior-on-chrome-2hm8