I’m going to try and address some of the questions and comments that popped up overnight.
First, the ALA submit button—as Jeffrey mentioned, we’re on it. I think we’ve got a fix worked out, stay tuned.
@Jens Meirt, @Florian Schmitt, and anyone else wondering why this might be needed - let’s keep in mind that modern operating systems have been adding more and more simple UI animation effects for ages. Think of the way a hidden Apple dock will slide in, or the way way ExposÃ© quickly moves and scales windows, or window minimization effects, and so on. These are little UI details that may not strictly be necessary, but the transitions aid a user’s ability to keep track of what happens one minute to the next when the screen quickly changes, where a non-animated immediate transition could be quite confusing. Can we lump animated navigation hovers into the same category? That’s probably a subjective decision. I’d argue that if we’re going to bother defining :hover states at all, it’s nice to have the option to do something more than a binary on/off transition. Hence, this article.
@Marco van Hylckama Vlieg, and anyone else noticing the glitchy third example in the article - yeah, this one certainly wasn’t perfect. I acknowledged later in the article that jQuery’s animate function causes a bit of randomness in that example (see “Other Considerations” heading). I’m now wondering if it might be possible to hide the overlap with a bit of overflow:hidden magic; didn’t think of it at the time, but it might be worth digging in a bit more.
@Jason W, @Rowan W, and anyone else concerned about the opacity: 0.9999 addition - the problem with that NOT being there is that on hover, most browsers will cause the rest of the text in the page to flash in between anti-aliased and sub-pixel anti-aliased text during the animation. I’m pretty sure this is a browser bug, and if I understand the nature of it, it’s not an easy one to solve. The fix is sort of a lesser of two evils choice, but for now it’s the best we’ve got.
@David Tapper, @Reimar Servas, and anyone else concerned about the click+hold+move the cursor out of the link glitch - yep, we were aware of this one too and I had a last-minute addition to the article that doesn’t seem to have made it in explaining it. This behaviour is actually similar to how Firefox treats active links when you move the cursor out of a clicked link, believe it or not. The difference is that you can click elsewhere in the page to de-activate the regular link, whereas with Sprites 2 you have to click the link again. So, not ideal, and a bug, and thanks for your suggested fix David Tapper!