-
Notifications
You must be signed in to change notification settings - Fork 654
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-values] Proposal for a 'progress' function to calculate progress between two <length> values #7268
Comments
And could also work with calculation values other than lengths. |
I guess this issue would be solved if we could have custom mathematical functions |
Having the ability to reproduce it by hand doesn't necessarily preclude us adding it in natively, if it's sufficiently useful and the manual reproduction is sufficiently annoying. I think this qualifies. |
I agree this should be easier. Some thoughts that might help with naming/syntax: Both --progress: progress(100vw, 375px, 1920px);
font-size: mix(var(--progress), 24px, 32px);
If we have ad hoc functions like that, I think it should somehow be obvious from naming that one is the inverse of the other: But what if we exposed the actual range mapping operation? We could have a font-size: map(100vw in 375px to 1920px into 24px to 32px); or font-size: map(100vw in [375px, 1920px] to [24px, 32px]); or something (syntax TBB). Note that these could also be stored in variables to be reused for every conversion: :root {
--page-widths: [375px, 1920px];
}
/* ... */
font-size: map(100vw in var(--page-widths) to [24px, 32px]); or even: :root {
--page-width-progress: 100vw in [375px, 1920px];
}
/* ... */
font-size: map(var(--page-width-progress) to [24px, 32px]); |
I agree that the name should reflect that this function is the inverse of
🤣
A range mapping function would be great! At the moment Easing could let us do something like --progress: inverse-mix(100vw, 375px, 1920px);
font-size: mix(var(--progress) ease-in-out, 1rem, 1.25rem) It would be great to be able to use easing functions in map as well, so the syntax should have room for extending in the future: map(100vw in [375px, 1920px] to [24px, 32px] ease-in-out) Also, while a |
I seem to have provided an example where |
Just some notes:
|
Yes, just determining the interpolation progress within a range, in a linear fashion, seems sufficient, and avoids all the complexities and incongruities of trying to invert an easing function, which as you note is not in general an invertable function! |
It might be useful to provide a way to invert the easily-invertible easing functions that we have. I believe the inverse of a |
Note that |
There are discussions in #6245 for alternative ways of interpolating values between breakpoints. I still think a ‘progress’ or ‘position-of’ function would be useful for individual properties and more advanced calculations. |
Seems like |
In range input, progress has different calculation modes. In the following example, the right edge of progress is always in the middle of the thumb. This prevents the rounded corner radius from changing and overflowing when dragged to the far left. 2023-12-29.16-30-27.mp4With .slider-progress {
--p1: calc((var(--range) - var(--range-min)) / (var(--range-max) - var(--range-min)));
--w1: clamp(28px, calc(100cqi * var(--p1)), calc(100cqi - 28px));
} 2023-12-29.16-31-01.mp4My question is, how can I implement such an algorithm using |
@fantasai @mirisuzanne Could this issue be closed now that |
While it's in the Editor's Draft, I don't see any official resolution from the WG. We would need to get that approval before we publish a new Working Draft (and close the issue). Seems the last time we brought it up (in #6245) was just to introduce the proposal, without asking for a resolution. If we think we're ready for a resolution, we could bring one of these issues back to the group. @andruud or @danielsakhapov - I think you were exploring a prototype at one point, and had some questions that we might want to address? Are those documented as issues anywhere? |
@mirisuzanne I don't think we've found anything bad, apart from the fact that browsers will have a lot of work to implement it for non-length accepting properties, since none of them (my estimation) are ready to deal with cases like - number-producing math function with relative units dependency (I guess you can see it now with sign() function here). |
@mirisuzanne I think we should probably change this part:
and have it compute to the actual (numeric) progress of the timeline instead (post-easing). We generally resolve things at the earliest point they can be resolved, and I'm not sure what we gain from delaying the computation here except increased implementation difficulty. |
The proposal is to add a new function to css-values-4 that calculates the progress between two
<length>
values in percent. The new function could be used together with the newmix
function to improve readability of fluid sizes.The syntax of the progress functions could be as follows:
All arguments are
<length>
values, while the return value would be a<percentage>
value representing the progress of the input between the min and max values. Progress would be clamped between0%
and100%
.The function could then be used together with
mix()
to calculate fluid sizes:This would work well with container query units as well
The proposed function is not new functionality, but would be syntactic sugar for
Name to be bikeshedded.
Motivation
Fluid typography has been around for years, but the css necessary to achieve it is hard to create and read.
The
clamp()
function makes it possible to create fluid typography with less bloat: Example copied from article above:It is still complicated to calculate the slope and intercept values necessary to create a fluid type that scales from a minimum to a maximum viewport size. It is not possible understand the min and max viewport sizes from reading the notation.
Preprocessors or other tools can be used to calculate the values, but this does not improve the readability.
The new mix funcion could let us interpolate between two font-sizes, as long as we have a progress argument:
The text was updated successfully, but these errors were encountered: