当询问人们他们想要修复 CSS 中的 任何 问题时,一个令人惊讶的常见回答是改进视窗单位的处理方式。
一个经常出现的问题是如何将它们与滚动条相关联。例如,如果一个元素的大小设置为 100vw
并且延伸到边缘,那么只要页面没有垂直滚动条,一切就都很好。如果页面确实有垂直滚动条,那么 100vw
就会太宽,并且垂直滚动条的存在会触发 水平 滚动条,因为视窗单位没有优雅/可选的方式来处理这种情况。因此,您可能需要隐藏 body 上的溢出,而实际上您并不需要这样做,例如。(演示)
另一种情况涉及移动浏览器。您可能会使用视窗单位来帮助您将固定页脚定位在屏幕底部。但是,浏览器 chrome 可能会出现(例如导航、键盘等),它可能会覆盖页脚,因为移动浏览器不会认为视窗大小有任何变化。
Matt Smith 记录 了这个问题

-webkit-fill-available
属性,而不是视窗单位来解决这个问题。以及一个解决方案
body {
min-height: 100vh;
min-height: -webkit-fill-available;
}
html {
height: -webkit-fill-available;
}
上面已更新,以确保使用的是 html
元素,因为 我们被告知 Chrome 正在更新行为以匹配 Firefox 的实现。
这真的有效吗? […] 我在我运行的所有测试中都没有遇到任何问题,而且我现在正在生产环境中使用这种方法。但我确实收到了一些回复我的推文的回复,指出了使用这种方法的其他可能问题(旋转设备的影响,Chrome 完全忽略了该属性等)。
将来最好能找到一个真正的跨浏览器解决方案,但我没有看到使用它作为改进有任何问题。使用供应商前缀属性作为渐进式增强很奇怪,但嘿,这个世界就是这么奇怪的。
阅读链接的文章的评论很有用,因为它们会对该问题进行更深入的测试。同样需要注意的是,这里使用的样式将来会发生变化,因此只要将其视为 Chris 所说的“渐进式增强”,那就没问题,但如果依赖于此功能就不行。
我个人迫不及待地想要看到在将来能够使用类似于这一行代码的简单可靠的 CSS 修复 100vh 问题的方法。现在已经 2020 年了,我们仍然没有解决方案,这真是太荒谬了。
JS,但我喜欢 Hiswe/vh-check:https://github.com/Hiswe/vh-check
已测试
* 运行 Chrome 83.0.4103.106 的 Android 10
* 运行 iOS 12.4 的 iPad Mini 2
* 运行 iOS 13.5 的 iPhone SE(320 x 568vp)
-webkit-fill-available
非常有效。我解决了 Chrome 中的这种方法问题,并将该修复发布为 PostCSS 插件
https://github.com/postcss/postcss-100vh-fix
它在所有浏览器中都能正常工作,无需使用 JS。
我尝试了一下,Chrome 和 Firefox 的当前版本似乎不支持连字符。无论是 Android 还是 Windows 都一样。
当您有固定元素并打开键盘时,它在 iPhone 设备上不起作用。它会将元素向上推,而不会调整元素的视窗大小。