- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Jan 2020 12:32:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `scrollbar-gutter`, and agreed to the following:
* `RESOLVED: Move scrollbar-gutter to the scrollbars spec, add florian as an editor`
<details><summary>The full IRC log of that discussion</summary>
<emilio> topic: scrollbar-gutter<br>
<emilio> github: https://github.com/w3c/csswg-drafts/issues/4674<br>
<emilio> cbiesinger: we're interested in implementing this: there's a lot of values for this property, and a lot of values didn't seem that useful to me<br>
<emilio> ... florian came with some use cases but I'm not sure they're useful enough?<br>
<emilio> iank_: we probably only want to implement stable<br>
<emilio> florian: the other values were solving issues raised by google<br>
<fantasai> s/and a lot/but a lot/<br>
<emilio> ... we should explain them better in the spec<br>
<emilio> ... but I'd be sad if we removed it<br>
<myles_> q+<br>
<emilio> cbiesinger: I think your explanation makes sense<br>
<emilio> fantasai: seems to me this feature belongs on css-scrollbars, not css-ui<br>
<hober> q+<br>
<hober> q-<br>
<emilio> florian: don't care, though I'm not an editor of css-scrollbars, so if you want me to keep editing it I should become an editor<br>
<tantek> huh?<br>
<emilio> RossenF2F: objections to move from css-ui to css-scrollbars and adding florian as an editor?<br>
<florian> s/keep editing it/keep editing that feature/<br>
<tantek> sorry I'm joining midconversation so I'm unaware of context<br>
<heycam> from css-overflow, not css-ui<br>
<fantasai> tantek, context is https://github.com/w3c/csswg-drafts/issues/4674<br>
<TabAtkins> tantek, moving scrollbar-gutter to css-scrollbars<br>
<emilio> RESOLVED: Move scrollbar-gutter to the scrollbars spec, add florian as an editor<br>
<RossenF2F> ack myles_<br>
<tantek> thanks fantasai<br>
<emilio> myles_: we did a review with some people that know more about design than me<br>
<emilio> ... this feature fundamentally breaks overlay scrollbars<br>
<emilio> ... but we also understand that there's a real problem here<br>
<emilio> ... and you don't want the scrollbar to cover things<br>
<tantek> myles++ has a very good point<br>
<emilio> ... there's also another issue (#4619) which proposes adding an environment variable with the width of the native scrollbars<br>
<cbiesinger> q+<br>
<emilio> ... it seems that'd allow authors to peek<br>
<emilio> florian: I don't think the stable value changes anything with overlay scrollbars, it's the force value what's problematic for you right?<br>
<emilio> myles_: any property that says "all elements should not be covered by overlay scrollbars" is problematic<br>
<emilio> hober: we like the idea of moving active elements but we don't want to encourage authors to try to inset everything<br>
<RossenF2F> q?<br>
<emilio> cbiesinger: the env variable seems a better case for the google use case<br>
<jensimmons> q?<br>
<jensimmons> q+<br>
<emilio> florian: I don't think it would because an env variable is for the entire page, so it doesn't depend on whether there actually are scrollbars<br>
<emilio> cbiesinger: I meant the combination of the env variable with the stable value<br>
<emilio> fantasai: but florian's point means that scrollbar width may change<br>
<emilio> ... and you don't know the scrollbar width<br>
<cbiesinger> q-<br>
<emilio> myles_: the wide value is not really that wide, so probably just the wide one would be enough<br>
<cbiesinger> s/4619/4691/<br>
<tantek> we deliberately removed explicit numeric width from scrollbar-width. there's also no "wide" value<br>
<tantek> https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width<br>
<cbiesinger> https://github.com/w3c/csswg-drafts/issues/4691<br>
<tantek> just: auto | thin | none<br>
<emilio> myles_: I think the value should be zero for non-overlay scrollbars<br>
<emilio> fantasai: we need both to align non-scrollable elements to scrollbars<br>
<emilio> myles_: isn't that a problem now?<br>
<emilio> florian: yes, but that's something that `scrollbar-gutter` solves<br>
<emilio> ... the `always` toggle let you get the scrollbar gutter on elements that are not scrollable<br>
<fantasai> The example is is a toolbar which is not scrollable over a scrollable box. The author wants the rightmost item in the toolbar to align with the rightmost item in the scrollable box.<br>
<emilio> ... which lets you fix that<br>
<tantek> q+ to ask if Blink also intends to implement scrollbar-color and scrollbar-width? if not, then it doesn't make sense to merge scrollbar-gutter with those properties, because they'll end up blocking each other in CR<br>
<emilio> hober: in a world with that value and non-overlay scrollbars then that'd be zero<br>
<hober> s/non-//<br>
<tantek> there is no "thick"<br>
<emilio> myles_: [[discussing with florian on the whiteboard]]<br>
<tantek> scrollbar-width: auto<br>
<tantek> is what I think people are trying to say?<br>
<emilio> myles_: so you mean that we need two environment variables, one per scrollbar-width value?<br>
<fantasai> The discussion is about how to know how thick to make the padding on the toolbar if the scroller has a 'scrollbar-width: thin' declaration - the solution currently is to say 'scrollbar-width: thin; scrollbar-gutter: always force' on the toolbar<br>
<jensimmons> q-<br>
<tantek> examples?<br>
<tantek> agreed with myles<br>
<emilio> florian: the thing that would fix this is `always`, people are already moving stuff away from the scrollbars, just guessing<br>
<fantasai> s/guessing/guessing how wide they are/<br>
<emilio> hober: so a variable that tells you how wide it is?<br>
<tantek> good I want to hear Jensimmons's thoughts<br>
<emilio> florian: as long as you can do that then I'm fine<br>
<emilio> myles_: there are too many values<br>
<florian> q?<br>
<fantasai> ack tantek<br>
<Zakim> tantek, you wanted to ask if Blink also intends to implement scrollbar-color and scrollbar-width? if not, then it doesn't make sense to merge scrollbar-gutter with those<br>
<florian> q+<br>
<Zakim> ... properties, because they'll end up blocking each other in CR<br>
<tantek> re: https://github.com/w3c/csswg-drafts/issues/4674 "Blink is interested in implementing/shipping scrollbar-gutter"<br>
<emilio> TabAtkins: some of them could be named better<br>
<RossenF2F> q?<br>
<emilio> tantek: I'd like to ask Google which other values besides stable is Blink interested in implementing, and is blink interested in implementing scrollbar-{width,color}?<br>
<emilio> cbiesinger: def. interested in stable and the env variable, not so much in others<br>
<TabAtkins> Okay, so I remember why we did "always" - "stable" means that authors still have to ensure their designs work on both widths. "always" was meant to be a "let authors safely be a little lazier" value.<br>
<emilio> tantek: makes sense, and I tend to agree with myles_ that there's if there's no implementor interest and no use case maybe should be dropped<br>
<emilio> cbiesinger: scrollbar-{width,color} is not on the roadmap<br>
<emilio> iank_: not meaning we won't implement, but not on the roadmap<br>
<TabAtkins> I feel strongly that if we do stable, we *need* force; that's the use-case Florian illustrated and it's very valuable I think.<br>
<emilio> tantek: then I'd probably advocate for undoing the move to the scrollbars spec<br>
<hober> hober: why not put them in different levels of the same spec?<br>
<emilio> ... we'd have to do a lot of gymnastics<br>
<TabAtkins> We can maybe drop "both" - it had use-cases that I think were mostly based on "always".<br>
<emilio> fantasai: I think there's a benefit to have related features in the same spec<br>
<fantasai> s/benefit/benefit to readers/<br>
<TabAtkins> So perhaps an `auto | [ stable && force? ]` grammar reduction.<br>
<emilio> ... keeping it in overflow doesn't make much sense<br>
<emilio> tantek: I don't think there's any benefit of moving it<br>
<bkardell_> what about what hober said?<br>
<emilio> RossenF2F: I don't think we should do busywork just for the sake of doing it, but I do think that we should have scrollbar-related properties together to move them for the REC track, and for readers<br>
<fantasai> hober, scrollbar-color and scrollbar-width already have one implementation<br>
<fantasai> hober, scrollbar-gutter has an intent from Chrome<br>
<emilio> ... this is why we have modules and levels<br>
<fantasai> hober, it's not clear which is further ahead in that respect<br>
<TabAtkins> q+<br>
<fantasai> hober, and we're not even in CR, so there's no reason to drop anything atm<br>
<emilio> RossenF2F: so we probably can still make a level of scrollbars be on the REC track with color/width<br>
<emilio> tantek: given the fact that there's disagreement on what implementors are interested in I think that trumps the cosmetic use case<br>
<bkardell_> "interest" and "priority" aren't the same though<br>
<emilio> ... that practical divergence should override the cosmetic thing<br>
<emilio> fantasai: but it's a WD<br>
<emilio> tantek: right that's why I think busywork is not warranted<br>
<TabAtkins> q?<br>
<emilio> ... hearing from WebKit that they're interested in all three, otherwise just leave it alone?<br>
<emilio> RossenF2F: let's try to avoid discussing process too much... Do you want to undo the previous resolution?<br>
<myles_> q+<br>
<emilio> tantek: yes, because the lack of interest from blink in scrollbar-width/color means we shouldn't do it<br>
<emilio> iank_: that's a misrepresentation<br>
<fantasai> I want to point out that oveflow-4 is otherwise completely experimental stuff and is not an appropriate place for a feature that is being imminently implemented<br>
<tantek> fantasai then move the experimental stuff in overflow-4 to overfow-5<br>
<RossenF2F> q?<br>
<emilio> jensimmons: interest is not the same as saying not on the roadmap<br>
<tantek> don't make extra busy work for multiple specs<br>
<fantasai> tantek, it's not an overflow feature, it's a scrollbar feature<br>
<emilio> iank_: It just meant not in the roadmap at the moment<br>
<fantasai> tantek, it doesn't belong in that module<br>
<emilio> ... that may change in the future<br>
<tantek> overflow and scrolling are tightly related<br>
<TabAtkins> tantek, stop objecting to other people volunteering to do work<br>
<tantek> fantasai quit making an aesthetic argument<br>
<emilio> cbiesinger: I'm more skeptical about the scrollbar width use case, we just don't plan to implement it soon<br>
<fantasai> tantek, it's a usability argument. I want our specs to not be GCPM-style hodgepodgs<br>
<tantek> I'm saying postpone until we get positive signals from implementers for all three properties<br>
<emilio> RossenF2F: there are other implementors other than google :-)<br>
<tantek> I'm arguing for more modularity not less<br>
<tantek> anyway my objection to the previous resolution is recorded<br>
<TabAtkins> tantek, one property per spec?<br>
<emilio> TabAtkins: yeah we try to be extremely clear when objecting because we understand it's a powerful statement<br>
<RossenF2F> q?<br>
<tantek> TabAtkins: no I'm not interested in strawman like that or fantasai's "GCPM-style hodgepodgs"<br>
<tantek> seriously, not good faith arguments<br>
<RossenF2F> ack florian<br>
<emilio> florian: I heard calls for dropping values and I'd like to push back. We designed this for years in response to use cases. I'm happy to document what the use cases were and maybe rename values so they're better names<br>
<tantek> starting by removing things that lack a reason is the right thing to do<br>
<emilio> ... but until that's done I don't think we should drop values<br>
<tantek> hober++<br>
<RossenF2F> q?<br>
<emilio> hober: that's some work in order to chop things, we'd rather do that now<br>
<tantek> I'm really not sympathetic to features without examples/explanations up front<br>
<emilio> florian: it's just some examples, and I'm sure we won't chop it off<br>
<hober> s/we'd rather do that now/i'd rather spare you the work and chop them now/<br>
<emilio> dbaron: I'd say that's a reason why explainers should have explainers with what they're trying to solve<br>
<emilio> myles_: I don't think that actually conflicts with the env variable proposal<br>
<dbaron> s/explainers should/specs should/<br>
<tantek> if you can't link to the examples / explanations, consider them non-existent<br>
<emilio> florian: I recall people saying there are no use cases but they were, and I'll spend some time cleaning up this and investigate dropping these after we remember what they're for?<br>
<tantek> florian: if you want to postpone dropping, then why not postpone merging also? why is that kind of tentative reasoning good for one postponement and not another?<br>
<tantek> feels pretty inconsistent<br>
<emilio> TabAtkins: I think we agree that stable or something that implements that is good, and that env doesn't solve it<br>
<emilio> ... I think `force stable` seems reasonable too<br>
<emilio> ... as that is what you can use to align<br>
<emilio> ... non-scrollable things to scrollable things<br>
<emilio> cbiesinger: you can use that with the env variable right?<br>
<emilio> TabAtkins: yes<br>
<emilio> florian: don't you need a media query for overlay scrollbars?<br>
<emilio> emilio: env variable would be zero in that case<br>
<emilio> TabAtkins: always is the one you were more skeptical about<br>
<tantek> TabAtkins: "I could see dropping this for now"<br>
<emilio> ... it's done so that you can consistently design stuff across systems<br>
<emilio> ... I could see us dropping always for now<br>
<emilio> ... `both` is intended for always and it seems to be a lot less valuable with stable<br>
<emilio> ... and I think we can drop it for now too<br>
<emilio> ... so we can probably drop them and use `stable` with the `force` keyword, or with the `env()` variable<br>
<emilio> myles_: sounds reasonable<br>
<hober> q+<br>
<RossenF2F> ack TabAtkins<br>
<emilio> fantasai++<br>
<jensimmons> q?<br>
<emilio> florian: my proposal is to revisit this in a week or three<br>
<emilio> ... once we have the cases and alternatives clear<br>
<fantasai> s/cases/cases described/<br>
<tantek> if you're postponing dropping, then postpone merging<br>
<tantek> why is postponing ok for one and not the other?<br>
<TabAtkins> tantek, I'm not happy with you apparently misquoting me to make a point opposite what I'm supporting<br>
<myles_> q-<br>
<RossenF2F> ack hober<br>
<emilio> hober: I wanted to reply to tab<br>
<emilio> ... you said that you're ok dropping always and both, and then between stable + force, or stable + env() you're indifferent right?<br>
<emilio> ... I prefer the env variable<br>
<cbiesinger> q+<br>
<emilio> ... I think it should be an exceptional thing done with particular descendants, and the env variable encourages this a bit more<br>
<RossenF2F> Zakim, close queue<br>
<Zakim> ok, RossenF2F, the speaker queue is closed<br>
<emilio> TabAtkins: are you ok with adding more than two values for different widths?<br>
<emilio> hober: we can get to that once it comes up<br>
<RossenF2F> ack cbiesinger<br>
<emilio> cbiesinger: I agree with hober though for different reasons. I think env() is more understandable for authors than `stable force`<br>
<tantek> I agree with cbiesinger, so don't bother with moving a dead property into a different spec<br>
<emilio> RossenF2F: so next steps florian brings the use cases for the current design<br>
<cbiesinger> well the property isn't dead, just maybe some values of it<br>
<hober> hober: i think we have multi-engine agreement here, which seems worth noting<br>
<tantek> Thanks Rossen for clarifying purpose of scrollbars spec. You're right we should have started there<br>
<tantek> Rossen++ for upleveling the conversation<br>
<emilio> RossenF2F: Re. merging, scrollbar-width/color just styles controls... scrollbar-gutter is more about the box model<br>
<emilio> ... so let's not move everything to scrollbars yet until we know what will remain there<br>
<tantek> That sounds like I need to better document scope in the Scrollbars spec<br>
<emilio> ... next call we'll see whether we stick to that resolution<br>
<tantek> TabAtkins: I've grown very intolerant of time-wasting aesthetics.<br>
<emilio> jensimmons: I like it when this group is able to have discussions and make space for each other instead of going back and forth<br>
<TabAtkins> ScribeNick: TabAtkins<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4674#issuecomment-577662037 using your GitHub account
Received on Thursday, 23 January 2020 12:32:19 UTC