- From: Ana Tudor via GitHub <sysbot+gh@w3.org>
- Date: Sun, 03 Apr 2022 15:28:44 +0000
- To: public-css-archive@w3.org
The below are my thoughts on this, based on coding hundreds of very different range input designs over the past few years. You can see a small sample of the sliders I coded in the collage below (these are actual screenshots of the range inputs I styled):  So far, the comments in this issue only talk about standard pseudos, but to me, that's not really an issue. Currently, it's often actually convenient to have different pseudos because the internal Shadow DOM structure and the way parts work/ are sized/ move also depends on the browser. This means that often, different styles are needed for WebKit browsers and Firefox. Making things standard needs to start with the Shadow DOM structure, not with the pseudo names. Otherwise, getting consistent results cross-browser is going to become more difficult, not easier. Here's the structure I came to the conclusion would be best for a simple, single thumb slider (we can discuss multiple handles later as I've also dealt with that - detailed in this two part article I wrote for CSS-Tricks: [one](https://css-tricks.com/multi-thumb-sliders-particular-two-thumb-case/) and [two](https://css-tricks.com/multi-thumb-sliders-general-case/)): * a `track` part * 2 progress parts, like IE/ pre-Chromium Edge had `::-ms-fill-lower` and `::-ms-fill-upper`; like in the IE/ old Edge these need to be *nested inside the `track`*, with one end attached to the corresponding end of the `content-box` of the `track` and the other end attached to the middle of the `thumb` (this is not how `::-moz-range-progress` works and that's a big problem because it means that, as it is, this Firefox pseudo is... pretty much unusable) * a `thumb` part that's *a sibling of the `track`* (not a child as it is the case in WebKit browsers) or doesn't have its motion restricted by the `track` or by the actual range input *the way it's currently happening*; this `thumb` and the `track` should be middle aligned vertically (currently not the case in WebKit browsers) This structure would allow for all the very different designs I've tried to code and which cannot be currently CSS-ed without adding extra elements or using pretty awful hacks which may lead to code breaking five months down the line or down a rabbithole of fixing the problems generated by fixes to earlier problems caused by fixes to problems we had before that and so on... I'll be coming back to this with a list of major issues this structure would fix, illustrated by practical range input examples. -- GitHub Notification of comment by thebabydino Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4410#issuecomment-1086891786 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 3 April 2022 15:28:47 UTC