- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 05 Jul 2018 09:54:39 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Scrollbar width`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Scrollbar width<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/1958<br> <fantasai> plinss, text-decoration-skip: objects<br> <TabAtkins> tantek: We had a rough consensus among people who cared to add a scrollbar-width property.<br> <TabAtkins> tantek: We think it's implementable.<br> <TabAtkins> tantek: Wanted to bring it to people's attention in case there are opinions.<br> <TabAtkins> tantek: This is one of the key things I wanted to resolve one way or the other before fpwd. Other was color properties.<br> <TabAtkins> heycam: This sets the maximum width? Why?<br> <TabAtkins> astearns: That was some feedback from Xidorn where the UA might want to display something smaller sometimes...?<br> <TabAtkins> tantek: Right. You might want to limit how wide a scrollbar can be, but not force platforms that do narrower ones to draw wide.<br> <TabAtkins> frremy: scrollbar-max-width?<br> <TabAtkins> myles: Worried for two reasons.<br> <TabAtkins> myles: First is macos scrollbars have two widths, they switch between.<br> <TabAtkins> myles: Such a model can't express that.<br> <TabAtkins> myles: Second is that on windows, scrollbar widths will change if you're using touch or not.<br> <TabAtkins> myles: So that also doesn't fit with this property<br> <TabAtkins> myles: Also, OS should be the one that sets these complicated models, not websites.<br> <fantasai> TabAtkins: A lot of websites have very narrow scrollbars, and that is exactly the reason why they are using non-native scrollbars<br> <TabAtkins> tantek: You brought up a good reason for the max treatment.<br> <TabAtkins> tantek: Platforms can switch between widths *within* the property's value.<br> <TabAtkins> tantek: so like on macos it starts small and gets bigger on hover - you can still do that with max-width.<br> <TabAtkins> frremy: When it gets bigger it's overlay, right?<br> <TabAtkins> myles: When you're using non-overlay scrollbars, it doesn't change size on hover.<br> <TabAtkins> frremy: So the width should just be the layout size<br> <TabAtkins> tantek: Maybe the size is jsut the initial size, the expanding can ignore that?<br> <TabAtkins> myles: Problem is just that there's already three modes on macos, i worry about letting pages control this.<br> <TabAtkins> astearns: Not allowing this property doesn't save users from terrible scrollbars. Pages will use custom (terrible) scrollbars.<br> <TabAtkins> astearns: This jsut lets them specify a max width, you can still do nice native scrollbars.<br> <TabAtkins> xidorn: I guess myles' point is whether the width should apply to overlay scrollbars, which I'm not sure.<br> <TabAtkins> xidorn: I discussed with tantek before, and thought it should be applied to overlay as well.<br> <TabAtkins> xidorn: But then we have problems - it may restrict the ability to expand the scrollbar.<br> <heycam> q+<br> <TabAtkins> myles: One other piece I want to mention is that setting this property shouldn't force scrollbars to be take up layout space.<br> <TabAtkins> tantek: It doesn't.<br> <TabAtkins> xidorn: It might make the layout space *smaller*.<br> <TabAtkins> xidorn: Whether this should apply to the appearance of overlay scrollbars is another issue.<br> <astearns> ack heycam<br> <TabAtkins> heycam: What is the use-case for allowing a specific width to be specified, and whether it's sufficient to just request "thin"?<br> <TabAtkins> myles: So if our users select that they want scrollbars to take up layout space, we don't have a thinner version.<br> <TabAtkins> q+<br> <frremy> q+<br> <TabAtkins> tantek: I think the problem to solve is that users are creating a totally new scrollbar just to make it thinner. The work there is suboptimal due to usability.<br> <TabAtkins> tantek: Hope is that we can reflect the underlying platform's behavior better.<br> <fantasai> tantek: ...<br> <TabAtkins> myles: I'm sympathetic to the idea that giving authors a way to get the behavior they want without building it themselves is better.<br> <TabAtkins> myles: I'm not very convinced that this will be the impetus to stop building things themselves.<br> <tantek> q+ to note perhaps we can *add* 'thin' as a keyword so authors can ask for a thin scrollbar without having to worry about specific pixels per platform?<br> <TabAtkins> Rossen: From xidorn's comment; if i set the max-width, at least we're going to affect the layout size<br> <TabAtkins> Rossen: If that exceeds the width of the scrollbar, that'll be weird.<br> <TabAtkins> TabAtkins: That's why it's a max width.<br> <TabAtkins> Rossen: So it doesn't go above the visual width of the scrollbar. With hidey-scrollbars, the width stays at zero.<br> <astearns> ack TabAtkins<br> <TabAtkins> [something from me]<br> <TabAtkins> tantek: Side issue - there are a lot of people discussing on the issues *demanding* the webkit model. If there was a canonical link I could point people to, it would be useful.<br> <xidorn> q+<br> <astearns> ack frremy<br> <TabAtkins> frremy: I think the more recent proposal was for having a "thin" keyword sounds good. And if they want "thin", maybe use overlay for that specific element?<br> <TabAtkins> frremy: REquest we get often is that people want dark scrollbars, and people want tinier scrollbars.<br> <fantasai> s/scrollbars/scrollbars, for things like chat windows/<br> <TabAtkins> frremy: So yeah, maybe rather than a specific size, we just have a "thin" keyword that opts into the OS's smaller version.<br> <TabAtkins> myles: So let's pretend I'm on gtk linux that only has one size...<br> <TabAtkins> frremy: Then it's just the one size, that's an OS size<br> <TabAtkins> s/size/limitation/<br> <TabAtkins> myles: So this can't be tested?<br> <fantasai> TabAtkins: We try to minimize manual tests, but it's not a case of if it's notpossible to machine test it doesn't exist.<br> <astearns> q?<br> <TabAtkins> myles: So what happens if you test on an OS that only has one scrollbar size?<br> <TabAtkins> tantek: It passes.<br> <TabAtkins> myles: So author has to know what all the platforms do...?<br> <TabAtkins> TabAtkins: Don't worry about GTK, everyone uses macos, windows, or chromeos. ^_^<br> <TabAtkins> dbaron: And GTK *does* have two widths anyway.<br> <astearns> ack tantek<br> <Zakim> tantek, you wanted to note perhaps we can *add* 'thin' as a keyword so authors can ask for a thin scrollbar without having to worry about specific pixels per platform?<br> <TabAtkins> tantek: So if we just add a thin value we can see what feedback we get.<br> <TabAtkins> TabAtkins: I'd accept that in my use-case, yeah.<br> <Rossen> q+<br> <fantasai> ...<br> <fantasai> tantek: A lot of what we do is replace JS hacks.<br> <astearns> ack xidorn<br> <TabAtkins> xidorn: I'd like to raise that there was actually another use-case I'd like to solve with scrollbar-width<br> <TabAtkins> xidorn: Some authors just want to make their own scrollbars, and want to make the native be hidden, but still be scrollable.<br> <TabAtkins> xidorn: I think that's a reasonable use-case as well. Even if their custom is terrible, it's still better than "overflow:hidden".<br> <fantasai> TabAtkins: Rich Byers had some proposal for having a scroller but without a visible scrollbar<br> <fantasai> ScribeNick: fantasai<br> <astearns> ack Rossen<br> <fantasai> Rossen: Couple points, the first one is for the lenght value<br> <fantasai> Rossen: If we were going ot go with a length value as it's currently specified<br> <fantasai> Rossen: There has to be some affordances, or at leats explain how scaling works<br> <fantasai> Rossen: E.g. in Edge we go to a great extent to make sure that the frame scrollbars never scale as you pinch-zoom, so that your scrollbar doesn't take over the entire surface of your device<br> <fantasai> Rossen: At the same time, content will scale<br> <fantasai> Rossen: So already a discrepency at least in our case<br> <fantasai> Rossen: between scrollbars attached to the frame and the content in the frame<br> <fantasai> tantek: gestures or other zoom?<br> <fantasai> Rossen: For browser zooms, we always keep the same scrollbar size as every other scrollbar in the system<br> <fantasai> Rossen: Not expecting any action, but it has to be considered<br> <tantek> s/other zoom/other zoom like zoom property<br> <fantasai> Rossen: The other thing is that scroll spec started off that you have a lot of interop bugs that were being reported to you and since the last time we talked about this<br> <fantasai> Rossen: couple things I realized<br> <fantasai> Rossen: Firstly, we removed all styling of scrollbars in Edge 4 yrs ago<br> <fantasai> Rossen: and we have absolutely no bugs reported to us about styling scrollbars<br> <fantasai> Rossen: so curious where we're going with this<br> <fantasai> frremy: Actually, we keep getting bugs from Outlook complaining to us about this.<br> <fantasai> ...<br> <fantasai> Rossen: To myles's point, ppl want more control<br> <fantasai> Rossen: Are we tryng to go more towards this model, or try to lock it down?<br> <fantasai> Rossen: thin/medium/thick scrollbars and some colors and leave it there<br> <fantasai> tantek: The hope is that a small number of properties is enough to satsify users<br> <fantasai> tantek: There are sites that will outright block browsers based on support for scrollbar styling<br> <fantasai> myles: New thing won't solve existing problem?<br> <fantasai> tantek: They're putting effort into trying every possible way to style the scrollbars, so expect they'll update with new thing if it's available<br> <fantasai> myles: Sites are saying that color of the scrollbar is so important they'd rather people not use their service?<br> <fantasai> tantek: Yes.<br> <tantek> https://www.w3.org/wiki/Css-scrollbars#Sites_blocking_browsers<br> <fantasai> xidorn: It's not so much about specific colors, but e.g. they have a dark interface and they don't want light scrollbars<br> <tantek> https://webcompat.com/uploads/2017/7/96051d95-3863-4285-8b02-245403aeb160-thumb.jpg<br> <fantasai> Rossen: I think the keyword values would be better<br> <fantasai> Rossen: Either adding or replacing <length><br> <fantasai> myles: Scrollbars are a evolving technology<br> <fantasai> myles: A few years ago MacOS scrollbars had up/down arrows<br> <fantasai> myles: Then we went to overlay and dropped the arrows<br> <fantasai> myles: Then went to two different overlay<br> <fantasai> myles: Windows has similar evolution<br> <fantasai> myles: You need to consider how this works with all of the complexity today, and also how it could work in the future<br> <fantasai> tantek: I agree with that, and been resistent to speccing this in general<br> <fantasai> tantek: So trying to figure out with specific use cases<br> <fantasai> tantek: As much as scrollbars have evolved, some way to control color has been constantly desired. Same with width<br> <fantasai> tantek: I would agree with your statement of being mindful of the future.<br> <fantasai> tantek: Question is, do folks want a thin keyword?<br> <fantasai> astearns: Choice is between having width that allows for zero, or having at least two keywords<br> <fantasai> astearns: thin/none/auto<br> <fantasai> Rossen: Can we take the length value out of the picture?<br> <fantasai> astearns: So do we have <length> or thin | auto | none ?<br> <TabAtkins> fantasai: If you wanna get rid of the scrollbar you can put it to 0 or none, same effect.<br> <TabAtkins> fantasai: But what do you mean by "thin"? If the author is caring about the width fo the scrollbar, they want it to be narrower than a particular amount.<br> <TabAtkins> astearns: Tab's use-case was fine with "thin".<br> <TabAtkins> fantasai: So what if scrollbars are 10px by default, but a thin version is 5px. They say "thin". But then later scrollbars default to 5, and thin is 2px, it's smaller than they intended!<br> <fantasai> TabAtkins: If it's 10px and 5px for thin, and author says 6px it's fine, it'll choose 5px one<br> <fantasai> TabAtkins: Late rOS change such that it's 8px and 3px, it'll go down to only 3px<br> <tantek> q?<br> <tantek> q+ dbaron<br> <TabAtkins> frremy: I don't think scrollbars will keep getting smaller, they're about as small as they'll get.<br> <TabAtkins> Rossen: Disagree, we keep changing them as well.<br> <TabAtkins> Rossen: Going back to Simon's statement that scrollbars as OS-level, and we shouldn't mess with them. I don't disagree with this.<br> <TabAtkins> Rossen: If the platform offers multiple sizes, maybe we give control over choosing that, ok. Maybe we want to give a little bit of color control, okay. But taking over system controls, you either take it over or you don't.<br> <TabAtkins> Rossen: For any other system control, like a button, they take it over totally. They use an image and script.<br> <tantek> q?<br> <astearns> ack dbaron<br> <TabAtkins> myles: So you're saying that authors should have no control, and should use JS entirely.<br> <TabAtkins> dbaron: An idea floated around was specifying a size and getting nearest-available size.<br> <TabAtkins> dbaron: Problem with that is people try out sizes and fiddle around until it looks good.<br> <florian> q+<br> <TabAtkins> dbaron: They can end up getting a different size than they ask for, but it looks okay, and then later changes violate what they want while still technically respecting what they say.<br> <TabAtkins> frremy: REason I disagree - if you ask for "thin" on mac you'll get overlay, 0 layout size.<br> <dbaron> dbaron: naming the property well can mitigate that risk<br> <TabAtkins> frremy: It seems way easier to just say "normal" or "thin", and they're up to the UA.<br> <TabAtkins> myles: On macos, there's layout and overlay scrollbars.<br> <TabAtkins> myles: If the author's threshold is larger than layout scrollbars they get that, if thinner they get overlay. Right?<br> <TabAtkins> myles: So the functionality seems to end up being flipping overlay on and off, which isn't what it's meant for!<br> <TabAtkins> tantek: I don't think flipping that switch is what was intended.<br> <tantek> s/switch/layout switch<br> <TabAtkins> myles: But macos has just two scrollbars - 16px and 0px. If your max-size is 15px, it'll turn on overlay.<br> <TabAtkins> myles: This is what I was getting at - we need to think deeply about how this affects scrollbar models today and in the future.<br> <TabAtkins> frremy: Problem is that the longer we wait, the more custom scrollbars we get.<br> <fantasai> myles: They want everything<br> <fantasai> TabAtkins: What they want and what they'll accept are two differnet hings<br> <astearns> ack florian<br> <TabAtkins> TabAtkins: And we're hoping we can hit their accept threshold with fairly little stuff.<br> <TabAtkins> florian: Re elika's point about getting something ridiculously tiny - maybe in the keywords we can have more than just auto|thin, we can add |hairline. That's definitely distinct in intent, while still allowing threshold.<br> <TabAtkins> myles: What if the OS's thinnest scrollbar is wider than the length?<br> <TabAtkins> TabAtkins: This is why frremy suggests just doing keywords, elkminate that problem.<br> <TabAtkins> florian: Note that scrollbar-gutter can solve some of those problems too.<br> <tantek> https://drafts.csswg.org/css-overflow-4/#scollbar-gutter-property<br> <TabAtkins> fantasai: And scrollbar-gutter should be in the same spec as this.<br> <TabAtkins> myles: So tantek you don't need resolutions yet, right?<br> <TabAtkins> tantek: My normal appraoch is to put in all the possibilities so we can discuss it with wider population.<br> <fantasai> s/this/this, if we go to FPWD/<br> <TabAtkins> tantek: So my inclination is to add "thin" and keep length for now.<br> <TabAtkins> Rossen: I think if we have the keyword and everyone revolts, we can think about adding lengths back.<br> <TabAtkins> TabAtkins: I agree, and I think lengths have a harder time of getting thru the committee anyway.<br> <TabAtkins> myles: My preferred solution is still option 3 - none of this proposal at all.<br> <TabAtkins> Rossen: +1<br> <TabAtkins> TabAtkins: I strongly disagree, as do our a11y people, but I understand your position, because it's what Simon has said every time this has come up.<br> <florian> q+<br> <TabAtkins> tantek: So I guess question is - would anyone object to going to fpwd with the width property at all, and would width with <length> draw objection?<br> <TabAtkins> Rossen: I wont' object to keywords. I'd object ot length<br> <TabAtkins> myles: We don't object to it in either form.<br> <astearns> ack florian<br> <TabAtkins> florian: I don't object to any particular, but to me fpwd signals we have details to figure out, but general agreement on the approach.<br> <TabAtkins> florian: I'm not sure we have agreement on appraoch yet. Not objecting, just noting.<br> <TabAtkins> myles: In addition to what I just said, which sounded positive, we're actually reluctant.<br> <TabAtkins> [talking about fpwd vs patents]<br> <TabAtkins> tantek: I'm hearing the least objection to putting *something* about length in there.<br> <TabAtkins> myles: Two browsers are reluctant.<br> <TabAtkins> tantek: If you really objected you'd drop the ::-webkit stuff.<br> <TabAtkins> myles: We don't comment on future software releases.<br> <TabAtkins> xidorn: Our position is that pushing this would help wk/blink drop the pseudo-elements.<br> <TabAtkins> xidorn: This is one of the use-cases we've heard.<br> <TabAtkins> tantek: Right. We think some of the users currently using ::-webkit stuff will be amenable to switching, and the -width property will contribute to that.<br> <TabAtkins> tantek: So my goal is to put it in for now. We can always decide in a subsequent draft to drop it.<br> <TabAtkins> florian: I'd be happier for fpwd if we agreed on earlier discussion.<br> <TabAtkins> fantasai: I think we're clear that this is about the simplest possible thing we could do.<br> <fantasai> s/do/do to control the width/<br> <TabAtkins> astearns: Rossen objected to "-width:<length>". If there was a scary warning, would that get thru your objection?<br> <TabAtkins> Rossen: Yeah.<br> <TabAtkins> proposed resolution to add "thin", and a big warning note about <length>, then go to fpwd.<br> <TabAtkins> [discussion about whether keywords, length, or both]<br> <TabAtkins> astearns: And you should include a note about disagreement aobut the existence of the property itself<br> <TabAtkins> astearns: Would you object to fpwd with the colors as stated?<br> <TabAtkins> fantasai: I think I would.<br> <TabAtkins> fantasai: We should start by just light vs dark theme.<br> <TabAtkins> astearns: Then we're out of time and will have to come back to this.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1958#issuecomment-402670195 using your GitHub account
Received on Thursday, 5 July 2018 09:55:25 UTC