This is pretty cool, but it also represents one of my main beefs with the HTML5/CSS standards and their past, current and future direction. That is the substantial amount of cognitive friction involved in doing many relative simple, even sometimes common things.

Implementation of often basic UI design concepts and interactions can quite often require some serious contortions of the HTML, CSS or both (though very fortunately, less and less the HTML). CSS is designed around being exceptionally flexible but nonetheless, there is no real consideration for usability or common patterns and use cases (or for the poor souls who may have to wrap their heads around these styles later on). I think in the end this is leading towards some pretty ugly legacy issues.

Sadly, I have no real solution here so I'm just bitching. I sort of see why we are at this point, and I don't currently see any way that a somewhat haphazard standards definition process can possibly focus on usability. Perhaps someone else here does?

Very true. It would be the job of the implementors to provide new properties that handle common use cases. For this example in particular, we now have:

animation-fill-mode

The problem is that right now implementors are all building different browsers that are attempting to provide a single consistent implementation of features as read off a spec document. A daunting, unenviable task to be sure.

Perhaps the solution is in frameworks or abstractions but that is also troubling. Who knows, it's still the best we've got right now, and that's going to have to be good enough for me.

there's 'cognitive friction' if you implement things in obtuse ways. fortunately web application development has a clean and easy way to accomplish these sorts of things: it's called javascript.

I could go on about the cognitive friction of javascript itself as a language but that's another discussion, but yes, I would almost certainly use javascript for this. I'm not really talking about this specific example, but a myriad of other examples where using transitions and other CSS features do make sense.

My favorite example is the way transitions handle height/width properties set it auto, in that they just don't. If you do decide to change the height of an "auto" sized item and want a transition you instead have to set it's current height explicitly (in Javascript) first, then set it to the height of the to the height of the new content (having calculated that somehow. What is worse you can't have the transition turned on, because setting from auto to X with the transitions on will cause a transition 'blip' from 0 to X.

The fact that this very simple and obvious case (that of changing the contents of something and having the height transition smoothly) was not addressed in the transition specifications is exactly what I am talking about.

Everytime I see a new technique I get all excited. Then I check it on Internet Explorer and the excitement fades.

On IE-9 it works the first time you try it but then the other buttons don't have any effect.

Just once I'd like an organization to have a corporate standard that mandates Chrome's latest version.

Something just occurred to me: Why exactly does microsoft still put any time into developing IE? Is there any benefit to them besides driving users to bing and other microsoft sites? Based on their licenses couldn't microsoft take the latest copy of firefox/chromium and just rebrand it, wouldn't they get the same exact benefit without wasting money on development?

At least initially, I think it was to maintain an applications barrier to entry--think all those businesses keeping IE6 around to run their web-based applications. Also, if a broken web browser is the most used, Joe Sixpack will think that standard-conforming web sites are broken rather than thinking that the web browser is broken, and thus stick with IE.

I hate that hacks have become "ninja" or "clever". You should always strive to write simple and readable code.

This (the original technique) is dangerous, of course - the browser might end up wasting a bit of CPU/power doing a nice 60fps animation of nothing. Even if this turns out not to make a significant difference in most cases, it's better to stick with JavaScript.

Unless "inf" (the floating point special value) becomes a CSS literal, I'm not gonna use this one.

The first sentence doesn't change colors on my iPad.

It doesn’t if I use a tap-click on my trackpad either; it only seems to if you hold it down.

Do these actions (tap-click, screen touch) not send separate mouse{down,up} events? Because that might be related.

In the demo, there seems to be a change in responsiveness as you approach a wall.

Yep, because every time you re-initiate the animation (by clicking a button), it starts an animation from the current position to the wall and sets it to get there in 2 seconds. So the speed is dependent on the distance from the target.

Given how easy it is to duplicate the same effect in Javascript, I see no reason to use this hack.

It's a Zeno's Paradox demo by accident.

Very clever. I disagree that this kind of thing should only be done in javascript. This is a very light-weight solution to various animation problems. In the old man in a room demo, it works perfectly for letting the GPU-accelerated browser handle that very smoothly, while freeing up your javascript thread for other duties.