Re: [csswg-drafts] Interpolate values between breakpoints (#6245)

This seems very related to this issue I opened last month: https://github.com/w3c/csswg-drafts/issues/11530

I’m still digesting @tabatkins' proposal in https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-2661545284 so apologies if I’ve missed something.

While not a strong objection, I’m not crazy about the idea of introducing even more functions. I don't see a strong disambiguation reason to do so (color stop positions can just always come after the value), and it makes the language harder for authors. Much easier to find what they are looking for when there is a 1-1 mapping of functions to purposes (it's already suboptimal that we need to have multiple functions for each interpolated type, but I understand the reasons for this…). Conceptually, "I want to interpolate between A and B" is not that different from "I want to interpolate between A, B, and C" to warrant a whole different function.

I do agree that mixing and interpolation do seem like fundamentally different concepts. However, do we actually _need_ mixing versions for other types of values? For color, mixing has an established meaning in the physical world, but I don't think anyone thinks about mixing `<length>` or `<number>` units. What does that even mean? And I’m not even sure the concept makes sense for images, at least any more than interpolation. We _generally_ don't add nontrivial features for completeness' sake, so if there are no use cases for mixing anything other than colors, then we shouldn't have these. 

I’m more strongly opposed to the `*-map()` naming. Maps have an established meaning in both programming languages and CSS preprocessors: they help you transform one (often categorical) value into another, e.g. so one can do things like transform `vertical` into `column` and `horizontal` into `row`. There have been several requests to add mapping functions to CSS (#7273 came up from a quick search, but pretty sure there have been many more). While something like `calc-map()` doesn't preclude something like `map()` or `map-get()` or whatever from being added, it does mean that now the same terminology is used for two distinct concepts. But even if we never add mapping functions, the concept still exists so having a `*-map()` function that doesn't work like a map is very confusing.

So if we don't name them `*-map()` what _do_ we name them? The obvious choice is something around interpolation (e.g. `calc-interpolate()`) though that is both exceedingly long and overly technical (violating [TAG principle 12.1: Use common words](https://www.w3.org/TR/design-principles/#naming-common-words)). 

| Name | Common word? | Short? | Clear? (to those who know the word) |
|------|--------|--------|--------|
`*-interpolate()` | ❌ | ❌ | ✅  | 
`*-tween()`| ❌ | ✅ | ✅  | 
`*-range()` | ✅ | ✅ | ❌ Sounds like it returns a range, rather than a value |
`*-intermediate()` |  ✅ | ❌ | ✅  |
`*-scale()` |  ✅ | ✅ | ✅  | 

Yup, the more I think about it, the more it seems to me that `*-scale()` ticks all the boxes. `color-scale()` is _particularly_ fitting, but `calc-scale()` doesn't seem bad either. `image-scale()` is a bit weird (looks like it's scaling an image) but oh well.
In fact, I think it's a sufficiently good name that I withdraw my (very weak) objection above about having multiple functions. 😁 

-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-2685663483 using your GitHub account


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

Received on Wednesday, 26 February 2025 17:00:46 UTC