- 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