The contents of the selected area don’t need to be opaque
Doesn’t require divs several divs for each edge of the animation
The CSS property border-image will do the heavy-lifting for us. Border-image is a strange beast because the name makes it sounds like an alternative to border-style (e.g. solid, dashed, dotted), but it’s really a 9-slice technique that even can fill the padding and content area with an image.
We’ll start with a 10px x 10px animated gif that is composed of nine tiles: 1×1 in the corners, 1×8 or 8×1 on the edges, and 8×8 in the center. The center tile is transparent so that we can let the area behind out element show through.
Our CSS will set border-image and specify that the slice is 1px from the edge and that the image should repeat instead of being stretched.
This is a fantastic post on the blink-dev discussion list by Chrome dev James Robinson describing how setTimeout’s timer clamping works. James argues that setTimeout(fn, 0) behaves exactly as setImmediate(fn) would except in excessively-nested timers.
Nearly everything I’ve read starts off with an incorrect idea about how timer clamping works or why it’s in place. The way timer clamping works  is every task has an associated timer nesting level. If the task originates from a setTimeout() or setInterval() call, the nesting level is one greater than the nesting level of the task that invoked setTimeout() or the task of the most recent iteration of that setInterval(), otherwise it’s zero. The 4ms clamp only applies once the nesting level is 4 or higher. Timers set within the context of an event handler, animation callback, or a timer that isn’t deeply nested are not subject to the clamping. This detail hasn’t been reflected in the HTML spec until recently (and there’s an off-by-one error in it right now), but has been true in WebKit/Blink since 2006  and in Gecko since 2009 . The practical effect of this is that setTimeout(…, x) means exactly what you think it would even for x in [0, 4) so long as the nesting level isn’t too high.
With a better understanding of timer clamping, let’s consider the possible use cases for scheduling asynchronous work. One is to time work relative to display updates. Obviously requestAnimationFrame() is the right API to use for animations, but it’s also the right choice for one-off uses. To perform work immediately before the next display – for example to batch up graphical updates as data is streamed in off the network – just make a one-off requestAnimationFrame() call. To perform work immediately -after- a display, just call setTimeout() from inside the requestAnimationFrame() handler. The nesting level is zero within a rAF() callback so the timeout parameter will not be clamped to 4.
Thousands of people, including myself, criedout in terror when Google removed the “Side Tabs” from Chrome. I tried for one month to settle into Firefox + Firebug + Tree Style Tabs as my main browser, but that combination is nowhere near is snappy as Chrome for my workload.
My workaround has been to use the most recent build of Chromium (Chrome’s open-source alter ego) that still contained the Side Tabs feature. Because there are no security updates available for this version, I use NoScript and whitelist scripting on sites as needed.
I’ve made a video showing how Webkit handles animating of CSS3 transforms very differently from animating of CSS position (left, top) or margin. The are several different conditions that will trigger the browser to use a “composite layer” which minimizes repaints and allows for hardware-accelerated composting. The benefits are especially dramatic in iOS Safari.
Try the example and compare the behavior in your browser’s inspection tools