Re: [css-scrollbars] Thoughts on FPWD

On 08/22/2018 09:00 AM, Tantek Çelik wrote:
> On Mon, Jul 30, 2018 at 3:38 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
>> Tantek,
>> We discussed the CSS Scrollbars spec at the Sydney F2F;
>>    https://drafts.csswg.org/css-scrollbars-1/
>>    https://lists.w3.org/Archives/Public/www-style/2018Jul/0031.html
>> but ran out of time before we were able to conclude on an FPWD.
>> Sorry for holding it up. It seemed to have prompted a lot of people
>> to look more closely at the spec, though, and some good issues were
>> filed.
> 
> I took a closer look at the issues you pointed out:
> 
> 
>> My take on FPWD is that a few things should be resolved first --
>>
>> https://github.com/w3c/csswg-drafts/issues/1958 =WG=
>> We almost, but apparently didn't, resolve on adding scrollbar-width.
>> To follow up on the F2F discussion, I think we should, as discussed
>> at the F2F, resolve to add it with the superset of the values
>> discussed,
> 
> We did discuss (and remove) any objections to adding it at the f2f, so
> that part was already done.

Yeah, but there was no resolution scribed. :( So I think we should get
that on the record.
>> (and also that renaming it
>> scrollbar-max-width, if we choose to allow <length> values, is also
>> a possibility).
> 
> IMO that was more theoretical than any kind of objection, so no need
> to process nor indicate that for FPWD.
> 
>> We can then file a follow-up issue on the value
>> space and another on the name (possibly repurposing #2966).
> 
> I took a look at 2966. I don't think a bikeshedding issue is worthy of
> its own explicit note in the FPWD.

I think that when syntax is an open question, it's good to note this
in the draft. It helps warn implementers that a significant breaking
change is being considered. Certain implementers in particular have
a tendency to assume FPWD means “ready to ship”, so I'd rather get
notes about breaking-change issues in their face than merely filed
away in GitHub...

>> https://github.com/w3c/csswg-drafts/issues/2879 =WG=
>> Strongly agree to adding some shorthands here, and they should be
>> in the FPWD. This should be pretty simple.
> 
> As noted in that issue, I think a shorthand would both be good, and we
> should consider a scrollbar-color *property* per issue 2993
> 
> https://github.com/w3c/csswg-drafts/issues/2993
> 
> I'd rather resolve on both of those rather than something halfway.

WFM

>> https://github.com/w3c/csswg-drafts/issues/2009
>> There's a lot of controversy around styling scrollbars, and more
>> than any other spec we've published so far,
> 
> I think that's selectively forgetful of all the drama around -webkit-
> prefixed properties in mid-to-late 2000s but whatever, controversy is
> not a measure of (un)success.

The controversy there was more about how the feature was released than
how the feature was designed, though.

>> I think it's important
>> that we have a good discussion of the scope and why we're taking
>> this approach and rejecting others. There are a lot of comments
>> in the various open issues from which you can lift all the relevant
>> arguments to make in this section: it'd be worth going through them
>> and incorporating them into your scope section / introduction.
> 
> I've looked through them all and they're all variants of "just
> implement all the -webkit- pseudos because we think we need all that
> power" (without any actual use-cases that demonstrate that claim).
> 
> If you find a specific argument there with merit, please raise it,
> otherwise I think we should leave it to processing the various issues.
> 
> Aside: what's the group etiquette / process when folks are spamming
> many issues with the same off-topic commentary / proposals?

Like I said in the quoted text :P write up a strong explanation of
your proposal and the reasons for it, including mention of the
counterproposals and why they're bad--basically, *thoroughly* justify
the design you're going with--and put that explanation in the Intro.
And then reply to each of those issues by linking to the intro.

This is basically your “if there's an FAQ, make an FAQ doc that
answers it” technique. :) I'm just saying to put it in the spec,
compiling the responses to all the variants of that question into
the spec intro. Then it's right up front, so anyone reviewing the
spec will see it.

>> https://github.com/w3c/csswg-drafts/issues/1960 =WG=
>> I don't think we can in good conscience accept FPWD without also
>> accepting this issue :)
> 
> I filed the issue :)
> 
> Really the follow-up to that issues is 2993. Not the continued
> off-issue insistence on tons of scrollbar pseudos.

I think that 2993 is a follow-up, but we should close 1960 with
a WG resolution that we're only allowing the setting of two colors,
as you've described so far in the draft.
>> https://github.com/w3c/csswg-drafts/issues/2898
>> Clarifying what “track” and “face” are, and explaining a little
>> better how colors map to other parts of a scrollbar or giving some
>> advice and a few examples of how additional colors are derived from
>> the given colors when needed would probably help everyone understand
>> the intent of the feature a little better.
> 
> I'm ok considering bikeshedding track/face for FPWD, they're legacy
> names taken from the -ms-scrollbar properties.

This issue isn't about bikeshedding, it's about better explanations
in the spec about what they are.

“In section 2, the terms "scrollbar-track" and "scrollbar-face" are
  used without defining what these are. The terms used to describe the
  components of a scrollbar vary from platform to platform, so the
  ones chosen here must be defined to ensure that all readers are on
  the same page.” -- https://github.com/w3c/csswg-drafts/issues/2898

You can also bikeshed them, but that would be a separate issue.

~fantasai

Received on Thursday, 23 August 2018 21:20:25 UTC