- From: Bramus! via GitHub <sysbot+gh@w3.org>
- Date: Fri, 18 Nov 2022 14:36:16 +0000
- To: public-css-archive@w3.org
bramus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-overflow-4] Effect of scrollbar-gutter on viewport == Testing the behavior of various browsers wrt `scrollbar-gutter` tells me it’s not interoperable. The spec doesn’t really define what should happen, so this needs work. ## The tests All tests are being run using the dedicated test pages on https://interop-2022-viewport.netlify.app/. Using the options on each testpage, the `vw` bars have been hidden so that they don’t cause extra overflow. | | `scrollbar-gutter: stable` (short content) | `scrollbar-gutter: stable` (long content) | `scrollbar-gutter: stable both-edges;` (short content) | `scrollbar-gutter: stable both-edges;` (long content) | |-|-|-|-|-| | Firefox 107 on macOS | <img width="976" alt="image" src="https://user-images.githubusercontent.com/213073/202724250-790e61ec-d2de-45b0-947c-9107a1b6e8e8.png"> | <img width="976" alt="image" src="https://user-images.githubusercontent.com/213073/202724295-75139ed4-7038-402b-bcbf-df2935f1d52b.png"> | <img width="976" alt="image" src="https://user-images.githubusercontent.com/213073/202724317-e0ce9b88-76ce-464e-a558-2f9e5485230f.png"> | <img width="976" alt="image" src="https://user-images.githubusercontent.com/213073/202724342-de4ca2f6-cd04-48bf-b808-948ed7e7d910.png"> | | Chrome 110 on macOS | <img width="976" alt="image" src="https://user-images.githubusercontent.com/213073/202724509-148458c3-953e-4465-8171-380bd4bfdf5e.png"> | <img width="976" alt="image" src="https://user-images.githubusercontent.com/213073/202724522-cb8b6b4e-69da-4926-b3ed-a9bb56b91112.png"> | <img width="976" alt="image" src="https://user-images.githubusercontent.com/213073/202724538-b20f14bd-489e-4e6f-a9df-519d4a11e617.png"> | <img width="976" alt="image" src="https://user-images.githubusercontent.com/213073/202724556-c4d2f5fa-11fc-4702-9c25-02f200513c46.png"> | | Safari TP 158 on macOS | _no support_ | _no support_ | _no support_ | _no support_ | _(I’ve only had time to test desktop browsers with support on macOS with scrollbars set to always visible)_ ## Findings - Firefox 107 - Always resizes the ICB. - Always repositions the ICB. - Always resizes the LVP. - Never repositions the LVP which doesn’t play nice with `stable both-edges` and the fact that the LVP gets resized. - Chrome 110 - Always resizes the ICB. - The reported value through `document.documentElement.clientWidth` is wrong, though. - Always repositions the ICB. - Only resizes the LVP if scrollbars are actually there. - Only repositions the LVP for `stable both-edges` when the scrollbars are actually there. - Safari TP 158 - No support ## Expected results - I would expect browsers to resize the ICB, so that things like viewport units remain stable. This is currently correct in all browsers. - Currently browsers don’t take this upfront change into account when calculating the size of the viewport units. This is a separate discussion: https://github.com/w3c/csswg-drafts/issues/5254 - I would expect browsers to only resize the layout viewport when the scrollbars are actually present. This way it’s possible for a fixedpos element to cover the entire viewport. ```css el { position: fixed; inset: 0; } ``` If the LVP were to be resized when no scrollbars are visible, an author would not be able to cover the entire viewport in case `stable` is used: there would be a small strip visible on the scrollbar area. - I would expect browsers to not reposition the layout viewport – not even when `stable both-edges` is used. This again for fixedpos element purposes. If the LVP were to be repositioned, an author would not be able to cover the entire viewport in case `stable both-edges` is used: there would always be a small strip visible on the opposing side of the scrollbar area. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8099 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 18 November 2022 14:36:18 UTC