Re: [csswg-drafts] [css-values-4] Should progress() functions clamp to 0-100%? (#11825)

The CSS Working Group just discussed `[css-values-4] Should progress() functions clamp to 0-100%?`, and agreed to the following:

* `RESOLVED: progress clamps by default between 0 and 1; we'll add unclamped keyword, or other keyword if folks have suggestions`

<details><summary>The full IRC log of that discussion</summary>
&lt;kbabbitt> bramus: this is about the clamping in the progress function<br>
&lt;kbabbitt> ... which is about to ship in Chrome<br>
&lt;kbabbitt> ... and Safari<br>
&lt;kbabbitt> ... currently progress() does not clamp to 0..100%<br>
&lt;kbabbitt> ... but reading comments there is a request to have it clamp in some way<br>
&lt;kbabbitt> ... options are: have it clamp by default, add an extra keyword<br>
&lt;kizu> q+<br>
&lt;kbabbitt> ... as part of first argument<br>
&lt;kbabbitt> .. alternative is inverse of clamp by default<br>
&lt;kbabbitt> ... would like a resolution before this hits<br>
&lt;kbabbitt> q+<br>
&lt;Rossen6> ack kizu<br>
&lt;kbabbitt> kizu: my opinion is we should clamp by default and have unclamp keyword<br>
&lt;kbabbitt> ... most cases I've tested want this<br>
&lt;kbabbitt> ... kind of already a shortcut around some math<br>
&lt;kbabbitt> ... possible to do the same with math already but this makes it more convenient<br>
&lt;kbabbitt> ... for most cases clamping will add more convenience<br>
&lt;ydaniv> +1<br>
&lt;kbabbitt> ... for cases where you need unclamped we can stiill have a keyword<br>
&lt;fantasai> +1 to kizu<br>
&lt;TabAtkins> scribe+<br>
&lt;TabAtkins> kbabbitt: I was curious - I can imagine the use-case for clamped, can someone give a use-case for unclamped progress?<br>
&lt;TabAtkins> weinig: I think any use-case mimicing an animation, since they can go beyond the 0-100% bounds<br>
&lt;TabAtkins> weinig: so if you're doing an overshoot, that can be useful<br>
&lt;flackr> +1<br>
&lt;TabAtkins> kbabbitt: for css animation, we don't have that behavior, we have basically clamping with fill-mode<br>
&lt;TabAtkins> flackr: if you have an easing curve, you can easily go beyond the endpoint with animations<br>
&lt;TabAtkins> kbabbitt: true<br>
&lt;iank_> (I'm dropping now - would be appreciated if we can bump https://github.com/w3c/csswg-drafts/issues/3059 to next week if possible)<br>
&lt;TabAtkins> kbabbitt: in progress(), couldn't you achieve that by encoding your stops to form that same curve?\<br>
&lt;TabAtkins> kbabbitt: i'm mixing this up with interpolate(), nm<br>
&lt;Rossen6> ack fantasai<br>
&lt;kbabbitt> fantasai: I think kizu and kbabbitt covered the things I was going to say<br>
&lt;TabAtkins> fantasai: i think roman and kevin covered what i want to say<br>
&lt;kbabbitt> ... it is a convenience notation<br>
&lt;Rossen6> ack kbabbitt<br>
&lt;TabAtkins> q+<br>
&lt;kbabbitt> ... clamping would cover most use cases<br>
&lt;kbabbitt> ... so that should be default behavior<br>
&lt;Rossen6> ack TabAtkins<br>
&lt;kbabbitt> TabAtkins: don't have a strong opinon on clamped or unclamped<br>
&lt;kbabbitt> ... weak preference for unclamped by default and keyword being clamped<br>
&lt;kbabbitt> ... based on usability of syntax<br>
&lt;miriam> q+<br>
&lt;kbabbitt> ... clamped is a shorter word, not conjugated<br>
&lt;kbabbitt> ... matches what function is doing in the first place<br>
&lt;kbabbitt> ... ignoring use cases, would go unclamped by default with clamp keyword<br>
&lt;kbabbitt> ... but if others feel there are strong use cases to go one way or other, happy to defer<br>
&lt;kbabbitt> +1 to TabAtkins<br>
&lt;Rossen6> ack miriam<br>
&lt;kbabbitt> miriam: agree that clamped is the only use case I've run into<br>
&lt;TabAtkins> `progress(var(--val) clamp, 1, 10)` simpler than `progress(var(--val) unclamped, 1, 10)`<br>
&lt;kbabbitt> ... there are use cases for unclamped but clamped seems default use case<br>
&lt;kbabbitt> ... ok as long as switching is simple<br>
&lt;fantasai> TabAtkins, that assumes you want them both equally. I think we're saying that's not true.<br>
&lt;kbabbitt> to clarify, my +1 is to "base it on strength of use cases"<br>
&lt;TabAtkins> Yes, I was just providing the syntax example directly, since kbabbitt minuted me as saying "clamped". ^_^<br>
&lt;kbabbitt> bramus: if others are saying clamp by default I think that's the way we should go<br>
&lt;kbabbitt> fantasai: Proposal is that progress clamps by default between 0 and 1<br>
&lt;kbabbitt> ... and we'll add unclamped keyword, or other keyword if folks have suggestions<br>
&lt;kbabbitt> RESOLVED: progress clamps by default between 0 and 1; we'll add unclamped keyword, or other keyword if folks have suggestions<br>
</details>


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


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

Received on Wednesday, 18 June 2025 16:41:12 UTC