- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Apr 2026 23:36:19 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-forms-1] Define range slider datalist integration`, and agreed to the following:
* `SUMMARY: This needs more work in HTML (to clone options) and CSS (to be able to style it), not part of appearance: base for now.`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> ntim: If you have input type=range and datalist, you get a bunch of tick marks that represent the different points in the data list<br>
<emilio> ntim: if you use range inputs with datalists you get tickmarks that represent points in the datalist<br>
<fantasai> ntim: as a guide where you can snap the lines to<br>
<fantasai> ntim: We discussed a few alls ago to try to standardize for appearance:base<br>
<fantasai> ntim: Takeaway from that conversation, that UI wasn't ideal to represent the datalist options<br>
<fantasai> ntim: So I wonder how we should continue that discussion for appearance:base<br>
<fantasai> ntim: Should we decide to not have those tickmarks at all for appearance:base?<br>
<fantasai> ntim: Should we standardize something else?<br>
<emilio> q+<br>
<fantasai> ntim: leaving that open.<br>
<astearns> ack emilio<br>
<fantasai> emilio: I think I lean towards not including this in MVP of form controls<br>
<fantasai> emilio: Feels very niche and also hard to define<br>
<fantasai> emilio: Seems you need something to reflect the datalist into the DOM some other way<br>
<fantasai> emilio: then you need to position them<br>
<fantasai> emilio: If author is using range ... not clear what the best way is to have base styles<br>
<fantasai> emilio: It seems pretty high effort for low value to me<br>
<ntim> q+<br>
<fantasai> emilio: Would rather get the other range pseudo-elements standardized and getting it to work cross-browser<br>
<fantasai> emilio: if we figure out tick marks we can add an opt in<br>
<fantasai> astearns: I suggested appearance:base iteration in the past, but told we need to have a single set of styles andnever change them once shipped<br>
<fantasai> emilio: Single styles is good, but extending is ok<br>
<fantasai> emilio: Main benefit of this would be proper cross-browser styling of track and inputs<br>
<astearns> ack ntim<br>
<fantasai> ntim: Emilio brought up HTML extensions<br>
<fantasai> ntim: I wonder if the right way forward is to purse this in HTML with potentially some CSS extensions<br>
<fantasai> ntim: but use new HTML elements to achieve the tick marks<br>
<fantasai> ntim: And potentially those elements can cover more than just tick marks<br>
<fantasai> ntim: like maybe they can reflect datalist options in different ways<br>
<fantasai> ntim: and CSS can [missed]<br>
<fantasai> emilio: I don't have a concrete idea of how to expose base styles in a way that doesn't require HTML magic<br>
<fantasai> emilio: to reflect the datalist options into the range input's shadow tree<br>
<fantasai> fantasai: Association of datalist and input?<br>
<fantasai> emilio: yes<br>
<emilio> (list attribute)<br>
<fantasai> fantasai: can multiple inputs reference the same datalist?<br>
<fantasai> fantasai: yes<br>
<fantasai> s/fantasai/emilio<br>
<fantasai> emilio: so need to create representation of the elements in the input tree<br>
<fantasai> ntim: ...<br>
<fantasai> emilio: Feels weird to require a wrapper element<br>
<fantasai> emilio: but I think we shouldn't have it on appearance:base for now<br>
<fantasai> emilio: This requires somewhat significant HTML magic, some of which has precedent<br>
<fantasai> emilio: like the <selectedcontent> stuff<br>
<fantasai> emilio: but the effort required to get this to work seems significantly higher<br>
<ntim> s/.../appearance: base should maybe not have tickmarks by default, and authors should maybe use new HTML features/<br>
<fantasai> emilio: main benefits of standardized range inputs don't include datalist<br>
<fantasai> emilio: this is something we could extend later<br>
<fantasai> emilio: tried to brainstorm the right way to expose these<br>
<fantasai> emilio: but if you expose N tickmark elements, that seems potentially useful<br>
<fantasai> emilio: but also pretty wasteful<br>
<fantasai> emilio: right now they're just a paint-time effect<br>
<fantasai> emilio: so a lot more lightweight han an element<br>
<fantasai> ntim: I don't think we should have pseudo-elements<br>
<fantasai> ntim: having a wrapper doesn't seem unreasonable<br>
<fantasai> ntim: Discussing extensions to range<br>
<fantasai> ntim: could think of a future where people start to have HTML elements and want to have tick marks<br>
<fantasai> ntim: and have fancy range features<br>
<astearns> ack fantasai<br>
<emilio> fantasai: The fact that you need to duplicate it means you need some HTML support to create these<br>
<emilio> ... you need one per option<br>
<emilio> ... and you also want labels on them<br>
<emilio> ... so it's going to have to be pseudo-elements so that they can style the labels<br>
<emilio> ... I'm not really sure how this would be styled, maybe with an anchor() function<br>
<emilio> ... need the various start / end attributes and such to get the right position<br>
<emilio> ... so definitely needs some work, but let's assume that we had the elements<br>
<emilio> ... there's the option of how we generate the elements<br>
<emilio> ... assuming we had them how would we style them?<br>
<ntim> <range><input type=range><indicators></indicators></range><br>
<emilio> astearns: so punt for now?<br>
<ntim> I had something like this in mind<br>
<emilio> fantasai: the thing we need the most is taking a set of markup that represent a datalist input with html<br>
<emilio> ... and determine how do you style it?<br>
<emilio> ... what's missing that we need to add to CSS<br>
<emilio> ... and what structure does the HTML need to have<br>
<emilio> astearns: ntim just posted a markup mockup<br>
<emilio> fantasai: with shadow dom it could be a children of the input<br>
<ntim> with CSS extensions or inserted elements to support the <indicators> element potentially<br>
<fantasai> emilio: question is if we magically clone the datalist content<br>
<fantasai> emilio: still need some sort of magic to communicate the datalist option value<br>
<fantasai> emilio: maybe something like inset-start: control-value()/input-max()-input-min() ... that gets you your position, don't need anchoring<br>
<fantasai> emilio: if you want labels, need some extra stuff<br>
<fantasai> emilio: if you want only some labels<br>
<ntim> indicators::label(...) {....}<br>
<emilio> fantasai: if you duplicate the datalist content and can select based on that then the author can choose<br>
<fantasai> emilio: But for me, I'd punt on this for the initial version, and explore wit HTMl bikeshedding how to make this work<br>
<fantasai> emilio: And seeing if it would be really useful<br>
<fantasai> emilio: And figure out cloning. The strings and tick marks etc.<br>
<fantasai> astearns: Perhaps we should not include it for now<br>
<fantasai> SUMMARY: This needs more work in HTML (to clone options) and CSS (to be able to style it), not part of appearance: base for now.<br>
<ntim> Proposed SUMMARY: Let's not include tickmarks for appearance: base at the moment. Work with HTML to see if we can come up with markup that can address more use cases than tickmarks.<br>
<fantasai> ntim: Other reason to work with HTML, last time we didn't hear that authors particularly needed it<br>
<fantasai> ... so need to address more than just tickmarks<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-4173587140 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 April 2026 23:36:20 UTC