Fix Jerky Scriptaculous (Script.aculo.us) Animation Effects

I was adding some BlindDown, BlindUp animation effects to something I was working on today with Scriptaculous and had a bit of an issue with jerky animation. I’ve had this before and ended up ditching them but never really investigated why sometimes they are smooth as nobody’s business and others not.

As it happened, today, I had it working nicely, made a change, and the issue arose, thus leading me to the cause.

It turns out that if you add a BlindDown or BlindUp animation to a div that has padding or a margin set in its CSS as the effect begins to execute the div jumps to the padding/margin size and then the BlindUp/BlindDown (or probably others but I haven’t investigated) works on the remaining ‘area’ of the element.

So this is jerky:

<script language="javascript" type="text/javascript">
    Effect.BlindDown("divJerky");
</script>
<div style="height:50px; padding:10px; display:none" id="divJerky">
    
</div>

The solution is this:

<script language="javascript" type="text/javascript">
    Effect.BlindDown("divJerky");
</script>
<div style="display:none" id="divJerky">
    <div style="height:50px; padding:10px">
    </div>
</div>

If you add the padding to an ‘inner’ div all is well in the world again and everything works smoothly…

I know this isn’t exactly astrophysics but it is Friday afternoon and I’ve only just realised what the issue was so I thought I’d share…

Have a good weekend 🙂

Clicking more than once may charge your credit card multiple times…

I bought some tickets from the Royal Liverpool Philharmonic Hall (that sounds like I’m all very cultured but, sorry to disappoint, they were for a pirate fancy dress party). At the checkout I was confronted with this:

Jeysus… Come on. It’s the 21st century for heaven’s sake. Surely this problem has been dealt with before?

Well, yes it has. The common solution is to disable the ‘Buy’ button using JavaScript in its “onclick” handler (or change its text or some such thing). This is probably what I would have done but it has the problem that it falls over if JavaScript isn’t enabled and will incur the wrath of Uncle Dave… You could argue that those without JavaScript enabled probably number less than 10% and then only a tiny fraction of those are going to be trigger happy so it solves the problem more or less. To complement that you could provide a big red warning as above and hide it with JavaScript as the page loads. This would mean it is displayed to those without JavaScript and would be hidden from those with it. This probably fits in with the Unobtrusive JavaScript mantra.

A more meaty non JavaScript solution is to put some sort of form id into a hidden field in the form on the server side when it is first rendered and then store it when the order is first received. Then only process orders that have not already been received. This works but the problem that arises is that after the second, erroneous, click you have to deal with where the user is redirected to so you need to be able to retrieve the order using the hidden value to allow the next page, confirmation or whatever, to be properly served (I can’t use served in this context anymore without thinking of South Park). This requires a bit of thought as the order may not have been processed when the second click is ‘received’ so you may not yet have an order to work against.

So, has anyone else got any bright ideas or should those with an itchy trigger finger be left to suffer the duplicate order fate of their own making?