- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 27 Jan 2026 17:10:39 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-forms-1] Define range slider datalist integration`. <details><summary>The full IRC log of that discussion</summary> <bramus> lwarlow: css forms is a WIP spec to make form controls stylable<br> <bramus> … with a special appearance mode<br> <bramus> … in l1 we focus on in-page controls, with exception of select<br> <bramus> … other pickers are out of scope in L1<br> <bramus> … there is 1 case where datalist have impact on the page rendering control, which is with the range input<br> <bramus> … you can give the datalist a list of options to render the ticks along the slider track<br> <bramus> … that is sth we have not specified yet<br> <bramus> … on top of that it is mentioned in the HTML spec (but ont implemented anywhere AFAIK), optoins can contain text or have a label attribute<br> <bramus> … is not used when rendering those ticks, but not uncommon to have labeled ticks<br> <bramus> … if we could come up with a way to do that<br> <bramus> … there is an idea in the Open UI enhanced range, that we have new pseudos<br> <astearns> ack lwarlow<br> <bramus> … ::slider-tick and ::slider-tick-label<br> <bramus> … havent discussed or integrated any of that<br> <bramus> … but are potential ways to do this<br> <bramus> … could be functional pseudos to take an index<br> <bramus> … wanna see what ppl think here<br> <astearns> ack dbaron<br> <bramus> dbaron: historical tihng about label and option<br> <bramus> … believe label attr on option was introduced as the same time as the optgroup element<br> <bramus> … designed as ??? and label would be used in optgroup supported browsers<br> <bramus> … a later spec change might have messed up that logic<br> <bramus> astearns: other comments?<br> <bramus> lwarlow: if anyone knows a browser that has implemented the label, but AFAIK none do … but I assume the screenshots in the spec come from _somewhere_<br> <bramus> … thinking about how styling would work<br> <bramus> … I think the ticks are ??? in paint<br> <emilio> q+<br> <bramus> … would be curious to see how we render this with CSS concepts<br> <ntim> s/???/implemented<br> <bramus> ntim: yes, just a paint thing<br> <bramus> emilio: same in gecko<br> <bramus> … would probably, like not do this for the base apperance thing. need to define a very similar thing that mirrors the option text into the button of the select<br> <bramus> … could use some of that, but my guess is that its gonna be fairly annoying to both spec and implement … feels niche<br> <bramus> … never seen a slider use this<br> <bramus> fantasai: prbably because its not stylalbe right now<br> <bramus> ntim: ticks are not very informative right now. from a UX you cant see which values they correspond to, so thats why folks dont use them I think<br> <miriam> I use them, but agree they're pretty limited<br> <bramus> … curious what component authors do<br> <bramus> emilio: we should probably not block most of the slider on this<br> <bramus> … if we can do it in two steps<br> <bramus> … getting sliders interoperable seems more important than datalist<br> <miriam> q+<br> <Kurt> q+<br> <bramus> castastrophe: a tick can be valuable if there is a density of data, like label every 5th instead of every single tick. might still need the tick for all, but not a label for all<br> <astearns> ack emilio<br> <lwarlow> +1 to that<br> <bramus> … a dense amount of that could use a tick<br> <bramus> +1<br> <astearns> ack miriam<br> <bramus> miriam: I use these fairly regularly but they are limited becase you cant have a visual label and cant style them<br> <bramus> … would be useful to be able to do that<br> <lwarlow> q+<br> <bramus> … choosing between a select and range … like font-sizes, might have ratios that are popular to only label the popular values<br> <castastrophe> q+<br> <bramus> … or like zoom values: only label 100%, 200%, etc<br> <dbaron> s/designed as ??? and label/designed so non-optgroup supporting browsers would use the contents of the option element and label/<br> <bramus> … or if you want the starting point to be marked, not the rest<br> <bramus> … i.e. putting a mark where the range defaults<br> <bramus> … would be super useful if we could label and style<br> <astearns> ack Kurt<br> <bramus> Kurt: are these labels relative to the max attr value?<br> <bramus> lwarlow: if you have options that … my hunch would be that they are absolute values, and ticks above the max dont get rendered<br> <bramus> … not sure if when the max changes ???<br> <bramus> Kurt: just changes the value.<br> <bramus> … considering how the max scales thigs<br> <lwarlow> There's examples at https://brechtdr.github.io/enhanced-range-slider-poc/ fwiw mostly around multi range but some still apply.<br> <bramus> … I know animations have percentages in their keyframes<br> <bramus> … could use inspiration from there<br> <bramus> … see how min/max impact those<br> <astearns> ack lwarlow<br> <bramus> lwarlow: regarding use-cases, here are some that Brecht has put together<br> <bramus> … (see link)<br> <bramus> … one of them is opening hours for example, or time-based stuff<br> <bramus> … or if you have a set of values (1-5-10-50-100)<br> <bramus> … the questions on what these values represent are things to think about<br> <bramus> … maybe some existing implementations can be used<br> <astearns> ack castastrophe<br> <bramus> castastrophe: two thoughts<br> <iank_> How do I get in the building?<br> <bramus> … 1. hear what emilio is saying to not block progress<br> <bramus> … but from designer standpoint, the ability to style the ticks and labels, I might have to redesign the thing … pass the data to the semantic one. withou tstyling of the more specific features its not gonna be as usable<br> <bramus> … users might skip it entirely then<br> <bramus> … 2. I like the datalist aproach, but dont think it scales well … translations and i18n … the value would need to be assigned to languages or abstracted to be more like how JS processes numbers.<br> <bramus> … like “I want to represent this as currency”<br> <bramus> … otherwise you need mutliple datalists … having some logic that replaces the datalist based on language<br> <bramus> … the more common use-cases would be representing numbers as currency, fractions, whole numbers, …<br> <bramus> … if we could make that translatable, this would scale bettter<br> <lwarlow> That's a very good point.<br> <bramus> astearns: thanks for the input, and lets continue working on it in 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/12963#issuecomment-3806424958 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 27 January 2026 17:10:40 UTC