- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Aug 2017 17:02:48 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Should viewport units still depend on scrollbar width for overflow:scroll?`.
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: Should viewport units still depend on scrollbar width for overflow:scroll?<br>
<tantek> because: <dael> jensimmons: I'm fine punting to next week.<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/1766<br>
<dael> astearns: We're waiting on impl feedback?<br>
<dael> TabAtkins: Yes, I'm getting ?? to comment.<br>
<zcorpan_> (Could css-meeting-bot remove the label when it's commenting?)<br>
<astearns> it does when we resolve something<br>
<dael> dbaron: I reised this bc gecko was the only engine that impl when we decided this years ago. It's apperently harder to do on silo. I think it's reasonable on their part.<br>
<dael> myles: If all browers except Moz ones don't support and MOz wants to remove it seems clear<br>
<dael> TabAtkins: Without this feature there's alot of cases where viewport is broken. THere are plent that do, but I suspect people are avoiding these thigns. You cannot get 100vw to be the size of the screen. THere's usually a scrollbar and 100vw is too big.<br>
<dael> myles: The desc says it's only on sroll not auto<br>
<dbaron> s/silo/stylo/<br>
<dael> TabAtkins: We decided viewport should be resolved at computed. For overflow auto we decided to ignore scrollbar, but w wanted to pay attention when it's there. overflow:scroll causes a scrollbar so we set it to take scrollbar into account in that case.<br>
<dael> myles: Overflow:Scroll on root is not common case<br>
<Florian> q+<br>
<dael> TabAtkins: I agree. But when your scrollbar appears your items to 100vw will overflow horz and cause a scrollbar. The way we decided to let tha tbe solve dyou can set overflow scroll on it explicitly so it fits. Without this viewport units are just broken. The only time they add to the viewport is when you have no scrollbar which is uncommon<br>
<dael> fremy: You still need to know size of scrollbar. It's not a static number.<br>
<dael> Rossen: We're talking about uint value. I'm with TabAtkins. If in the case of overflow: scroll when scrollbar takes spec away from viewable viewport current spec mandates the correct behavior from user PoV. viewport should resolve to are-scrollbars.<br>
<dael> Rossen: Changing spec for interop and going aaginst what makes sense isn't best.<br>
<astearns> ack Florian<br>
<dael> Florian: If we don't drop the thing should we extend it? Even if it's auto?<br>
<dael> TabAtkins: Prob should. Assuing whatever element applies to root scroller. If that works and we define how that would help.<br>
<dael> Rossen: I would argue against that. THe elemnt causing the scrollbar could be defined in vh unit which causes scrollbar and introduces a dependency. IN the case of overflow scroll on the viewport we only need to add computed value and resolve overflow for the root. From there on decide what he value will be.<br>
<dael> fantasai: No one is suggesting auto for scrollbar. There's a scrollbar gutter property that adds extra space.<br>
<dael> Rossen: I was reading the minutes from Florian about perhaps extending to auto.<br>
<Florian> https://drafts.csswg.org/css-overflow-4/#scollbar-gutter-property<br>
<fantasai> Florian was asking about scrollbar-gutte rproperty<br>
<dael> TabAtkins: It's only when you ahve a predicatble value to auto<br>
<fantasai> s/should we extend it/should we extend it to handle the scrollbar-gutter property/<br>
<dael> Florian: Even though you get that you get a predictable size with space reserved but not scrollbar so maybe that shouldn't count. I don't know.<br>
<astearns> q+<br>
<dael> Rossen: Let's assume simple l to r. Whatever an element with abspos top 0 right 0 wherever that positions to shoudl be extent of vh<br>
<dael> TabAtkins: No because then by default auto changes value of vw unit and that defets the computed value time purpose<br>
<dael> Rossen: No in the cae of the gutter we're talking about the prop reserving space for gutter<br>
<dael> TabAtkins: If gutter is predictable yet<br>
<dael> Rossen: That's what I'm talking about. So if abspos items are positioned to gutter this should be extent of vh as well?<br>
<dael> Florian: I don't think we explicitly define it may fall out of the wording, but I don't htink that was concious decision.<br>
<dael> Florian: I don't think we decided on that<br>
<dael> astearns: Is that enough on the gutter sidebar?<br>
<Rossen> q?<br>
<dael> Florian: I think we need to come back, but not for this call.<br>
<dael> astearns: I want to go back to the discussion before gutters where...I agree that vw should take the scrollbar into account where it exists. But the one piece of impl feedback on that is it's really annoying to have to layout arbitrary things when you gain a scrollbar. Would it make sense to define auto same as scroll case for vw? It's always taking into case poss scrollbar?<br>
<dael> TabAtkins: If you have overflow: hidden on root vw doesn't stretch all the way across the screen.<br>
<dael> Florian: Just auto.<br>
<dael> TabAtkins: No, still hidden. Just changing auto doesn't fix dbaron problem. He didn't want size of vw change based on somebody updating [missed]<br>
<dbaron> I think there were actually 2 issues.<br>
<dael> TabAtkins: Change at all is the worry. Main responce is this is no different hen m unit. You change the font and everything below has to change. Only more complicated is that sometimes body can set viewport. So you can effect one element up.<br>
<Rossen> dbaron, can you pls summarize?<br>
<dbaron> One was that dynamic changes to 'overflow' are hard, but that the other is that in Gecko, we need to depend on layout to find out what the scrollbar width is.<br>
<dael> TabAtkins: Aside from that one element jump which is very rare and not important for purpose of tree expence this is identical to setting font size.<br>
<dael> TabAtkins: You dont' need layout this is computed value time<br>
<dael> dbaron: Second thing that made it had is in gecko it's not ready.<br>
<dael> dbaron: [missed]<br>
<dael> dbaron: I'm not even sure it worked rilably. I think it worked most of the time because usually we constructed scrollbars first.<br>
<dael> TabAtkins: Is that b/c scrollbar width is controllable in FF?<br>
<dael> dbaron: It depends on too many OS dependant and that code exists in scrollbar layout.<br>
<dael> TabAtkins: Yeah.<br>
<dael> dbaron: It's possible that the number of things to test is 2 or 3, but that's not the way it was written<br>
<Rossen> wouldn't webkit-scrollbar {width} have the same effect?<br>
<dael> astearns: We're at time. i'm hearing the desire to keep spec behavior as-is, but we'll need other impl to make the changes. WE should continue impl feedback in the issue. We're out of time today, we'll talk next week.<br>
<TabAtkins> s/Yeah./So maybe just moving the code up and piping the data down into layout instead./<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-326055226 using your GitHub account
Received on Wednesday, 30 August 2017 17:02:45 UTC