- From: Ilya Streltsyn via GitHub <sysbot+gh@w3.org>
- Date: Sun, 16 Sep 2018 03:58:57 +0000
- To: public-css-archive@w3.org
I have to admit that I am also not convinced that this reasoning is enough. I completely understand the intention to correct the mistake of exposing the _direct mapping_ of the _specific platform implementation_ to the Web, but using this as a reason against _any_ pseudo-element-based approach still seems kind of throwing out a baby with the bathwater to me. > Different platforms have different scrollbar structure means testing interop is harder, because authors would need to take not only engine but also platforms into account. This is the reality authors have to deal with _regardless_ which approach is chosen, even without styling scrollbars at all (some platforms always show scrollbars and include their width into the element size, some auto-hide and exclude them, and designs have to adapt to either behavior). I don't see how restricting the ability to affect the scrollbar appearance _and behavior_ with some arbitrarily picked limited set of aspects makes this situation easier for authors. On the contrary, there are cases where these artificial limitations may impact the UX negatively (for example, I strongly disagree that losing the ability to handle the scrollbar thumb hovering on Windows is "[probably fine](https://bugzilla.mozilla.org/show_bug.cgi?id=1460456#c7)"). > Operating systems continuously evolve their scrollbar designs to provide better user experience, beyond the ability of any set of... In my opinion, the exactly same concern can be raised against any limited set of predefined scrollbar aspects, regardless the exact way they are expressed — via pseudo-elements or via (sub)properties. For example, imagine that some platform decides one day to split the functionality of the scrollbar thumb into two parts, one for large-scale "scrubbing" and one for the "fine tuning" the scroll position in the extremely long documents. Which part should the "scrollbar thumb color" refer to then? Or should the user agent fall back to the "simpler scrollbar than the default platform UI rendering" when scrollbar styling properties are in effect, _losing this extra functionality/usability feature entirely?_ However, as @craigkovatch mentioned above, the "fundamental" parts of the scrollbar are nearly constant in any given platform over time, so we may expect them to be available in the future — again, _either_ via (sub)properties _or_ via pseudo elements. And the second approach still feels much more flexible. I agree that complete modelling of the specific implementation is probably not needed (if possible at all), and limiting the scrollbar styling possibilities to some degree is necessary. But maybe presenting the same two aspects — the track and the thumb — as pseudo elements (so one would be able to apply `:hover` to them etc.) can be the acceptable compromise between the interop and flexibility? -- GitHub Notification of comment by SelenIT Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2009#issuecomment-421687598 using your GitHub account
Received on Sunday, 16 September 2018 03:58:59 UTC