- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Mon, 27 Jun 2022 20:36:14 +0000
- To: public-css-archive@w3.org
I don't think it's useful to draw an implicit connection to `steps()`, which does something relatively different. (Technically `steps()` can be reproduced with this function, but the "steps" mean something more than just "segments" - they imply horizontal extension, as if they were steps on a staircase.) Strongly opposed to `ease()`, as this isn't *remotely* related to the `ease-*` keywords, all of which are specifically about *smoothly curving*. Similarly opposed to `easing()`; it also doesn't match the conjugation of the other values. We already have a function + related keywords group (`steps()` and `step-*`) and this would completely break with the pattern they establish. I'd block this if it came to it. Mildly opposed to `linear-spline()` - the "spline" doesn't add anything useful, and we've omitted that word from `cubic-bezier()`, which is technically a "cubic Bezier spline". Would be okay with `piecewise()`, tho I prefer `linear()` over it. It's a little more complex in spelling (I'm always against words with the `ie` compound if they can be avoided, as whether English spells that sound "ie" or "ei" is pretty random.) I *have* used "piecewise linear" to refer to functions like this; the term doesn't necessarily imply the ability to have C0 discontinuities like `steps()` produces. `linear()` is definitely the best option. We've done the "keyword and function with same name" variations before (notably in pseudo-classes, but I think elsewhere?), and it fits the "keyword is the obvious default arguments to the function" pattern we use there. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7419#issuecomment-1167861313 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 27 June 2022 20:36:15 UTC