Hi Tantek, > On Jul 9, 2018, at 4:36 PM, Tantek Çelik <tan...@cs.stanford.edu> wrote: > > On Mon, Jul 9, 2018 at 1:57 PM, Mike Taylor <mi...@mozilla.com> wrote: >> Hi Xidorn, >> >>> On Jul 8, 2018, at 8:24 PM, Xidorn Quan <m...@upsuper.org> wrote: >>> Hopefully with these properties (and one another controlling scrollbar >>> width or style to fulfill thin scrollbar usecases), WebKit and Blink would >>> be able to unship their current pseudo-elements, so that we wouldn't need >>> to implement them to get web compatible. > > Thanks Xidorn! > > >> I’m skeptical about this approach, given that it requires existing and >> legacy sites to update their code. But I would be happy to be wrong. ^__^ > > MS Edge disagrees as they have been able to *drop* their legacy > proprietary -ms- prefixed properties for scrollbar coloring (which was > often provided as a back-up in ::-webkit- scrollbar code samples) with > very little impact on apparent bugs / compat from their perspective. > > We confirmed this last week at the CSSWG meeting with MS Edge PMs. > Waiting on the official f2f minutes for a citation.
That’s a very cool signal. > > >> To date the compat issues we care about (because they break layouts) are >> about assigning a specific width, or hiding the track entirely (via >> ::-webkit-scrollbar). > > Agree with the use-cases "specific width, or hiding the track > entirely" and the new (not yet implemented) scrollbar-width property > addresses those. > > https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width > > Also we are getting strong informal signals (reconfirmed as of last > week) that there is high desirability to DROP the mess of > ::-webkit-scrollbar-* from existing implementations. This is a when > not if, and is largely waiting on sufficient proof of concept that CSS > Scrollbars solves enough use-cases to get at least some sites to > switch or provide both, which likely depends on us shipping the new > standard properties. > > Past evidence (which shows how this has changed to be even more > negative on webkit-scrollbars over the past year) until we get last > week's minutes: > > https://lists.w3.org/Archives/Public/www-style/2017May/0010.html > "smfr: It was a mistake to leak to web. We don't really like that > people can style scrollbars. We won't enhance and prefer to deprecate > it." > > https://lists.w3.org/Archives/Public/www-style/2017Dec/0040.html > "TabAtkins: We would like to drop as much of our weird -webkit- stuff > as possible." > ... > "smfr: We're interested only in very limited customization of > scrollbars. Would like to get rid of -webkit- scrollbar pseudo stuff. > smfr: we're only interested in coloring, and hiding scrollbars." > > Not quite an official intent to deprecate / unship, but clearly that's > the direction things are headed. Also positive signals. Typically Apple doesn’t drop support for anything that has shipped, at risk of breaking sites… so we’ll have to see how that evolves going forward. > > >>> Platform coverage: Desktop >> >> Why not on mobile? > > Requires platform specific code that just hasn't been written (yet) > for mobile platforms. > > Do you think this feature requires Desktop+Mobile parity/equivalency > before we ship on Desktop? Thanks. If we have plans to ship on mobile in the future, I would say no. I was mostly curious if this was considered as a “Desktop”-only feature. Thanks, -- Mike Taylor Web Compat, Mozilla _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
