- From: Bramus via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Nov 2023 13:48:39 +0000
- To: public-css-archive@w3.org
Some situation that came to mind today: 1. Say the window’s `innerWidth` is 1000px. After subtracting the scrollbar-width _(assuming a classic `16px`)_ that would have `100vw` be computed to `984px`. 2. Now say on the page you have a scrollable `<div>` with a width of `50vw`. Taking half of `984px`, that would give it a width of `492px`. Because of its scrollbar, there’s “only” `476px` available space inside of it left though. 3. Now comes the part where authors might get tripped up: if they then size something inside that `<div>` to be `50vw`, they will end up with a horizontal scrollbar again, as the computed width is `492px` and not the leftover `476px`. If you know what’s happening that is expected behavior, yet it might trip up some authors. It also underlines that this automatic subtraction only solves the `100vw` case on the root scroller. A solution with an envvar would allow fixing all those cases, but puts the burden on the author to take it into account. Related to the third bullet point above: in that case, maybe we should also do the same for `100cqi` with the same conditions on the container? Demo: https://codepen.io/bramus/pen/rNPqOZe -- GitHub Notification of comment by bramus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6026#issuecomment-1833818113 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 November 2023 13:48:41 UTC