- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 1 Jul 2016 17:46:44 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Dean Jackson <dino@apple.com>, www-style list <www-style@w3.org>
[I don't know what client you're using, but whatever they On Fri, Jul 1, 2016 at 5:37 PM, Maciej Stachowiak <mjs@apple.com> wrote: >> (Alternate syntax: use units for these, like `spring(2mass >> 5velocity)`. Stronger connection between value and type, but also >> maybe weird? Unsure.) > > > "mass" and "velocity" aren't units, they are types of units. This would be > like writing "8length" instead of "8px". > > Please don't make physicists cry. But in this circumstance they're *families* of units - velocity might be px/sec, or hue/sec, etc. Classifying that as a generic unit "velocity" doesn't seem *too* crazy to me. (That said, this is my least favorite syntax possibility.) >> (Second alternate syntax: finally invent "named arguments" for real, >> like some people have been agitating for for a while. `spring(mass: >> 2; velocity: 5;)`? To be less weird we'd have then go and backport >> this to other functions. Probably a decent idea? Need to noodle on >> syntax more, look at several different functions that use syntax >> differently. > > That's a more appealing syntax and makes it easier to figure out defaults. Kk. This is just the more formalized version of option 1 (just do keyword/number pairs), and implies that we need to do the work of porting it back to other functions and properties. >>> We could pick another formula that is more amenable to duration-based >>> springs. >>> >>> However, there is some criticism against coding an animation like this >>> purely on duration: >>> https://medium.com/@flyosity/your-spring-animations-are-bad-and-it-s-probably-apple-s-fault-784932e51733 >> >> That criticism is geared towards a bad API design that required you to >> specify a *technically redundant* duration, and if you didn't specify >> what the algo would have "naturally" provided you get an >> unnatural-looking result. > > My read is that it actually solves the spring equation in reverse and > computes a stiffness and mass for the given duration. There is no stiffness > or mass provided to the API, just damping (as a ratio, presumably relative > to stiffness or something) and initial velocity. So the duration is not > redundant. > > I think the reason the spring examples using the API look bad is that > authors are likely to severely underestimate the duration required for a > comfortable looking bounce, thus resulting in springs with crazy high > stiffness which look awkward even though they are technically correct. Ah, that might be right, I didn't dive deeply into the examples given. If that's the case, then yeah, it implies that authors are just generally terrible at figuring out durations properly, and we should indeed avoid specifying them explicitly. But that leans more on my other point, that this implies we should work more on animation sequencing, which is currently deferred to v2 of WebAnim. ~TJ
Received on Saturday, 2 July 2016 00:47:32 UTC