什么是屏幕的宽度? 100VW vs InnerWidth vs VisualViewPort.Width vs Screen.width(react)
您可以想象,我正在尝试使我的网页响应迅速且移动友好。
我有一个外部容器,在该容器上,我在该容器上动态设置宽度使用此挂钩(window.innerwidth)。因此,要测试页面是否响应响应,我打开Chrome-devtools并开始使DevTools更宽:
确保有点跳跃,但是它会按照预期的方式正确缩放。当我打开以在响应式工具中执行相同操作时,问题开始:
突然间整个页面缩小?另外,很难看到,但是我正在记录window.innerwidth
,并且在我更改宽度时并没有改变。
因此,我在手机上尝试一下,并且行为确实是出乎意料的:
负载看起来还不错
仍然按预期翻转电话,但是当我何时翻转回去???
这种疯狂的效果发生了,我的意思是现在看起来像窗口。Innerheight也遇到了一些麻烦?因为带有灰色背景颜色的容器的最小高度设置为窗口。Innerheight。如果我尝试转到应用程序的其他页面,然后返回,我得到了:
它是最后一个图像的缩放。我可以从中缩成一团。
所以我在Google周围进行了搜索,看来我找到了有相同问题的人 a 详细答案建议我应该使用window.visualviewport.width.width
而不是。因此,我尝试一下:
主要差异,调整大小似乎有点跳跃。我还记录了window.visualviewport.width
,它正在更改,但仅略微,它不与屏幕上方所示的响应性宽度相对应。
但最重要的是,不幸的是,这并没有解决整个屏幕大小的问题,并且在移动设备上的意外行为仍然存在。 (应该提到的是,如果我不处于“响应模式”,而只是调整窗口大小。
所以我发现另一个答案进一步向下建议使用window.screen.width
,所以我尝试一下:
,引入了a thoter 新型怪异的范围?比屏幕快的速度
似乎与标题具有CSS的事实有关 网格 - 板块列:130px auto 130px;
。如果我降低130px
- 值,则标题也将降低的点。我想使屏幕在标题下方的最小宽度以下会导致一些(我认为)确实出乎意料的行为。
尽管控制台日志(现在记录window.screen.width
,现在正确打印了Chromes响应工具报告的宽度。该错误可以在我的手机中看到,
此处猜猜我的手机的宽度必须低于300个像素
。 屏幕之间的差异
, innerwidth 和visualViewport.width
,如果我将响应窗口的大小设置为500px并重新加载窗口。 屏幕的任何值
所有这些都将屏幕设置为到响应窗口的宽度。
InnerWidth
和VisualViewport.width
均应评估为309px(我认为这是标头的最小功能宽度。
如果我们查看innerwidth
如何和VisualViewPort.Width
在我的电话上外观:
在visualviewport.width.width
和innerwidth
我们可以看到与一条类似于一行的行 截图中看到它)。
screen.width
(在此处可以在屏幕 img src =“ https://i.sstatic.net/6fwrkm.jpg” alt =“在此处输入图像说明”>
第一个解决方案
,因此第一个也是最直接的解决方案是使用窗口。 ),只需确保没有元素将自己推到屏幕的宽度之外
screen.width (或100VW
。 “ https://stackoverflow.com/questions/36297612/window-innerwidth-innerwidth-in-chromes-device-mode#comment12329501_36317697">视口元标记从
<meta name="viewport" content="width=device-width, initial-scale=1" />
所有
<meta name="viewport" content="width=device-width, minimum-scale=1" />
替代方案,screen.width
,innerwidth
和visualviewport.width.width
现在彼此之间的行为相同, :
他们都记录了响应窗口的正确宽度,我的手机上的页面也可以工作。如果仔细观察,您会发现当屏幕驶入309阈值以下时,标头确实会被切断。但是,使用此解决方案似乎比第一个解决方案更优雅地破裂。
因此,如果您已经解决了问题,为什么要发布此问题?
好吧,正如您现在可能已经了解的那样,我喜欢这个问题,而不是喜欢解决方案。也就是说,我真的很想知道为什么这种解决方案有效?因此,即使解决了我的“实用”问题,我对剩下的一些谜团也很好奇:
- 为什么调整窗口(第一个视频)的行为与调整Chrome Dev工具中的“响应式盒子”的行为有所不同?
- 当我倾斜手机时,为什么该错误会出现在我的手机上,然后再次将其倾斜? (第三张图片)
- 为什么(在电话上)回到某个页面并再次返回时,屏幕超级放大了? (第四个图片)
- 为什么
innerwidth
和visualViewport.width
在调整响应式窗口时继续打印相同的值。 - 他们为什么要奇怪地缩放整个屏幕,而不是以预期的方式更改屏幕的大小(由于某种原因使响应式窗口较小时会放大?代码>解决问题了吗?)
- 为什么
screen.width
与innerwidth
和visualviewport.width.width
的行为不同?为什么在低于标头的最小宽度时会引起如此怪异的白色空间效果? - 是否有任何理由不想设置
最小规模= 1
?
As you could imagine, I'm trying to make my webpage responsive and mobile friendly.
I have an outer container on which I set the width dynamically using this hook (window.innerWidth). So to test if the page is responsive I open up Chrome-devtools and start making the devtools wider:
Sure it's a little jumpy but it scales correctly, as expected. The problem starts when I open up to do the same in the responsive tools:
Suddenly the whole page scales down? Also, it's hard to see but I'm logging window.innerWidth
and it's not changing as I'm changing the width.
So I try it out on my cell-phone and the the behaviour is really unexpected:
On load it looks ok
Flip the phone, still as expected, but when I flip it back???
This crazy effect happens, I mean now it looks like window.innerHeight is having some trouble as well? Because the container with the gray background color has it's min-height set to window.innerHeight. And if i try going to some other page of the app and then back I get this:
It's a zoomed in version of the last image. I can pinche-zoom out from it.
So I google around and it looks like I find someone with the same problem there's a detailed answer suggesting I should use window.visualViewport.width
instead. So I try it out:
Main differences, the resizing seem's a little jumpier. I'm also logging window.visualViewport.width
and it is changing, but only slightly and it's not corresponding to the responsive-width that's shown above the screen.
But most importantly, it's unfortunately not fixing the problem of weirdly resizing the entire screen, and the unexpected behaviour on mobile remains. (should be mentioned that this one too, works as expected if I'm not in "responsive mode" and just resize the window.
So I spot another answer further down suggesting to use window.screen.width
instead, so I try it out:
Which introduced a whole new type of wonkyness? It seems to scale correctly, but down at around a few pixels above 300 it starts to just cut-off a piece of the header while making the container (which should be the width of the screen) smaller at a faster rate than the screen?
This seem to be related to the fact that the header has the css:grid-template-columns: 130px auto 130px;
. If I lower the 130px
-value, the point at which the header gets cut off lowers as well. I suppose making the screen go below the headers min-width causes some (in my opinion) really unexpected behaviour.
Though the console log (now logging window.screen.width
, now correctly prints the width reported by chromes responsive tool. The bug can be seen in my phone as well
I guess my phone must be a few pixels below 300 in width. Interesting fact is that using 100vw
displays exactly the same behaviour as using screen.width
.
It's also interesting to look at the difference between screen.width
, innerWidth
and visualViewport.width
. If I set the size of the responsive window to 500px and reload the window. All of them evaluates to 500px. If I set the screen to any value below the threshold where screen.width
starts to cut off a piece of the screen.
screen.width
evaluates to the width of the responsive window.innerWidth
and visualViewport.width
will both evaluate to 309px (which I assume is the minimum functional width of the header.
If we look at how innerWidth
and visualViewport.width
looks on my phone:
On both visualViewport.width
and innerWidth
we can see a much smaller but similar line to the one on screen.width
(here it can be seen on a zoomed in screenshot).
First solution
So the first and most straight forward solution would be to use window.screen.width
(or 100vw
) and simply make sure that no element ever push themselves outside the width of the screen.
But wait, another solution has appeared!
By looking at a comment to an answer of the previous question I see that someone solved it by changing the the viewport meta-tag from
<meta name="viewport" content="width=device-width, initial-scale=1" />
to
<meta name="viewport" content="width=device-width, minimum-scale=1" />
All alternatives, screen.width
, innerWidth
and visualViewport.width
all now behave identically to each other and as desired:
They all log the correct width of the responsive window, the page on my mobile also works. If you look closely you can see that the header does get cut off a little when the screen goes below the 309-threshold. But with this solution it seems like the page breaks a lot more gracefully than in first solution.
So if you've already solved the problem, why are you posting this question?
Well, as you might have understood by now, I love this problem more than I love the solution. That is, I would really like to know WHY this solution works? So even though my "practical" problem is solved I'm really curious as to a few remaining mysteries:
- Why does resizing the window (first video) behave differently from resizing the "responsive box" in chrome dev tools?
- Why does the bug appear on my mobile when I tilt my phone, and then tilt it back again? (third picture)
- Why, when I (on the phone) go into some page and back again, is the screen super zoomed in? (fourth picture)
- Why does
innerWidth
andvisualViewport.width
continue to print the same value when resizing the responsive window. - Why do they weirdly scale down the whole screen instead of changing the size of the screen in the expected way (are they for some reason zooming out when making the responsive window smaller? Is that why setting
minimum-scale=1
solves the issue?) - Why does
screen.width
behave differently frominnerWidth
andvisualViewport.width
? And why does it cause such a weird white-space effect when going below the minimum width of the header? - Are there any reason one wouldn't want to set
minimum-scale=1
?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论