There were other areas I wanted to ask about, but I chose to keep the survey a bit more focussed – especially as it stretched to 19 questions already.

This could be something I look to include next year though if there’s interest in finding out about usage.

Yes, just seemed a bit CSS-heavy, when I had the feeling in my dev-career that CSS isn't a big thing when using a CSS framework.

The site has some issues on tablets, simply as the scroll event doesn’t fire until you stop scrolling, and so the animations don’t trigger continuously like they do on desktop browsers, only when you stop scrolling. It didn’t crash when I tested it though.

Unfortunately, as it’s a side project, I didn’t have time to rectify this (using iScroll or something similar). Would like to find a solution though.

Cheers dude :)

Thanks :) Think it's easy for some to forget it's a tech demo, so it isn't meant to be absolutely 'perfect', but really happy with the feedback so far.

Good idea re the curtain - it would be quite an easy port to make the animation work like that, so think I might do that at some point.

Think there are lots of possibilities around window resizing that haven't been explored yet - could make some really interesting effects...

Not a dumb question - only reason was because I wanted an excuse to play around with css animations and see how powerful they are in their current state.

SVG would probably be much more robust as a solution (as would canvas have been) - I think the demo shows more than anything that CSS3 animations need slightly more reliable support across modern browsers before they are a viable choice for doing some really nice things with them.

Thanks for the feedback - reason it's a bit buggy is mainly down to the implementation of the animation step-timing.

In Firefox, it works as you would expect, stepping through the spriting. In webkit, it's very inconsistent in how it renders, and doesn't look as polished because of this.

I've noticed the speed of the animation being effected by the resizing - like mentioned to others, will probably release a version which just shows the animations off separate to the window resizing as well to avoid this. The main reason for including reliance on media queries was to fit it into the mozilla dev derby criteria for this month.

Decent point on not knowing how big your window size is - think I'll update to include a width counter on the start screen.

Reason for the resizing down at the start is simply so only certain parts of the animation show at different times. It means I can control what width the animation is being viewed at, as otherwise I'd have to animate everything across a very large width potentially, which would be pretty time consuming, as this could be huge. Think with the feedback I've had, will release as a non media query animation as well when I get chance.

It took me a while to realize that the resizing was the whole point -- the scene animates as it gets wider.

There's nothing ground-breaking here, but neither is there in many of the XKCD stunts that we fawn over here. I think if you just describe it that way we'd all know what's going on.

What version of Firefox were you using?

I got this same behavior on Windows 8 using Chrome 22.0.1229.94 and IE 10.

I'm seeing the issue using Firefox 16.0.2 on OSX Lion.

Very strange - I'm on same version here.

I'm going to add a width counter to give more feedback on the resizing, as seems to be a bit of a bottleneck.

It seems the minimum reported by window.innerWidth on 16.0.2 (OS X, 10.8.2) is 453. Once it hits that, I can drag it all the smaller I like, and it is stuck at 453.

Using Firefox 16.0.2 on OSX 10.8.2.

Only reason it's controlled with media queries is because it was an entry for this months Mozilla dev derby (which is based around media queries).

I could pretty easily modify and release as a straight up animation though with no media query control.

I explored a few options - the reason I decided to make it controlled by the user was so it didn't have to open in a new window (as you can only control the width of the window with JS in a separate window).

Thanks for the feedback though - might create a separate self-running version at some point.

This only works when resizing the window? Would an ever-increasing div work? If you floated it right the size would always increase on the left, mimicking the drag and resize action that the user is doing.

That said, I get that you're pushing the limits as it is here and you've likely already considered this as an option.

Yeh, can use resizeTo but only when you have a separate window.

Not sure if an increasing div would work. Could potentially do it as an iframe, but not sure how nicely that'd work, would have to try it out.

Think I'll release it as a separate full animation at some point - will write up how it's all put together when I do.