[css-forms-1] Names of <input type=range> / <input type=checkbox switch> pseudo-elements

[annevk]

I decided to split this from #4410 as that discussion is already quite long.

In WebKit we accidentally implemented the new pseudo-elements as ::thumb and ::track. They are not shipped and can be renamed, but when discussing it internally none of us really liked the longer prefixed names. Also, when it was revealed we implemented these pseudo-elements, nobody noticed they had the wrong names. @nt1m discovered it while auditing pseudo-elements in general.

Selectors are typically short words, without thematic grouping. E.g., it's :playing, not :media-playing. They get context from usage. E.g., input::thumb.

And for a switch it's also not at all a "slider" thumb. It's just the thumb. It slides while animating, but it's not like you can hold it in any position that's not on or off.

If there's ever a need for another thumb/track-like pseudo-element that can have a longer name.

[yisibl]

RESOLVED: Add ::slider-thumb, ::slider-track
RESOLVED: Define these two pseudos as siblings of each other
RESOLVED: Apply them to <input type=range>, switch, <progress>, and <meter>
RESOLVED: Add ::slider-fill when relevant
RESOLVED: track, fill, thumb are in the same tree order as their usual painting order

#4410 (comment)

I found a problem with the name of the WebKit implementation, but I thought the CSSWG had discussed it elsewhere and removed the slider- prefix from the name.😂

Overall, I like the shorter names.

[tabatkins]

Selectors are typically short words, without thematic grouping. E.g., it's :playing, not :media-playing. They get context from usage. E.g., input::thumb.

This is true for pseudo-elements, because their only effect is to match something; they don't affect anything else. But pseudo-elements do have larger effects, namely what properties are allowed on them. So having a slightly uniquified name, if we think there might be other pseudos with the same "basic" name that could have different contexts, could be useful.

(I suspect that's not really the case here, fwiw - all the thumb/track/etc pseudos will act the same in this regard.)

So, sure, shorter names works for me.

[fantasai]

My concern with the shorter names is that some of them are very generic, e.g. ::track especially and even ::thumb. Imho grouping them together makes it clearer what they're referring to.

[lukewarlow]

I agree that ::thumb might be a bit generic especially when we already have the (admittedly non-standard) ::-webkit-scrollbar-thumb. But slider also doesn't seem like the right prefix if we want these to apply to <meter> and <progress>, and is a bit odd even for <input type=checkbox switch>.

[css-meeting-bot]

The CSS Working Group just discussed [css-forms-1] Names of <input type=range> / <input type=checkbox switch> pseudo-elements, and agreed to the following:

• RESOLVED: Keep the slider-* prefixes and close the issue

The full IRC log of that discussion

<TabAtkins> ntim: i put the issues in order of expected speed
<TabAtkins> ntim: we originally resolved on the speudo-elements for range, switch, and meter/progress to have ::slider-* prefix
<TabAtkins> ntim: but we realized it might be better to drop the slider prefix for authoring
<TabAtkins> ntim: since writing "slider-" might not be convenient
<TabAtkins> ntim: so wanted to see people's thoughts
<TabAtkins> q+
<astearns> ack TabAtkins
<fantasai> TabAtkins: I would prefer to keep the "slide-" prefix. I don't think it's very long. But it groups these clearly related pseudos together semantically -- and also in alphabetically ordered lists.
<lea> q?
<lea> q+
<fantasai> astearns: Would you keep that for <meter> and <progress> also?
<fantasai> TabAtkins: Fine with that. It's sliding.
<fantasai> TabAtkins: To the extent that <meter>/<progress> have a thumb.
<TabAtkins> fantasai: it might not be something you can grip, but it might be something styleable
<astearns> ack lea
<TabAtkins> lea: i have a weak preference towards not prefixing
<TabAtkins> lea: not just for verbosity, but just when do you group related pseudos together
<TabAtkins> lea: we're already talking about meter/progress, but what about switch?
<TabAtkins> lea: if you don't prefix, it's up to the author to group or separate them
<ntim> q+
<TabAtkins> lea: while if we decide how to prefix them, doing the oppsoite requires more complexity. locks us in as we have more elements with a shared structure
<astearns> ack ntim
<TabAtkins> ntim: more context, webkit implemented switch control. it always felt odd to write `switch::slider-thumb`/etc
<TabAtkins> ntim: they're a slider to some extent, but it felt weird
<TabAtkins> lea: so case in point, it's not the future we'll reach it, we're already there
<emilio> Slight preference for keeping `::slider-` fwiw, but...
<fantasai> TabAtkins: Switch looks like a slider. You're sliding it back and forth.
<astearns> q+
<bkardell> q+
<fantasai> TabAtkins: If you have a thumb and track etc. then you're describing a slider.
<fantasai> TabAtkins: these concepts are taken from the slider hierarchy of controls
<fantasai> lea: Meter and progress?
<fantasai> TabAtkins: yes. The value slides.
<bkardell> q-
<TabAtkins> astearns: the argument against taking the slider prefix off is that thumbs and tracks could possiblly be other things
<TabAtkins> astearns: would it make sense to use another prefix, like ::ui-track?
<astearns> ack astearns
<TabAtkins> fantasai: scrollbars are also UI and they have thumbs and tracks too
<bkardell> q+
<astearns> ack bkardell
<fantasai> bkardell: This doens't apply to the scrollbar thumb
<fantasai> TabAtkins: e.g. prefixed ::scrollbar-thumb and ::scrollbar-track
<fantasai> TabAtkins: a ::ui- prefix would be confusing, thos eare also ui
<fantasai> bkardell: If we name them generically, would they apply to those thumbs and tracks, too?
<astearns> ::form-thumb?
<fantasai> meter and progress aren't form inputs...
<TabAtkins> bkardell: [directing question to Lea]
<TabAtkins> lea: my argument depended on the idea that you coudl speialize them with the rest of the selector
<TabAtkins> lea: if there's a way to do that for a scrollbar, then sure, but if there isn't we definitely need a prefix then
<TabAtkins> lea: you need the ability to target both - generic and specific
<ntim> q+
<astearns> ack ntim
<TabAtkins> ntim: clarifying - right now there's no specified ::scrollbar-thumb or track, and that's intentional.
<TabAtkins> bkardell: the reason i asked is sometimes these also change over time what our mental model is
<TabAtkins> bkardell: some video players have thumbs and tracks
<emilio> Wouldn't that be a `<progress>`?
<TabAtkins> bkardell: you were saying if you squint at this control it looks like a track, but i think if you look at it another way it might not be...
<lea> I think a core eigenquestion is: could the same element have two types of tracks/thumbs?
<TabAtkins> ntim: i think this is where Lea's argument applies, the author can always specify the selector before the pseudo-eleemtn to be specific
<TabAtkins> ntim: if the author puts `input::thumb` you know it's not for a video
<TabAtkins> lea: a core question we could ask is if we think the same element could have two types of thumbs/tracks?
<TabAtkins> lea: a slider with two thumbs, certainly, but those are of the same type of thing
<TabAtkins> ntim: we can add a functional version of the pseudo at that point to target idnviidual ones
<TabAtkins> ntim: straw poll?
<astearns> ack fantasai
<TabAtkins> fantasai: i think we should think aobut this - it's not just thumb/track, we also have fill, and possibly other things
<TabAtkins> fantasai: if these are pseudos we are dedicating to this purpose, that takes those names away from anything else
<TabAtkins> lea: do we have a list of the names?
<TabAtkins> fantasai: so far "thumb", "track", "fill"
<emilio> There's also the benefit of typing `::slider-` and seeing all of them together in your editor :-)
<TabAtkins> ntim: there's another issue to add something for color-swatch
<TabAtkins> bkardell: "ruler" or "meter", the tick marks
<astearns> 1: keeping the slider- prefixes for thumb and track
<astearns> 2: just use thumb and track
<TabAtkins> fantasai: i think we need to amke sure the prefix is consistent for all the parts, eithe rprefix all or none
<TabAtkins> fantasai: if we think prefixing some is okay and others aren't we ahve a problem
<TabAtkins> astearns: yes we need to think as a whole, but don't know that it's a bad result to have some as a prefix and some aren't, because some might be generic enough to not need one
<ydaniv> +1 to lea
<TabAtkins> lea: if we don't prefix these we can still name individual ones better
<TabAtkins> STRAW POLL TIME
<ntim> 2
<TabAtkins> 1
<ydaniv> 2
<lea> 2
<smfr> 1
<astearns> 1
<noamr> 1
<kurt> 1
<emilio> 1
<ChrisL> 2
<bkardell> 1.5
<oriol> 1
<alisonmaher> 1
<rachelandrew> 1
<kbabbitt> 1
<schenney> 1
<kizu> 1
<lea> s/we can still name individual ones better/we can still name individual ones better, e.g. we may decide `::track-fill` is a better name than `::fill`. That's not prefixing, just good naming./
<bkardell> q+
<bkardell> q-
<noamr> We have `:active-view-transition-type`, I think `:slider-fill` is short
<dbaron> emilio: I like the autocomplete aspects of the ::slider prefix.
<TabAtkins> I think slider-fill is *too* short, based on precedent. we need longer words
<bkardell> q+
<TabAtkins> astearns: looks like prefixes are winning
<TabAtkins> ntim: okay, prefixes are in the previous resolution
<TabAtkins> bkardell: each of those controls are sliders currently
<TabAtkins> bkardell: so nothing changes in terms of what the pseudo-element applies to
<lea> q+
<astearns> ack bkardell
<TabAtkins> ntim: it would apply to switch, range, meter, and progress
<bkardell> 2
<bkardell> since that is generic behavior, I think 2
<TabAtkins> lea: if we keep these prefixes it makes it harder to use descreptive names, becuase it's already long
<TabAtkins> lea: i think "fill" is confusing, "slider-fill" is still confusing, but "slider-track-fill" would be too long
<TabAtkins> astearns: so we'll take a resolution to keep the prefixes, based on straw poll
<TabAtkins> astearns: if we have better argumetns in the future we can revisit
<TabAtkins> astearns: proposed reoslution is keep slider prefixes and close the issue
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: Keep the slider-* prefixes and close the issue