- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Apr 2025 18:12:41 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-forms-1] Should `::slider-track` always precede `::slider-fill`?``, and agreed to the following: * `RESOLVED: The originating element of ::slider-fill is the input element, not the ::slider-track.` * `RESOLVED: The slider-fill is a child of the slider-track in the pseudo-element tree` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> ntim: so should ::slider-track always be before ::slider-fill?<br> <TabAtkins> ntim: track is the track itself, fill is the progressed part<br> <TabAtkins> ntim: current draft defines fill to be a child of the track, not a sibling, so this might not apply<br> <TabAtkins> ntim: this was Ana Tudor's conclusion too<br> <TabAtkins> TabAtkins: so if we stick witht he current spec, where fill is a child of track, it's moot?<br> <TabAtkins> ntim: yes<br> <TabAtkins> astearns: ah it's in the draft but without a resolution?<br> <emilio> q+<br> <TabAtkins> ntim: yes. we have a resolution on the *thumb* being a sibling of the track, but nothing on where the fill lives<br> <TabAtkins> bkardell: i went back and forth on a bunch of these with Ana<br> <fantasai> So <slider><::track><::fill/></::track> <::thumb/></slider> ?<br> <TabAtkins> bkardell: so the proposal is that fill is a child of the track?<br> <TabAtkins> ntim: yes<br> <TabAtkins> ntim: Ana's rationale was if you apply a padding to the track you want to push the fill in<br> <TabAtkins> fantasai: i think that makes sense, and once it's a little more drafted we should ask Ana for a review<br> <astearns> ack emilio<br> <TabAtkins> emilio: isn't this unrelated to where it goes in the tree?<br> <TabAtkins> emilio: i think OP is whether you shoudl always nest the pseudo, but that's unrelated to where they are in the tree<br> <TabAtkins> TabAtkins: ah indeed, this issue is aobut how you spell the selector. i agree that we shoudln't require `::slider-track::slider-fill`. We can just allow `::slider-fill` and still have it be a child of the track in the dom tree.<br> <TabAtkins> ntim: if we can resolve on the tree position that's nice too tho<br> <TabAtkins> ntim: becuase that affects this still, siblings *wouldn't* nest<br> <TabAtkins> TabAtkins: not necessarily. they really are independent. nesting is just useful if we need to scope things, like in a few VT bits. But you don't need to do a full chain of VT pseudos.<br> <TabAtkins> emilio: so reoslution should be originating element of ::slider-fill is the input element, not the ::slider-track<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: The originating element of ::slider-fill is the input element, not the ::slider-track.<br> <TabAtkins> astearns: and we can also take a resolution on the fill being a child of the track in the pseudo tree<br> <TabAtkins> bkardell: coudl we put it off for a bit?<br> <TabAtkins> ntim: we can always revisit.<br> <TabAtkins> fantasai: can we just resolve and say that if Ana has another opinion we reopen?<br> <TabAtkins> astearns: so proposed reoslution is that fill is a child of the track in the pseudo-tree<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: The slider-fill is a child of the slider-track in the pseudo-element tree<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11330#issuecomment-2770307323 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 18:12:42 UTC