Re: [csswg-drafts] [css-values] Should viewport units still depend on scrollbar width for overflow:scroll?

The Working Group just discussed `Should viewport units still depend on scrollbar width for overflow:scroll?`, and agreed to the following resolutions:

* `RESOLVED: Drop the requirement to subtract scrollbar size from vh/vw units for overflow scroll`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Should viewport units still depend on scrollbar width for overflow:scroll?<br>
&lt;dael> Github: https://github.com/w3c/csswg-drafts/issues/1766<br>
&lt;dael> Rossen_: Can anyone take this?<br>
&lt;dael> TabAtkins: I'm here.<br>
&lt;dael> TabAtkins: This may not be decided yet. Core of the issue is, vw and vh we spec that if you do overflow scroll on root scroller we take into account size of scrollbar so 100vw fills the visual viewport<br>
&lt;dael> TabAtkins: FF has broken code for this, Servo isn't planning on doing it. We, Chrome, don't do it either. dbaron is asking if we can remove that so vw and vh are based on ignoring scrollbar. My org obj is that distroyed usefulness of these and we decided aut would default to no scrollbar size.<br>
&lt;dael> TabAtkins: After we thought more for layout you don't need...I don't htink many if any vw cases need 100 to be exactly the right size. You can use flexbox or gird for simimlar or better. For otehr things with iewport limits such as scaling fonts, they're fine with a little off<br>
&lt;dael> TabAtkins: I could be convinced that vw are lower fidelity.<br>
&lt;dael> fantasai: I'd ask aorund a bit more. I can imagine wanting something to fill the viewport when you click. Doing layout of sizing of tables if they're too big to wrap them in their own scrollbar. i can see cases.<br>
&lt;dael> TabAtkins: I'd like to see examples that aren't solved in other ways. I should look at the table case again.<br>
&lt;dael> smfr: The author of the webkit blog came asking about this He wanted his viewport to be full bleed and 100 vw was triggering full scrollbars<br>
&lt;dael> smfr: This is only an issue for always on scrollbars.<br>
&lt;Rossen_> position:fixed; left:0; right:0; top0; bottom:0;<br>
&lt;Rossen_> :)<br>
&lt;dael> TabAtkins: I suspect that's why it didn't make it into webkit and then chrome inherited that code.<br>
&lt;dael> TabAtkins: You seem to be arguing we should keep spec as-is so it an respond to scrollbars?<br>
&lt;dael> smfr: Not nec. Independantly we should htink of ways to solve this.<br>
&lt;dael> fantasai: We should solve it with these units. If we don't how do we fix this? Another unit?<br>
&lt;dael> Rossen_: fwiw we don't support in edge or ie either. I'm in support of what TabAtkins said and his rational. At the same time I sympathize with fantasai were if we're going to have units to enable this, this is the unit.<br>
&lt;Florian> Remaining CSS-UI Bugs on mandatory requirements with less than 2 implementations:  https://pastebin.com/vu1CCTMv<br>
&lt;dael> Rossen_: Sounds to me like none of the impl have it and the only one with it wants to drop and it's broken. If we allow scrollbar styling that would have more severe effects for how we resolve scrollbar width. What are we doing.<br>
&lt;dael> Rossen_: Options are vw always resolved to full viewport ignoring scrollbars. For most scenarios you know how big the iewport is and if you care about scrollbars you can do calc and subtract.<br>
&lt;dael> myles: You can do better with dino's proposal from the last f2f.<br>
&lt;dael> Rossen_: Even better. Love it. That's a great option once we have it.<br>
&lt;fantasai> s/subtact/subtract some pixels/<br>
&lt;fantasai> s/f2f/f2f. One of those variables can be the scrollbar width/<br>
&lt;dael> Rossen_: Those are the options I see, what do we do?<br>
&lt;dael> myles: Sounds like there's agreement to drop.<br>
&lt;fantasai> :(<br>
&lt;dael> Rossen_: Agreed. Obj?<br>
&lt;fremy> fine with dropping<br>
&lt;dael> RESOLVED: Drop the requirement to subtract scrollbar size from vh/vw units for overflow scroll<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1766#issuecomment-327642426 using your GitHub account

Received on Wednesday, 6 September 2017 23:47:13 UTC