* consistent sidebar tutorial
- added css-var for light sidebar-text for easy handling
- provide higher contrast for better readability in code and blockquotes
- push SHOW ME with higher contrast (on dark instead on white)
* minor fixes on opacities and color
* adjust sidebar-styles of docs and examples
closes#2641
* improve referencing to code editor for mobile readers
The current documentation mentions "to the right" which is not accurate for people reading the tutorial on narrow-viewport devices.
I changed it to "the code editor", but this may be improved upon to match other more common references.
* typo
Use verlet-style integration for spring animations. Rather than keeping track of "value" and velocity over time, keep track of value and previous-value, and derive velocity from the delta every tick. This has a few benefits, including greater stability (position and velocity can't drift) and simplifying signature of tick_spring (no need to pass velocity back up).
Pulling "settled" flag out of the return signature as well means return value is just "next value", simplifying code mapping over objects and arrays, and eliminating duplicated code across get_initial_velocity, get_threshold and tick_spring.
Refactored "threshold" calcs, extremely inexpensive to do inline in tick_spring rather than create a parallel structure. Also fixes a rare pathological case where springs will never settle (reading through the code, could happen if velocity was non-zero during a set() where target==current, threshold will be calculated to be zero and settled will always be set to false, leading to infinite animations).
Functional changes:
In my experience dealing with spring animations, there are a handful of edge-cases where it is nice to have library support. 99% of the time, the only times you'd want to fudge 'stiffness' and 'damping' is during a live interaction (e.g. dragging something around). By providing an idiomatic mechanism hopefully the code around dealing with that could be simpler.
I propose an additional "options" parameter to 'set()' and 'update()'.
If passed {hard:true} the set will be considered a "hard" set, where you want the value to be set to the target value immediately. This could be extremely useful when implementing dragging for instance.
If passed {soft:true} or {soft:<duration>}, the set will be considered a "soft" set, where momentum will be preserved for some duration before settling. This could be useful when implementing "throwing", e.g. after a drag, on mouseup, 'soft set' to some position and the user's previous momentum will be honored before settling down.
Technically momentum preservation happens to a degree now, but aggressive stiffness and/or damping values make it nearly unapparent. This handles the case where you may want more aggressive or heavily underdamped springs but without the apparent velocity discontinuity that happens on throw. (As a real example, in FaceTime, note behavior when tossing around the picture-in-picture, or the iPhone X gestural behavior when tossing apps back to the home screen).
Internally this is implemented by temporarily setting mass to infinity and ramping back to normal over some duration.
"Hard sets" are also special-cased to trigger a same-frame set and fulfilment, leading to more responsive dragging. Best case is a one frame improvement in drag latency (noticed in Safari). This also handles the "old way" method of munging 'stiffness' and 'damping' to 1, so the improvement applies to existing code.
*E.g.* is an English language idiom that can be said in a plainer way, easier for non-native speakers to understand.
Personal preference is to use plainer language when possible, but I wouldn't be offended if this were rejected.