- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Apr 2025 17:53:21 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> ntim: i put the issues in order of expected speed<br> <TabAtkins> ntim: we originally resolved on the speudo-elements for range, switch, and meter/progress to have ::slider-* prefix<br> <TabAtkins> ntim: but we realized it might be better to drop the slider prefix for authoring<br> <TabAtkins> ntim: since writing "slider-" might not be convenient<br> <TabAtkins> ntim: so wanted to see people's thoughts<br> <TabAtkins> q+<br> <astearns> ack TabAtkins<br> <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.<br> <lea> q?<br> <lea> q+<br> <fantasai> astearns: Would you keep that for <meter> and <progress> also?<br> <fantasai> TabAtkins: Fine with that. It's sliding.<br> <fantasai> TabAtkins: To the extent that <meter>/<progress> have a thumb.<br> <TabAtkins> fantasai: it might not be something you can grip, but it might be something styleable<br> <astearns> ack lea<br> <TabAtkins> lea: i have a weak preference towards not prefixing<br> <TabAtkins> lea: not just for verbosity, but just when do you group related pseudos together<br> <TabAtkins> lea: we're already talking about meter/progress, but what about switch?<br> <TabAtkins> lea: if you don't prefix, it's up to the author to group or separate them<br> <ntim> q+<br> <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<br> <astearns> ack ntim<br> <TabAtkins> ntim: more context, webkit implemented switch control. it always felt odd to write `switch::slider-thumb`/etc<br> <TabAtkins> ntim: they're a slider to some extent, but it felt weird<br> <TabAtkins> lea: so case in point, it's not the future we'll reach it, we're already there<br> <emilio> Slight preference for keeping `::slider-` fwiw, but...<br> <fantasai> TabAtkins: Switch looks like a slider. You're sliding it back and forth.<br> <astearns> q+<br> <bkardell> q+<br> <fantasai> TabAtkins: If you have a thumb and track etc. then you're describing a slider.<br> <fantasai> TabAtkins: these concepts are taken from the slider hierarchy of controls<br> <fantasai> lea: Meter and progress?<br> <fantasai> TabAtkins: yes. The value slides.<br> <bkardell> q-<br> <TabAtkins> astearns: the argument against taking the slider prefix off is that thumbs and tracks could possiblly be other things<br> <TabAtkins> astearns: would it make sense to use another prefix, like ::ui-track?<br> <astearns> ack astearns<br> <TabAtkins> fantasai: scrollbars are also UI and they have thumbs and tracks too<br> <bkardell> q+<br> <astearns> ack bkardell<br> <fantasai> bkardell: This doens't apply to the scrollbar thumb<br> <fantasai> TabAtkins: e.g. prefixed ::scrollbar-thumb and ::scrollbar-track<br> <fantasai> TabAtkins: a ::ui- prefix would be confusing, thos eare also ui<br> <fantasai> bkardell: If we name them generically, would they apply to those thumbs and tracks, too?<br> <astearns> ::form-thumb?<br> <fantasai> meter and progress aren't form inputs...<br> <TabAtkins> bkardell: [directing question to Lea]<br> <TabAtkins> lea: my argument depended on the idea that you coudl speialize them with the rest of the selector<br> <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<br> <TabAtkins> lea: you need the ability to target both - generic and specific<br> <ntim> q+<br> <astearns> ack ntim<br> <TabAtkins> ntim: clarifying - right now there's no specified ::scrollbar-thumb or track, and that's intentional.<br> <TabAtkins> bkardell: the reason i asked is sometimes these also change over time what our mental model is<br> <TabAtkins> bkardell: some video players have thumbs and tracks<br> <emilio> Wouldn't that be a `<progress>`?<br> <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...<br> <lea> I think a core eigenquestion is: could the same element have two types of tracks/thumbs?<br> <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<br> <TabAtkins> ntim: if the author puts `input::thumb` you know it's not for a video<br> <TabAtkins> lea: a core question we could ask is if we think the same element could have two types of thumbs/tracks?<br> <TabAtkins> lea: a slider with two thumbs, certainly, but those are of the same type of thing<br> <TabAtkins> ntim: we can add a functional version of the pseudo at that point to target idnviidual ones<br> <TabAtkins> ntim: straw poll?<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: i think we should think aobut this - it's not just thumb/track, we also have fill, and possibly other things<br> <TabAtkins> fantasai: if these are pseudos we are dedicating to this purpose, that takes those names away from anything else<br> <TabAtkins> lea: do we have a list of the names?<br> <TabAtkins> fantasai: so far "thumb", "track", "fill"<br> <emilio> There's also the benefit of typing `::slider-` and seeing all of them together in your editor :-)<br> <TabAtkins> ntim: there's another issue to add something for color-swatch<br> <TabAtkins> bkardell: "ruler" or "meter", the tick marks<br> <astearns> 1: keeping the slider- prefixes for thumb and track<br> <astearns> 2: just use thumb and track<br> <TabAtkins> fantasai: i think we need to amke sure the prefix is consistent for all the parts, eithe rprefix all or none<br> <TabAtkins> fantasai: if we think prefixing some is okay and others aren't we ahve a problem<br> <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<br> <ydaniv> +1 to lea<br> <TabAtkins> lea: if we don't prefix these we can still name individual ones better<br> <TabAtkins> STRAW POLL TIME<br> <ntim> 2<br> <TabAtkins> 1<br> <ydaniv> 2<br> <lea> 2<br> <smfr> 1<br> <astearns> 1<br> <noamr> 1<br> <kurt> 1<br> <emilio> 1<br> <ChrisL> 2<br> <bkardell> 1.5<br> <oriol> 1<br> <alisonmaher> 1<br> <rachelandrew> 1<br> <kbabbitt> 1<br> <schenney> 1<br> <kizu> 1<br> <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./<br> <bkardell> q+<br> <bkardell> q-<br> <noamr> We have `:active-view-transition-type`, I think `:slider-fill` is short<br> <dbaron> emilio: I like the autocomplete aspects of the ::slider prefix.<br> <TabAtkins> I think slider-fill is *too* short, based on precedent. we need longer words<br> <bkardell> q+<br> <TabAtkins> astearns: looks like prefixes are winning<br> <TabAtkins> ntim: okay, prefixes are in the previous resolution<br> <TabAtkins> bkardell: each of those controls are sliders currently<br> <TabAtkins> bkardell: so nothing changes in terms of what the pseudo-element applies to<br> <lea> q+<br> <astearns> ack bkardell<br> <TabAtkins> ntim: it would apply to switch, range, meter, and progress<br> <bkardell> 2<br> <bkardell> since that is generic behavior, I think 2<br> <TabAtkins> lea: if we keep these prefixes it makes it harder to use descreptive names, becuase it's already long<br> <TabAtkins> lea: i think "fill" is confusing, "slider-fill" is still confusing, but "slider-track-fill" would be too long<br> <TabAtkins> astearns: so we'll take a resolution to keep the prefixes, based on straw poll<br> <TabAtkins> astearns: if we have better argumetns in the future we can revisit<br> <TabAtkins> astearns: proposed reoslution is keep slider prefixes and close the issue<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: Keep the slider-* prefixes and close the issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9830#issuecomment-2770253830 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 April 2025 17:53:22 UTC