I just updated the documentation panes on http://VelocityJS.org to include real-time CodePen demos.

Beyond that, what else should be improved? Specifically, which panes contain unclear descriptions or simply lack sufficient detail?

I do not plan on hosting the documentation on GitHub at this time (it'll result in too many PR's and I only have so much time), so please respond with your change requests as a comment in this thread, and I will promptly consider each and every request.

Thank you so much in advance. One of my top priorities is great documentation, so this is very helpful to me :)

@nmussy developed a shim for the jQuery functions that Velocity depends on. I'm now focusing my attention on releasing this work. (I waited until all core Velocity features landed, which they now have.)

The shim works as follows:

• The shim is loaded as a separate JS file before jquery.velocity.js. Velocity automatically detects the shim then uses it for some of its internal functions -- so long as jQuery isn't also present on the page, in which case Velocity will always default to using jQuery proper.
• If the shim isn't loaded at all, jquery.velocity.js works exactly as it does now. No changes are being made to the core Velocity file. The shim's purpose is to simply act as a polyfill.
• If the shim is loaded, you inherently can no longer chain onto jQuery element objects, e.g. $("div").velocity() won't work since you don't have access to jQuery's selector engine nor its chaining capabilities. Accordingly, all shimmed Velocity animation takes place via Velocity's utility function: http://velocityjs.org/#utilityFunction. Note that, when jQuery is loaded on the page, the utility function is normally an extension of jQuery's $ object. However, when jQuery isn't loaded (meaning, the shim is being used), the utility function is attached directly onto the window object and is therefore accessed simply via Velocity.animate(element, propertiesMap, options); This is the new syntax for animating with the jQuery-free version of Velocity.
• If the shim has been loaded and Zepto (instead of jQuery) is loaded on the page, Velocity will attach itself to Zepto's $ and $.fn and will automatically work exactly like it already does with jQuery, e.g. $zeptoElement.velocity();. Without the shim, jquery.velocity.js currently does not work at all with Zepto.

Questions for you guys:

• Should the shim file be named velocity.jquery-shim.js, velocity.shim.js, or something else?
• Should the shim not be a separate file? Instead, should the shim code be baked into Velocity itself, and then should jquery.velocity.js be renamed to simply velocity.js? Note that the shim has a minified size of 4Kb and that minified Velocity is currently at 30Kb.
• An alternative to the above option is to have two versions of Velocity from here on out: velocity.js and jquery.velocity.js. One of them simply bakes in the shim code at the top. Accordingly, the shim itself would not be released as a separate file. (My concern with this option is that there starts to be a lot of download options for users, and I don't want to make them think twice about what file to use.)

Notes:

• There is no performance benefit to not using jQuery. jQuery was never a bottleneck for Velocity. Don't drop jQuery just because you want "increased speed."
• Dropping jQuery and using the shim will only work for IE9+. IE8, which is normally supported by jquery.velocity.js, will not be supported in the shimmed version.
• Since you'll inherently lose access to jQuery's delay() and queue() functions when not using jQuery, you'll want to replicate their behavior by leveraging Velocity's delay option as well as its begin/complete callbacks.

Any questions, concerns, or comments?

I wonder if https://github.com/tobia/Pause/blob/master/jquery.pause.js can be repurposed to wrap over $.velocity instead of $.animate to enable pausing/resuming velocity animations.

I'm considering adding support for SVG element animation. By default, neither jQuery, nor Transit, nor Velocity support this. Why? Because most CSS properties don't take effect on SVG elements; you have to tween their HTML attributes (e.g. width='100%') directly.

CSS properties that already work by default for SVG elements: opacity, 2D transforms (all browsers except Safari desktop and mobile)

What I'd be adding support for: transform (full browser support), x, y, width, height, cx, cy, r, rx, ry, x1, y1, x2, y2 -- basically, anything that's numerically tweenable.

How it would work: Before an element is animated, there would be a check for node instanceof SVGElement. When Velocity detects this flag, it'll apply all properties directly to the SVG element's attributes instead of its style tag.

So here's the question, who would use this? Better yet, is anyone dying for this to be implemented?

I only consider this a valid consideration for Velocity if it helps people avoid having to load additional SVG animation libraries; if you still need whatever your current SVG solution is even once Velocity has integrated this support, then it's not worth supporting at all.

Here is what I'm doing:

        $container
            .find('.pfentry__info')
            .velocity('stop')
            .velocity
                properties:
                    opacity: 1
                    scale: [1, 0.9]
                options:
                    display: 'block'
                    duration: 225

I have this in my CSS:

.pfentry__info {
 opacity: 0;
 transform: scale(0.9);
}

When Velocity is run, it scales with forcefeeding from 0.9 to 1, and then it drops scale(1), but keeps opacity: 1.

How do I fix it ? ( a tmp fix would be to remove the transform from CSS, but I'm thinking that this could be a Velocity bug ? )

SlideUp and SlideDown both apply the following styles as expected

display: none; overflow: visible; height: auto; margin-top: 0px; margin-bottom: 0px; padding-top: 0px; padding-bottom: 0px;

However Velocity does not remove these style tags from the elements upon completion. Tried it on multiple elements.

I am trying to set up a JSFiddle but I keep getting a console error of: Uncaught Error: Velocity: Either jQuery or Velocity's jQuery shim must first be loaded.

Will happily throw up an example if somebody wouldn't mind telling me how exactly I do that with JSFiddle (never used it before).

Stage 1

• [ ] Use original source and add/update build system
• [ ] Convert source over to Typescript.
• [ ] Automated tests: especially useful for Pull Requests (Jasmine?, Mocha?)
• [ ] API Documentation within code (TypeDoc? GitBook?)

Stage 2

• [ ] Fix / close all valid open issues
• [ ] Merge / add / close all open Pull Requests

Note

This is an open issue so people can discuss and put their own views in for getting things moving again - not for bug reports and feature requests which should be opened as separate issues - if you want to refer to an already open issue then feel free, but we do want to try to get them all closed / resolved as soon as possible anyway.

• Typescript is described as "Javascript with types" - the code is pretty much identical but has type annotations added, so var test = "abc"; test = 123; doesn't give a warning in Javascript, but would in Typescript as you're trying to change the type of it (nice at preventing errors) - you could also use var test: string; test = "abc"; test = 123; to get the same warning.

I just noticed this on an iPhone 5S - velocity animations triggered by a touch event don't execute until after the touch has ended. I'm guessing this is somehow due to the requestAnimationFrame implementation in Safari for iOS, it seems like it doesn't invoke the functions queued up until all touches have ended. jQuery animations behave the same way in this situation, possibly setTimeout/Interval also suffer from the same feature. So, not really a velocity bug, but I'm just wondering if you had noticed this and might have any thoughts about how to address it? I'm thinking it's best to just use CSS transitions triggered by class changes in this scenario..

jsDelivr has some phenomenal features where you can generate one single js file from multiple ones and in that way reduce the number of requests needed.

It would be great if you would consider adding velocity to their list of repos.

Thanks for something awesome <3

I've been experimenting quite a bit with Velocity.js but i haven't yet been able to run Velocity at reasonable speeds on mobile with more real animations and a bit more complex objects.

My latest pen on codePen just runs "ok" on desktop (win7+chrome) but on mobile it runs horribly. I've checked the paint times etc and it seems to be ok. Is there anything one can do to increase the perf on mobile? The in-built mobileHA doesn't seem to make much of a difference.

I know about what CSS properties to animate and not for best performance but that doesn't seem to help. I usually only animate translate + opacity and stay away from shadows, borders, top, width, height etc (anything that causes repaints).

The hope is to create something that doesn't require misc fallbacks for mobile devices or extraneous code in order to cover more platforms of different kinds. Sort of like thinking responsive design but for transitional UI/UX as well. It would suck to drop Velocity and only use CSS3 animations since the Velocity API and implementations is great for separating animation from presentation.

I'm trying to use velocity using browserify in the simplest case (without externally loading velocity and using browserify shim), and I get the error

Velocity: Either jQuery or Velocity's jQuery shim must first be loaded.

It looks like the code won't execute require("jquery") unless window.Velocity is defined, which doesn't make sense:

https://github.com/julianshapiro/velocity/blob/master/jquery.velocity.js#L42

I suspect the point of that conditional is to allow you to use Velocity's jQuery shim instead of jQuery. If that is the case, shouldn't it be:

factory(window.Velocity ? undefined : require("jquery"));

That seems to be consistent with the AMD implementation as well as the downstream code. It also gets rid of the error for me.

Hey, I am new to velocity and I would like to learn how you made the 3d effect.

It's mentioned that the must-see video is at https://www.youtube.com/watch?v=MDLiVB6g2NY, but unfortunately, the video is private. Any chance to make it public again? Or is there another resource where this example is explained?

Your system information

• VelocityJS version: 2.0.6
• Browser: Edge
• Operating System: Windows

Checklist

• Is this an issue with code?: Kind of
• Is this an issue with documentation?: No
• Have you reproduced this in other browsers?: Yes
• Have you checked for updates?: Yes
• Have you checked for similar open issues?: Yes

Please remember that this is an issue tracker, support requests should be posted on StackOverflow - see CONTRIBUTING.md

Please describe your issue in as much detail as possible:

I need to use the "non jQuery" version eg the standard JS function: Velocity() however if jQuery happens to be used on the same page velocity seems to prioritise the jQuery version and no longer attaches "Velocity" to the window object.

Is there something I can modify in the code manually to force velocity to attach it to the main object, or is there another way I can achieve this?

Finally, this may seem like a strange question because "why not just use the jquery version?", but in my use case I am including Velocity within a separate class, and my class does not require jQuery, so I am using the window Velocity function istead.. in other words I don't want my class to break just because jquery happens to be included on the page. If that makes sense.

Your system information

• VelocityJS version: 2.0.6
• Browser: chrome
• Operating System: ios

Checklist

• Is this an issue with code?: [Yes]
• Is this an issue with documentation?: [Yes]
• Have you checked for updates?: [Yes]
• Have you checked for similar open issues?: [Yes]

Please describe your issue in as much detail as possible:

1. Is there any code that can achieve specialEasing like jQuery animate?
2. How to use relative position in v2.0.6? When I use '+=', it does not work properly.

thanks

I'm trying to achieve something like this where the div expands from the center to left and right: http://jsfiddle.net/SNzgs/1/.

I am currently using velocity(el, { scale: [1, 0], opacity: [ 1, "easeInSine", 0 ]}, { duration: 800, }) but it doesn't give me the desired effect.

Your system information

• VelocityJS version: 2
• Browser: chrome
• Operating System: windows 8

Checklist

• Is this an issue with code?: [Yes/No]
• Is this an issue with documentation?: [Yes/No]
• Have you reproduced this in other browsers?: [Yes/No]
• Have you checked for updates?: [Yes/No]
• Have you checked for similar open issues?: [Yes/No]

Please remember that this is an issue tracker, support requests should be posted on StackOverflow - see CONTRIBUTING.md

Please describe your issue in as much detail as possible:

Describe what you expected should happen and what did happen. animating the scrollTop using scrollTop property only work if the scrollTop position is at 0px. So if the scrollTop position have changed from 0, it can only animate back to 0. Aside from that it wont work. Example: // html scrollTop position is at 0px $("html").velocity({scrollTop: 500}, {duration: 2000}) // it will work // html scrollTop position is at 500px $("html").velocity({scrollTop: 700}, {duration: 2000}) // it wont work //html scrollTop position is at 500px $("html").velocity({scrollTop: 0}, {duration: 2000}) // it will work

Steps for reproducing this issue (code):

JSFiddle example showing issue in action (code):

Go to https://jsfiddle.net/Rycochet/mqv9L27u/ - click the "Fork" button at the top, create the example and copy the new URL back here.

So this has been paused for quite a while, the reason basically came down to not having the time / spoons for writing Unit Tests to be able to do a proper release for v2...

Now almost two years later I've been actively coding Velocity again for a couple of weeks, and all I can say is... I've started a lot again!

Things have changed a lot in the past two years - there were things I wanted to do with the code before that were so bad for performance they couldn't be justified, but that's all changed, and now a lot of these things that could improve the interface for Velocity are now first-class citizens in the JS world of browsers - so I'm in the process of splitting Velocity up even more than before and making it significantly more powerful!

In a rough end-user explanation, the API for animations will remain the same as V2, which itself was very similar to V1 in most ways (only properties such as scrolling were complete changes).

Things that are changing are pretty much all behind the hood:

• Far more abstracted design, which means we can do more Unit Tests to make sure things are safe and working correctly
• Splitting almost everything apart - there's going to be more packages published (with the old velocity-animate being retired) - We've got a new namespaced project @velocityjs - so it's easier to use what you want - there will be a @velocityjs/animate which will effectively be the same as the old one for direct script use in browsers though (and will include everything from all other core parts of Velocity - though likely not specific modules such as React / Ember / Angular etc)
• All modules for Velocity will be using the same public API that anyone can use, so there's (almost) nothing they can do that someone else can't hook into to extend!
• The core part of Velocity no longer knows or cares what it is animating... All the browser support is being put into @velocityjs/dom, which might not seem like much - but it means that adding support for animating anything else becomes a lot simpler. What else might you animate? How about an Object that's being used to generate some WebGL display - and you can write your own custom functions for getting / setting any properties!

A lot of these things are still being designed in terms of the best ways to do them, and I encourage anyone who wants to see what's happening have a look at the V3 branch - though be aware that a lot more is likely to break before it works again (the changes are too extensive to keep things working in the interim, but hopefully it won't take long to get back there again).

I also want to write a performance / stress testing module that can compare all current animation libraries with each other - and give a good idea on what needs to be improved - so any ideas and support would be awesome!

Internally we're now using Lerna for monorepo support, TSDX for package building, and will be using Jest for unit testing, and Storybook for showing off individual components that can be (as that also lets us include example code that can be played with). As with V2 this is 100% in Typescript, but the "everything" package of @velocityjs/animate will be compiled with Webpack and Babel for older browser compatibility.

NOTE: The current V2 state is now being saved under the V2 branch - it never quite reached release due to the lack of testing, but still works very well for a lot of people.