Re: [csswg-drafts] [css-forms-1] `control-value()` function (#7869)

The CSS Working Group just discussed ``[css-forms-1] `control-value()` function``, and agreed to the following:

* `RESOLVED: Accept control-value() as described in the draft (with subsequent edits)`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> ntim: a problem devs often ahve is they want to refer to the value insdie a range or text input<br>
&lt;TabAtkins> ntim: for range input, you see a bubble with a number in it following the thumb<br>
&lt;TabAtkins> ntim: in the current Forms draft there's a control-value() function<br>
&lt;TabAtkins> ntim: syntax is draft-y, i think we can match attr()<br>
&lt;TabAtkins> ntim: i'm hoping to get a formal resolution<br>
&lt;TabAtkins> q+<br>
&lt;lea> q+<br>
&lt;TabAtkins> ntim: and maybe we want to think about the problem of, do we want to scope this to the control itself, or allow other elements to refer to the values of other elements<br>
&lt;TabAtkins> ntim: havne't thought too mucha bout that yet<br>
&lt;astearns> ack TabAtkins<br>
&lt;lea> TabAtkins: I think we should add this. Few details that I listed. Control value is just as dangerous as `attr()` but should be solvable the same way, just repeat the same handling<br>
&lt;lea> TabAtkins: 2. I don't think we should exactly match the attr() syntax, we're not doing arbitrary parsing of an unknown string, we have a well-known value coming from the control<br>
&lt;lea> TabAtkins: getting it as a string is always useful, getting it as a number also useful<br>
&lt;lea> TabAtkins: other than that, I think it's a good idea and we should do it<br>
&lt;TabAtkins> ntim: i agree we should let people switch the types. might want it as a number to use in a calc() to set a width<br>
&lt;astearns> ack lea<br>
&lt;TabAtkins> lea: also agree we should do it<br>
&lt;TabAtkins> lea: how do web components hook into this for their own values?<br>
&lt;TabAtkins> lea: and also, we do want it to inherit in some way. the tooltip of a slider often shows the slider value. so how does that work if it's only on the slider itself.<br>
&lt;TabAtkins> TabAtkins: if it's a pseudo-element it's fine, they refer to the main element<br>
&lt;kbabbitt> q+<br>
&lt;TabAtkins> lea: yeah but that doesn't solve a custom element<br>
&lt;TabAtkins> ntim: yup, pseudo-elements get you part of the way, but not all the wya<br>
&lt;TabAtkins> lea: if it resolves at the right time it's not insumoutable<br>
&lt;TabAtkins> ntim: how does inheritance work?<br>
&lt;TabAtkins> ntim: you'd need to get the value out of the slider and pull it up?<br>
&lt;TabAtkins> TabAtkins: yeah that's hard<br>
&lt;kizu> anchor positioning and scroll-driven animations :)<br>
&lt;astearns> ack dbaron<br>
&lt;TabAtkins> ntim: the separate element reference can be another issue<br>
&lt;TabAtkins> dbaron: there was some discussion of security restrictions in the bug, wanted to make sure it's not list<br>
&lt;TabAtkins> TabAtkins: yeah, i mentioned it should be the same as attr()<br>
&lt;astearns> ack kbabbitt<br>
&lt;TabAtkins> ntim: yup, to avoid exfiltration into a url<br>
&lt;dbaron> s/list/lost/<br>
&lt;TabAtkins> kbabbitt: i was also thinking about security issue here. wondering if it has to be stronger than attr(), like using it on a password input<br>
&lt;TabAtkins> kbabbitt: i don't know if attr() already addresses this<br>
&lt;TabAtkins> TabAtkins: it should, the attr() restriction prevents any value produced by it to be used in a url<br>
&lt;TabAtkins> astearns: so it sounds like we're just asking for waht's in the draft to be blessed?<br>
&lt;TabAtkins> ntim: yeah<br>
&lt;TabAtkins> astearns: proposed resolution: control-value() as described in the draft looks reasonable<br>
&lt;TabAtkins> RESOLVED: Accept control-value() as described in the draft (with subsequent edits)<br>
&lt;TabAtkins> dbaron: also wanted to point out there's proposals to have selectors that depend on control values<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7869#issuecomment-2776258699 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 3 April 2025 15:54:38 UTC