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
Below are compression and expiration settings for Apache that I’ve found optimal for StepMania. You can paste them into your .htaccess file.
Don’t mess with PHP’s ob_gzhandler. The settings below enable compression at the Apache module level, are the cleanest way to handle compression of non-PHP types, and are better performing to boot.
If your PHP application has a option for compression (it’ll be using ob_gzhander), turn that off in favor of these settings.
Web-Sniffer is useful for testing whether your compression and cache-control settings are taking effect. It’s also useful for troubleshooting HTTP error responses that Firefox and Chrome hide with pretty error pages.
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
AddOutputFilterByType DEFLATE application/x-httpd-eruby
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType audio/x-wav "access plus 1 month"
ExpiresByType audio/mpeg "access plus 1 month"
ExpiresByType video/mpeg "access plus 1 month"
ExpiresByType video/mp4 "access plus 1 month"
ExpiresByType video/quicktime "access plus 1 month"
ExpiresByType video/x-ms-wmv "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType text/css "access plus 1 hour"