浏览器 vw 单位与滚动条

浏览器视口

简单理解就是浏览器中用于浏览内容的区域,浏览器界面什么页签、菜单、开发者工具都去掉的部分,如下:

在 css 当中,浏览器的视口尺寸可以通过 100vw 与 100vh 来获取。在不出现右侧滚动条的情况下,给一个元素设置 width: 100vw ,它就会铺满整个浏览器窗口内容。例如图中的 div

100vw 下的滚动条问题

当浏览器视口高度不足以完整显示 div ,出现右侧滚动条时,底部滚动条也会一同出现。这是因为 div 宽度 100vw 在浏览器尺寸和缩放不变化的情况下是个固定值,而页面右侧滚动条的出现使得 div 实际能够显示的区域小于 100vw ,导致底部的滚动条

而如果将 div 宽度 100vw 变成 100% ,底部滚动条就会消失(父元素 body 默认会占满整个视口,但是出右侧滚动条时,就会让出滚动条的空间)。如果没有右侧滚动条,给 div 设置 100% 和 100vw 的效果是一样的。

在出现右侧滚动条时,如果设置 div 宽度为 width: calc(100vw - 100%) ,我们就能拿到一个和当前右侧滚动条宽度一致的 div

如何使用 100vw 并且规避滚动条问题

一般用到 100vw 的时候都是想元素自动撑满浏览器视口。虽然 100% 能比较好得解决滚动条,但是当出现深层嵌套的时候,我们就要把元素的父元素挨个设置成 100% ,可以但不算体面。而解决这个问题的办法呢,也没有太好,就利用 calc 计算 width: calc(100vw - 滚动条宽度值)

有些方法诸如设置 max-width: 100% 来限制元素宽度,或者 calc(100vw - 100%) 获取滚动条宽度再计算,这种方式能起效的前提是父元素已经能够撑满整个视口,那既然如此,何不直接设置 width: 100%

视口尺寸的补充

100vw 的值等于 window.innerWidth ;同理,100vh 等于 window.innerHeight 。如果去缩放内容,innerWidth 的值也会等比例变化,但是用于标定浏览器宽高的值 window.outerWidthwindow.outerHeight 就不会随着缩放变化。

而非常有意思的是,在 win11 1080P Chrome100% 比例下:

  • 浏览器未占满屏幕,outerWidth - innerWidth = 16
  • 浏览器占满屏幕, outerWidth = innerWidth = 1920
  • 浏览器 F11 全屏,outerWidth - innerWidth = -16

这个多出来的正负 16 是浏览器的哪部分?猜测是浏览器边框的阴影效果的宽度,但是这个 -16 看起来就非常诡异。

相关推荐
用户059540174461 天前
大模型长上下文遗忘排查实录:用 Playwright 自动化测试,揪出了 90% 的存储序列化 bug
前端·css
天蓝色的鱼鱼2 天前
关于 CSS 你可能不知道的属性,但关键时刻很有用
前端·css
用户059540174462 天前
向量库静默丢数据踩坑实录:Playwright 端到端测试让我排查了72小时
前端·css
ZhengEnCi3 天前
Q06-导航按钮高级拟态玻璃效果构建完全指南
前端·css
用户059540174463 天前
Redis持久化踩坑实录:这个数据丢失Bug让我排查了6小时
前端·css
用户059540174464 天前
Redis记忆存储故障恢复测试踩坑实录:手动测试让我漏掉了2个一致性Bug
前端·css
用户059540174464 天前
用了3年Mock,才发现Redis记忆存储的测试一直漏掉了60%的边界场景
前端·css
用户059540174465 天前
用了6个月LangChain,才发现AI Agent的记忆存储一直有坑——写了23个Pytest用例才彻底修好
前端·css
用户059540174465 天前
把LLM记忆测试从手工脚本换成Pytest参数化,回归时间从2小时降到10分钟
前端·css
用户059540174466 天前
Redis缓存一致性踩坑实录:线上故障排查6小时,我用pytest+内存快照把它永久关进了笼子
前端·css