Léonie Watson with a much-needed reference on how to do a good job with SVG accessibility. A couple of takeaways: 1) Use it, the sharp clarity of SVG is good for low vision folks. 2) Inline SVG offers better accessibility 3) Use <title> and <desc>. Plus several more you should definitely read about.
Direct Link to Article — Permalink
Tips for Creating Accessible SVG is a post from CSS-Tricks
Super group hug and jumping high fives for everyone. I was honored to accept the Outstanding Contribution award for The Net Awards this year. The entire internet got to vote in the first round, then a select group of peers voted in the second round, so that's makes it a double-special thing to win.
I sadly couldn't make the ceremony, but I saw lots of pictures and heard nothing but great things. I sent them this acceptance video to play in my absence:
And to literally double the honor, Dave Rupert and I also won Podcast of the Year. Dave wasn't able to attend either, so we made this Thank You page and sent in this acceptance video:
Winner Winner is a post from CSS-Tricks
oEmbed is a neat little technology that allows for rich content to be embedded into other content very easily. You paste a link to the "thing" and, when published, that link magically transforms into something much more useful than a link. A quintessential example is a link to a YouTube video. Just drop the URL to a video in a blog post, and it will transform into an embedded version of that video. Flickr URL... turns into an embedded photo.
CodePen supports oEmbed as well, which means you can put Embedded Pens in some interesting places right now, and enabling your site to allow them is pretty easy as well.
I mention this here, because it works great right here on CSS-Tricks!
We encourage you to post Pens of issues in the forums anyway, because that's 100 times easier to play with and diagnose than trying to just look at code and imagine it.
Right here in the blog, works the exact same way.
Of course, it's easy. But there is more than that. With oEmbed, you are whitelisting places you allow embedded rich content from. It's a trust thing.
CodePen embeds require JavaScript to work. That sounds anti-progressive-enhancement, but it's actually the opposite. By requiring JavaScript, we can take a perfectly good bit of content (a sentence explaining the title, author, and info about a Pen) and transform it into an <iframe> embed experience. So without JavaScript, the content still "works" and makes sense. With JavaScript, it's better. An <iframe> alone would just break in a no-JS environment (for us).
So, because we need need that <script> for our embeds to work, that limits where they can be used. Most sites don't allow you to just to execute whatever <script> you put on them. That would be highly irresponsible and a major security flaw (XSS). With oEmbed, you can allow that <script> through only for trusted sources. Pretty cool way to handle it, I think.
oEmbed works by:
You can see more about the CodePen oEmbed API here, including our API endpoint and what we return.
It's basically one line of code to enabled it on a self-hosted WordPress site, but you might as well make use a plugin because that's what they are for. Then to make it work in comments (and bbPress), there is another plugin.
Iframely supports CodePen, and 900+ other domains embedded content, so that's an option too.
If you use Jetpack, support is coming soon to that.
But remember, if you are just embedding Pens into blog posts and stuff you don't need oEmbed at all. You can use our embed code, which means you can adjust heights and change themes and stuff, which is more powerful.
Discourse, as in the excellent forum software.
Thanks to Joey Kudish and the WordPress.com for getting Embedded Pens working there!
Lemme know if you end up using it in a cool way.
A major reason we started building CodePen at all was because showing snippets of code alone pales in comparison to seeing that code actually running, and this makes it easier to bring those running bits of code to the same types of places that used to be limited to snippets.
oEmbed Bring Embedded Pens All Over is a post from CSS-Tricks
The following is a guest post by Pankaj Parashar. Pankaj has written here before, last time about the progress element. I'm happy to have Pankaj back, this time to tackle the idea of showing reading progress (or really, a scroll position indicator) on websites, which has been a mini-trend lately.
Lately I've seen quite a few websites that have some kind of an indicator to display the current reading position (how much you have "read", depending on how far you have scrolled down an article). Generally, such indicators are used on blog posts or long form articles and help readers understand how far they are from finishing the article.
Here are some examples:
Interestingly, all three techniques represent the same information but with a different approach. I don't know if there is a name for this feature - so throughout the article, I call it a Reading Position Indicator.
In this article, we'll focus on the first technique that uses a horizontal progress bar as the indicator. But instead of using traditional div/span(s) and some non-linear math to build the indicator, we will use the HTML5 progress element. In my opinion <progress> is much more semantically accurate and suitable to represent this information, and that too with no complex calculations involved.
To build a reading position indicator, we need to answer two important questions:
This leaves us with no choice but to tackle this problem statement with a completely different approach.
The principle behind this technique is based on a simple fact that the user needs to scroll to reach the end of the web page. Once the user reaches the end of the web page we can conclude that he/she has finished reading the article. Our technique revolves around the scroll event which is likely to be the key to determine an approximate position of the user while reading.
Assuming the user starts reading from the top and will only scroll once he/she reaches the end of the viewport, we'll attempt to answer the following questions:
max attribute.value attribute.
In the context of the browser, document and window are two different objects. window is the viewable area of the browser (thick blue box in the above example) and document is actually the page that loads inside the window (thin grey box currently scrolling).
Let's start with a basic markup:
<progress value="0"></progress>It's important to explicitly specify the value attribute. Otherwise, our progress bar will be in the indeterminate state. We don't want to add unnecessary styles in CSS for the indeterminate state. Thus we choose to ignore this state by specifying the value attribute. Initially, the user starts reading from the top, hence, the starting value set in the markup is 0. The default value of the max attribute (if unspecified) is 1.
To determine the correct value for the max attribute, we need to subtract the window's height from the height of the document. This can only be done via JavaScript, so we will worry about it at a later stage.
The placement of the markup in the HTML document would heavily depend on the how rest of the elements are placed. Typically, if you have no fixed position containers in your document, then you can place the progress element right on top of all the elements inside the <body> tag.
<body>
<progress value="0"></progress>
<!--------------------------------
Place the rest of your markup here
--------------------------------->
</body>Since, we want our indicator to always sit on top of the web page, even when the user scrolls, we'll position the progress element as fixed. Additionally, we would want the background of our indicator to be transparent so that an empty progress bar doesn't create a visual hinderance while scrolling through the web page. At the same time this will also help us tackle browsers with JavaScript disabled that we'll cover later.
progress {
/* Positioning */
position: fixed;
left: 0;
top: 0;
/* Dimensions */
width: 100%;
height: 5px;
/* Reset the appearance */
-webkit-appearance: none;
-moz-appearance: none;
appearance: none;
/* Get rid of the default border in Firefox/Opera. */
border: none;
/* Progress bar container for Firefox/IE10+ */
background-color: transparent;
/* Progress bar value for IE10+ */
color: red;
}For Blink/Webkit/Firefox, we need to use vendor specific pseudo elements to style the value inside the progress bar. This will be used to add color to our indicator.
progress::-webkit-progress-bar {
background-color: transparent;
}
progress::-webkit-progress-value {
background-color: red;
}
progress::-moz-progress-bar {
background-color: red;
}Calculating the width/height of window and document in JavaScript is messy and varies horribly across different breed of browsers. Thankfully, jQuery manages to abstract all the complexities offered by these browsers and provides a much cleaner mechanism to calculate the dimensions of window and document. Hence, for the rest of the article we'll rely on jQuery to handle all our interactions with the user.
Before, we begin, do not forget to add jQuery library to your document.
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js"></script>We need jQuery to determine the max and the value attribute of our progress element.
max value is the portion of the document that lies outside the viewport which can be calculated by subtracting the window's height from the height of the document.var winHeight = $(window).height(),
docHeight = $(document).height();
max = docHeight - winHeight;
$(progress).attr('max', max);value will be zero (already defined in the markup). However, as soon as the user starts scrolling, the vertical offset of the top of the document from the top of the window will increase. If the scrollbar is at the very top, or if the element is not scrollable, the offset will be 0.var value = $(window).scrollTop();
$(progress).attr('value', value);document in $(document).height(), we can use other elements like section, article or div that holds the content of the article to calculate the height and present the user with a much more accurate representation of the reading position indicator. This becomes quite useful, when you have a blog post that is filled with comments and constitutes more than 50% of the actual article.Now, everytime the user scrolls, we need to re-calculate the y-offset from the top of the window and then set it to the value attribute of the progress element. Note that the max attribute remains the same and doesn't change when the user scrolls.
$(document).on('scroll', function() {
value = $(window).scrollTop();
progressBar.attr('value', value);
});The direction in which the user is scrolling is not important, because we always calculate the y-offset from the top of the window.
It's important that our code executes only then the DOM is loaded, otherwise, premature calculation of window/document's height could lead to weird and unpredictable results.
$(document).on('ready', function() {
var winHeight = $(window).height(),
docHeight = $(document).height(),
progressBar = $('progress'),
max, value;
/* Set the max scrollable area */
max = docHeight - winHeight;
progressBar.attr('max', max);
$(document).on('scroll', function(){
value = $(window).scrollTop();
progressBar.attr('value', value);
});
});(Or ensure this code is loaded at the bottom of the page instead of the top, and skip the document ready call.)
This is all what we need to build a functional reading position indicator that works equally well in all the browsers that support the HTML5 progress element. However, the support is limited to Firefox 16+, Opera 11+, Chrome, Safari 6+. IE10+ partially supports them. Opera 11 and 12 doesn't permit changing the progress bar color. Hence, our indicator reflects the default green color.
There are quite a few variations possible in which we can style the indicator. Especially, the semantic color scheme (fourth variation) is a useful experiment, wherein the indicator changes color based on the proximity of the reading position from the end of the article.
See the Pen Reading Position Indicator by Pankaj Parashar (@pankajparashar) on CodePen.
There are few scenarios, where our code can potentially break or present the user with an incorrect indicator. Let's look at those edge cases:
So far, our code assumes that the height of the document is greater than the window's height, which may not be the case always. Fortunately, browsers handle this situation very well by returning the height of the window, when the document is visibly shorter than the window. Hence, docHeight and winHeight are the same.
max = docHeight - winHeight; // equal to zero.This is as good as a progress element with both max and value attribute as zero.
<progress max="0" value="0"></progress>Hence, our progress bar would remain empty and since our background is transparent, there will be no indicator on the page. This makes sense because, when the entire page can fit within the viewport there is really no need for an indicator.
Moreover, the scroll event won't fire at all because the height of the document doesn't exceed the window height. Hence, without making any modification, our code is robust enough to handle this edge case.
When the user resizes the window, the height of the window and the document will change. This means that we will have to recalculate the max and the value attribute to reflect the correct position of the indicator. We'll bind the code that calculates the correct position to the resize event handler.
$(window).on('resize', function() {
winHeight = $(window).height(),
docHeight = $(document).height();
max = docHeight - winHeight;
progressBar.attr('max', max);
value = $(window).scrollTop();
progressBar.attr('value', value);
});When JavaScript is disabled our progress bar would have the default value as 0 and max as 1.
<progress max="1" value="0"></progress>This would mean that the progress bar would remain empty and wouldn't affect any part the page. This is as good, as a page with no indicator isn't a big loss to the reader.
Older browsers that do not support the HTML5 progress element will simply ignore the progress tag. However, for some devs providing a consistent experience is important. Hence, in the following section, we'll employ the same fallback technique that was used in my previous article to implement the reading position indicator for oler browsers.
Markup - The idea is to simulate the look and feel of the progress element with div/span(s). Modern browsers will render the progress element and ignore the markup inside it, whereas older browsers that cannot understand the progress element will ignore it and instead render the markup inside it.
<progress value="0">
<div class="progress-container">
<span class="progress-bar"></span>
</div>
</progress>Styling - The container will always span across the width of the webpage and the background will stay transparent to handle other edge cases.
.progress-container {
width: 100%;
background-color: transparent;
position: fixed;
top: 0;
left: 0;
height: 5px;
display: block;
}
.progress-bar {
background-color: red;
width: 0%;
display: block;
height: inherit;
}Interaction - First we need to separate browsers that do not support the progress element from the browsers that support them. This can be achieved either with native JavaScript or you can use Modernizr to test the feature.
if ('max' in document.createElement('progress')) {
// Progress element is supported
} else {
// Doesn't support the progress element. Put your fallback code here.
}The inputs still remain the same. But, in addition to determining the value, we need to calculate the width of the .progress-bar in percentage.
winHeight = $(window).height();
docHeight = $(document).height();
max = docHeight - winHeight;
value = $(window).scrollTop();
width = (value/max) * 100;
width = width + '%';
$('.progress-bar').css({'width': width});After exploring all the edge cases, we can refactor the code to remove any duplicate statements and make it more DRY-er.
$(document).ready(function() {
var getMax = function(){
return $(document).height() - $(window).height();
}
var getValue = function(){
return $(window).scrollTop();
}
if ('max' in document.createElement('progress')) {
// Browser supports progress element
var progressBar = $('progress');
// Set the Max attr for the first time
progressBar.attr({ max: getMax() });
$(document).on('scroll', function(){
// On scroll only Value attr needs to be calculated
progressBar.attr({ value: getValue() });
});
$(window).resize(function(){
// On resize, both Max/Value attr needs to be calculated
progressBar.attr({ max: getMax(), value: getValue() });
});
} else {
var progressBar = $('.progress-bar'),
max = getMax(),
value, width;
var getWidth = function() {
// Calculate width in percentage
value = getValue();
width = (value/max) * 100;
width = width + '%';
return width;
}
var setWidth = function(){
progressBar.css({ width: getWidth() });
}
$(document).on('scroll', setWidth);
$(window).on('resize', function(){
// Need to reset the Max attr
max = getMax();
setWidth();
});
}
});Generally, it is considered a bad practice to attach handlers to the scroll event because the browser attempts to repaint the content that appears every time you scroll. In our case, the DOM structure and the styles applied to them are simple, hence, we wouldn't observe any lag or noticeable delay while scrolling. However, when we magnify the scale at which this feature can be implemented on websites that employs complex DOM structure with intricate styles, the scroll experience can become janky and the performance may go for a toss.
If scrolling performance is really becoming a big overhead for you to overcome, then you can either choose to get rid of this feature completely or attempt to optimize your code to avoid unnecessary repaints. Couple of useful articles to get you started:
I am no UX expert, but in some cases, the position and appearance of our indicator can be ambiguous and potentially confuse the user. Ajax-driven websites like Medium, Youtube etc., use similar kind of a progress bar to indicate the load status of the next page. Chrome for mobile natively uses a blue color progress bar for the webpage loader. Now, if you add the reading position indicator to this frame, I am sure that an average user will have a hard time understanding what the progress bar at the top of the page really means.
You'll have to make the call for yourself if this is of benefit to use your users or not.
div/span(s) technique making the entire code bloat.Reading Position Indicator is a post from CSS-Tricks
It's pretty common to use SVG within an anchor link or otherwise "click/tappable thing" on a web page. It's also increasingly common that the SVG is inline <svg>, because it's often nice having the SVG in the DOM since you can style it with CSS and script it with JS and such. But what does that mean for click events?
A link with an SVG icon in it might be like this:
<a href="#0" data-data="something">
<svg ... >
<rect ...>
<svg>
</a>Now you want to bind a click event to that anchor link. In jQuery:
$("a").on("click", function(event) {
// `this` will always be the <a>
console.log($(this).data("data"));
// "something"
});That will work perfectly fine. Note there is a data-* attribute on the anchor link. That's probably there specifically for JavaScript to access and use. No problem at all how we have it written right now, because within the anonymous function we have bound, this will always be that anchor link, which has that attribute available. Even if you use event delegation and call some function who-knows-where to handle it, this will be that anchor link and you can easily snag that data-* attribute.
But let's say you're going to rock some raw JavaScript event delegation:
document.addEventListener('click', doThing);
function doThing(event) {
// test for an element match here
}You don't have an easy reference to your anchor link there. You'll need to test the event.target to see if it even is the anchor link. But in the case of our SVG-in-a-link, what is that target?
It could either be:
<a><svg><rect>You might just have to check the tagName of the element that was clicked, and if you know it was a sub-element, move up the chain:
document.addEventListener('click', doThing);
function doThing(event) {
var el;
// we can check the tag type, and if it's not the <a>, move up.
if (event.target.tagType == "rect") {
// move up TWICE
el = event.target.parentElement.parentElement;
} else if (event.target.tagType == "svg") {
// move up ONCE
el = event.target.parentElement;
} else {
el = event.target;
}
console.log(el.getAttribute("data-data"));
}That's pretty nuts though. It's too tied to the HTML and SVG structure. Toss a <g> in there around some <path>s, which is a perfectly fine thing to do for grouping, and it breaks. Or the tagType is path not a rect, or any other DOM difference.
Personally I've been preferring some CSS solutions.
One way is to lay a pseudo element over top the entire anchor element, so that the clicks are guaranteed to be on the anchor element itself, nothing inside it:
a {
position: relative;
}
a::after {
content: "";
top: 0;
left: 0;
width: 100%;
height: 100%;
}This seems to work pretty well too:
a > svg {
pointer-events: none;
}pointer-events typically doesn't work in IE (it does in 11+, but not lower), but it actually does when applied to SVG, in IE 9+, which is the version of IE that supports SVG anyway.
Here's a Pen with the issue demonstrated and the fixes:
See the Pen owyFj by Chris Coyier (@chriscoyier) on CodePen.
If you're using SVG in a click target, be very careful you're getting the right element in JavaScript, and if you have trouble, consider a CSS cover.
Links with Inline SVG, Staying on Target with Events is a post from CSS-Tricks
Too many great quotes in this essay by Peter Welch . I'll just pick this one:
Right now someone who works for Facebook is getting tens of thousands of error messages and frantically trying to find the problem before the whole charade collapses. There's a team at a Google office that hasn't slept in three days. Somewhere there's a database programmer surrounded by empty Mountain Dew bottles whose husband thinks she's dead. And if these people stop, the world burns. Most people don't even know what sysadmins do, but trust me, if they all took a lunch break at the same time they wouldn't make it to the deli before you ran out of bullets protecting your canned goods from roving bands of mutants.
Over-the-top hilariously negative, but you can feel the love through it.
Direct Link to Article — Permalink
Programming Sucks is a post from CSS-Tricks
The following is a guest post by Julian Shapiro. Julian recently released Velocity.js, a more performant jQuery replacement for .animate(). He recently wrote about how JavaScript animations can be so fast over on David Walsh's blog, a topic we've covered here as well. In this article, Julian introduces Velocity.js itself.
Velocity.js is a jQuery plugin that re-implements jQuery's $.animate() function to produce significantly higher performance (making Velocity also faster than CSS transitions in many cases) while including several new features to improve animation workflow.
In 7Kb (zipped), Velocity includes all of $.animate()'s features while also packing in transform animation, looping, class animation, and scrolling. In short, Velocity is designed to be the best of jQuery, jQuery UI, and CSS transitions.
Velocity works everywhere — back to IE8 and Android 2.3. Further, since Velocity's syntax is identical to $.animate()'s, none of your page's code needs to change.
The goal of Velocity is to be a leader in DOM animation performance and convenience. This article focuses on the latter. To learn more about the former, refer to Velocity's performance comparisons over at VelocityJS.org. In particular, this article demonstrates how to use Velocity to improve your UI animation workflow. In a concise showdown, eight of Velocity's features are compared against their jQuery counterparts.
If you feel that your current UI workflow is messy, poorly segregated, or too reliant upon jQuery’s broad array of style functions, then this walkthrough is for you.
Before we dive into Velocity, let's quickly cover the bases: It should be pointed out that both $.animate() and $.velocity() support a malleable options syntax. You can either pass in options as comma-separated values, or you can pass in a standalone options object.
Here's an example of the comma-separated syntax, in which an integer is treated as the animation's duration, a string is treated as the easing type, and a function is treated as a callback (which is triggered upon the animation's completion):
$div.animate(
{
opacity: 1
},
1000,
"linear",
function() {
alert("Done animating.");
}
);Next, here's an example of the object syntax:
$div.animate(
{
opacity: 1
},
{
duration: 1000,
easing: "linear",
complete: function() {
alert("Done animating!")
},
queue: "myQueue"
}
);Beyond producing cleaner-looking code, using the options object provides access to additional animation parameters that are otherwise not able to be specified via the comma-separated syntax.
An example of one such option provided by jQuery is "queue". Velocity also provides the queue option, and multiple animation calls chained onto a single element automatically queue onto one another.
Here, a div's opacity will be animated to 1 for 1000ms then back down to 0 for the next 1000ms:
$div
.animate({ opacity: 1 }, 1000)
.animate({ opacity: 0 }, 1000);Now, with the bases out of the way, let's start comparing Velocity to jQuery.
In place of a properties map, Velocity also accepts "reverse" as its first parameter. Reverse animates the target element toward its values prior to its previous Velocity call.
In jQuery, that would be like:
$div
/* Fade an element in while sliding it into view. */
.animate({ opacity: 1, top: "50%" })
/* The values below are what we originally set the element to in our stylesheet. Animate back to them. */
.animate({ opacity: 0, top: "-25%" });In Velocity, it's easier as it is not only less code, but you don't have to repeat values from your stylesheet:
$div
.velocity({ opacity: 1, top: "50%" })
.velocity("reverse");By default, Velocity's reverse command uses the same options that were passed into the previous Velocity call. These options can be extended by passing new options into the "reverse" call. For example:
$div
.velocity({ opacity: 1, top: "50%" }, 1000)
/* Animate back to the prior visual state at half the duration of the previous animation. */
.velocity("reverse", 500);A popular UI technique is to scroll the browser so that it's aligned with an element further down the page, then to animate that element with attention-grabbing flourishes. Pulling this off with jQuery involves messy, non-performant code:
In jQuery, animating the scrollTop property requires you to target both the html element and the body element in order for the animation to work in older versions of Internet Explorer.
$("html, body").animate(
{
scrollTop: $div.offset().top
},
1000,
function() {
/* We use a callback to fade in the div once the browser has completed scrolling. */
$div.animate({ opacity: 1 });
}
);In Velocity, you target the element you want to scroll to:
$div
.velocity("scroll", 1000)
.velocity({ opacity: 1 });Just as with Velocity's "reverse" command, "scroll" can be passed in as Velocity's first parameter in place of a properties map. Also like the reverse command, the scroll command accepts animation options and can be chained onto other calls.
The scroll command's behavior is straightforward: Scroll the browser to the top of the element targeted by the Velocity call.
Oftentimes, an element's animation needs to be looped. Examples include shaking a dialog box to indicate invalid user input or bouncing a notification icon to grab the user's attention.
In jQuery, looping an animation entails messing your animation logic by breaking part of it out into a for statement:
for (var i = 0; i < 5; i++) {
$div
/* Slide the element up by 100px. */
.animate({ top: -100 })
/* Then animate back to the original value. */
.animate({ top: 0 });
}In Velocity, simply set the loop option to an integer equal to the desired number of loop cycles. A single loop cycle consists of animating toward the values in the property map followed by reversing back to the original values.
$div.velocity(
{ top: -100 },
{ loop: 5 }
);You'll often find yourself fading in an element whose display property was initially set to none, so that the element wasn't immediately visible upon page load. Subsequently fading in these elements requires several lines of jQuery:
$div
/* Use jQuery's $.show() function to make the element visible by switching its display property to "block"/"inline" as appropriate. */
.show()
/* Set the element's starting opacity to 0 so that it can be gradually faded in by the subsequent animation call. */
.css("opacity", 0)
/* Fade in and slide into view. */
.animate({
opacity: 1,
top: "50%"
});In Velocity, you simply pass in display as an option. The display option accepts the same set of values that its CSS property counterpart does (e.g. "block", "inline", and "none").
$div.velocity(
{
opacity: 1,
top: "50%"
},
{
display: "block"
}
);When the display option is set to a value other than none, the element's display property is set to the provided value at the start of the animation. Conversely, when display is passed a value of none, the display property is set upon the animation's completion.
$div
/* Fade out and slide out of view. */
.animate({ opacity: 0, top: "-50%" })
/* Then set the display property to "none" via a queued $.fadeOut() call. */
.fadeOut(1);$div.velocity(
{
opacity: 0,
top: "-50%"
},
{
display: "none"
}
);Further, if an element's opacity is being animated to a non-zero value while its display option is being set to a value other than none, Velocity conveniently defaults opacity's start value to 0.
Velocity accepts a delay option that replaces having to sprinkle $.delay() calls throughout your animation code:
$div
.delay(1000)
.animate({
opacity: 1
});$div.velocity(
{
opacity: 1
},
{
delay: 1000
}
);Beyond consolidating animation logic into a single call, using Velocity's built-in delay option allows Velocity to optimize chained animations by caching values between them.
To avoid declaring CSS styles alongside JavaScript code, which is considered poor practice due to its resulting code maintainability complications, it is often recommended to separate out your animation styles into CSS classes then to trigger them using JavaScript.
Note that to perform class animation in jQuery, you must also have jQuery UI loaded. jQuery UI adds 62KB to your page once zipped. Conversely, class animation is already built into Velocity.
.animate_slideIn {
opacity: 1;
top: 50%;
}$div.addClass("animate_slideIn", 1000);$div.velocity("slideIn", 1000);To animate a class in Velocity, simply pass in its name as Velocity's first parameter. Note that Velocity requires you to prefix your animation classes with animate_, but that you do not include this prefix in the Velocity call.
Also note that - in order to significantly increase performance - Velocity does not actually apply the class to the target element; the class is merely used as a property map container.
Forcing hardware acceleration (HA) on an element is an easy to way to dramatically increase animation performance on mobile devices. Enabling HA is traditionally achieved by setting an element's transform property to translateZ(0).
$div
.css("transform", "translateZ(0)")
.animate({ opacity: 1 })
.css("transform", "none");In Velocity, HA is automatically applied on mobile devices (there's no performance boost to be gained on the desktop). Velocity's control over HA is highly optimized.
$div.velocity({ opacity: 1 });The purpose of this walkthrough has been to demonstrate Velocity's consolidation of animation logic within your code. In short, Velocity is an expressive and efficient tool for crafting UI animations.
While jQuery is tremendously powerful, it was never jQuery's design goal to function as an optimized animation engine, and it suffers accordingly from less-than-ideal performance and workflows. At just 7Kb zipped, Velocity packs in enough features and speed gains for you to consider making it your animation engine of choice.
To explore the remainder of Velocity's features, including color and transform animation, check out Velocity's documentation at VelocityJS.org.
Before we conclude, here are some extreme examples of web animation that are made possible through the expressiveness and speed of Velocity:
Improving UI Animation Workflow with Velocity.js is a post from CSS-Tricks