- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Apr 2021 17:02:22 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow] scrollbar-gutter should not do anything for non-scrollable boxes`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-overflow] scrollbar-gutter should not do anything for non-scrollable boxes<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/6028<br> <dael> emilio: A bit confused<br> <dael> emilio: How scrollbar gutter applies to thing with overflow visible or clip<br> <dael> emilio: That's interaction with a lot of layout models and it's not defined. I think should be defined on scrollable boxes and that's it<br> <dael> florian: Not dismissing challenge. Good reasons why proposed to work this way<br> <dael> florian: Some examples might be in spec, some in issue. One example of why you want to apply to not scrollable item is like gmail UI<br> <smfr> q+<br> <dael> florian: You have icons in each email and icons in header above list and you want to visually align. Where the icons will be depends on if that part has a gutter. Depends on if scrollbars are overlay or classic. Element that is not scollable but next to and you want visual alignment you need to say give me a gutter that's the same size so I have the same space<br> <dael> emilio: Could that be env variable?<br> <dael> florian: Was suggested. Not easy. First, wouldn't be env variable but a unit b/c have scrollbar width that lets you change the size. With an env variable you don't have the size b/c context based it changes<br> <dael> florian: Also, a whole bunch of them. In the issue. You can't know if scrollbar will be on left or right. Might be decision based on bidi or OS design<br> <dael> florian: As author you would need a pile of env variables or more likely units to know side, size<br> <emilio> q+<br> <dael> florian: Another point is there's a couple of aspects of scrollbar gutter suggested to be variables or units but need different ones. Some use cases need size of classical scrollbar and some other usecases where you want 0 with classical and overlay with new.<br> <astearns> ack smfr<br> <tantek> while I agree with the theoretical use-cases of aligning stuff in/on a nonscrollable box with a subsequent (or previous) scrollable box with gutter, has anyone actually seen this in practice? didn't see any links to real world examples in the issue<br> <tantek> e.g. is this for table header on top of a scrollable table body?<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to propose we close this as 'scrollbar-gutter applies to all elements to which overflow applies'<br> <dael> smfr: I find it weird we would have a property like this that adds eq to padding or margin. It's almost like spacer.gif. Weird way to add layout space. Sympathize with need to match, but would think use of scrollbar gutter should be limited to where scrollbars appear<br> <dael> fantasai: Want to suggest we solve bymaking applies to be all elements to which overflow property applies. Avoids explicit list in this propdef table and tie them together. Doesn't mean you are assigning overflow scroll<br> <dael> emilio: I think more tricky to impl. Overflow applies to a lot of things in SVG and whatnot<br> <dael> TabAtkins: Applies only to flip between visible and hidden. Can be more precise<br> <dael> emilio: Maybe<br> <astearns> ack emilio<br> <fantasai> s/precise/precise, say only elements to which 'overflow: scroll' applies/<br> <dael> emilio: Reply to florian is you need context for which side scrollbar is on to solve adding spacing. Also true with scrollbar gutter. If element is RtL then either your element needs to be RtL or something needs to happen. That's not well defined in scrollable but not defined in non-scroll<br> <dael> emilio: You need all the context scrolling box has and need it to match. Having env variables; way FF UI does this you have MQ for overlying scrollbars and then scrollbar width- for overlay there's a MQ<br> <dael> emilio: I think it's only 2 widths and if they're overlay. That's the 3 bits of state. Sides is trickier but scrollbar gutter doesn't fix it<br> <dael> florian: Depends on varables. Case of matching nearby I agree doesn't change. Other things it would simplify with env variables and in those you need size. I feel this is a topic for a F2F with a whiteboard<br> <dael> emilio: Maybe. Generally feel scrollbar gutter applying to non-scrollable will lead to itnerop issues<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to comment on rtl<br> <dael> fantasai: Side comment that having the scrollbar switch side on rtl or ltr is probably not great user interface b/c want consistent side. There are impl that do this, though<br> <dael> dbaron[m]: FF for a time had a hidden preference to change that and some users cared very deeply about that preference<br> <dael> florian: I think overall point in the general sense it is not trivial to replace with 1 or more variables.<br> <fantasai> s/though/though. E.g. Firefox uses OS direction, whereas Chrome uses element direction/<br> <dael> florian: There are use cases underlying all use cases and the proposed value to add. May be true some are impractical to impl. That is new information to me and should investigate. Reject it's simplier to make it 2 variables and that there's not a use case<br> <dael> astearns: Have been hearing use case is not strong enough to justify complication of adding scrollbar gutters to things that cannot scroll<br> <tantek> regarding changing "Applies to:", another option to consider is what scrollbar-width says: https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width "Applies to: boxes to which overflow applies"<br> <felipeerias> q+<br> <tantek> +1 astearns<br> <smfr> q+<br> <fantasai> WG discussion to add the 'force' value to scrollbar-gutter: https://lists.w3.org/Archives/Public/www-style/2017Feb/0059.html<br> <dael> emilio: No concerns about it as a property that applies to scrollable things. Proposed values seemed fine when I went through<br> <dael> astearns: tantek has suggestion in IRC that I believe is similar to fan<br> <astearns> ack felipeerias<br> <tantek> s/to fan/to what fantasai suggested<br> <dael> felipeerias: conceptually I agree force value is a bit weird. Want to align to container with scrollbar with you set scrollbar-width:thing to non-scrollable. Agree it's weird. Problem with scrollbars if they have logic that depends on OS. Either you have something like scrollbar-gutter where you give value or you make the complexity visible to the web author so you have MQ to know about overlay or classical, maybe a selector to know side<br> <dael> felipeerias: Trade off. I understand some of the concerns and they are reasonable<br> <astearns> ack smfr<br> <dael> smfr: Emphasize WK position; whole point of overlay scrollbars is to max space for content. Not a fan of encouraging authors to reserve space. Want to allow authors to move interactive elements from under scrollbar, but fine for text to go there<br> <tantek> How is text not an interactive element? E.g. text selection<br> <dael> smfr: General policy is not to encourage authors to avoid that edge. We'd prefer things like env variables that authors can apply to specific elements<br> <dael> florian: If we want env variables to replace force and allwidth we need different varables. They're opposites. I'm concerned about explosion of units<br> <dael> fantasai: Note we had discussion on these lines so might be worth looking at that<br> <florian> s/allwidth/always/<br> <tantek> clear: scroll-gutter :P<br> <dael> myles: Goal is not to have a formulation of units. Goal is move indiviual elements. If there's a design solution without a pile of variables would be great.<br> <chrishtr> q+<br> <dael> florian: If we decide some usecases have bad tradeoff between desireable and complex I think that's okay. might regret. The claim we can just replace with an env variable, though, we can't 'just' if we want to solve all the things that the solution does now.<br> <astearns> ack chrishtr<br> <dael> chrishtr: Looks like we've expanded to not just case from emilio but subsiquent issues about removing always. I think it would be okay to remove always and maybe also do what emilio suggests b/c solves some use cases that we have most consensus on and then we can consider solutions for other use cases in the future<br> <bmathwig> +q<br> <dael> astearns: That is one possibility<br> <dael> florian: I don't have an issue with UAs prioritizing a more easily doable subset of property. As long as we don't rule out some use cases worth exploring whole design. If we say we'll do this and solve the rest with varables and then discover we can't that would be unfortunate.<br> <dael> chrishtr: I don't htink it would conflict. Subset, emilio's point needs to be edited in. Only applying to scrollable elements<br> <dael> florian: Means removing force value. You can't support that value w/o applying to other elements<br> <astearns> ack bmathwig<br> <dael> bmathwig: From Edge standpoint and based on our use cases I would propose keeping always and auto and discard the rest. Overlay vs classical we don't have use cases for sable, both, or force<br> <dael> florian: Not stable? Surprised<br> <dael> bmathwig: If dev doesn't include gutter it's assumed auto so scrollbars overtake. And always they want space cross platofrm and browser to avoid special casing.<br> <dael> astearns: bmathwig I suggest you put those details into issue #4674. We should add details and we'll bring them back next meeting to see if we can get to resolution<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6028#issuecomment-824216850 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 April 2021 17:02:25 UTC