Slidedown transition with scaleY

Here’s another “non-height” approach to slide down transitions: use scaleY (I haven’t checked this for browser support yet, I think IE9 at least will need a prefix for transform-origin).

Neat, I kinda like this one too. The overshoot on the slide down (where it goes a bit further and bounces back) is a touch of exaggeration, easily achieved with cubic-bezier timing. That sounds confusing! But it isn’t all that hard! Use Lea Verou’s amazing preview tool. Here’s the curve I came up with:,.38,.72,1.3

So this approach is still different to animating the height. The jquery slidedown adjusts the box height, revealing more content. The scaleY property squeezes the content which may look weird. Again, a little fade in while sliding may help. Also, scale is more attuned to squash and stretch so, you know, that’s something to play with!


javascript jam

Javascript jam is a fun project tacking along nicely at work. Twice a week, giving folks a chance to try their chops in javascript and learn how it works. Feels a bit bizarre but we’ve tackled turning random website backgrounds pink, implementing a word count validation plugin, and live updates of page text from textarea input events. Is it all leading somewhere? You bet!

I wanted to keep a little piece here for posterity.

For those that are missing an invite… it’s jam every other day! 🙂

You wanted a chance to jam twice a week on javascript projects? You got it.

1–2 pm, Tuesday and Friday, at the StarBoard.
(Is it lunch? Is it professional development? Ask your team lead!)

Twice a week not enough for you?

Try one of these courses. Bring your questions to a jam.

Or play with some live code:

What’s in it for me?

Ten reasons your friends recommend javascript jams!

  1. hands on experience writing javascript
  2. your questions answered (html, css and UI design too)
  3. contribute to the form builder, QA tool and single website experience
  4. invent your own innovative product
  5. practice MVP (there’s only so much we can do in an hour)
  6. aha moments! So that’s how they did that! (bring questions)
  7. increase your geek speak vocabulary with fun terms like closure, foo and immediately invoked function expression
  8. real world practice spelling color the American way
  9. combine your interests: ukulele + javascript =
  10. everything tastes better with javascript?

Where’s our code?

Keeping it here for now:

“I’m sure I’ll take you with pleasure!” the Queen said. “Two pence a week, and jam every other day.”
Alice couldn’t help laughing, as she said, “I don’t want you to hire me – and I don’t care for jam.”
“It’s very good jam,” said the Queen.
“Well, I don’t want any to-day, at any rate.”
“You couldn’t have it if you did want it,” the Queen said. “The rule is, jam to-morrow and jam yesterday – but never jam to-day.”
“It must come sometimes to ‘jam to-day’,” Alice objected.
“No, it can’t,” said the Queen. “It’s jam every other day: to-day isn’t any other day, you know.”
“I don’t understand you,” said Alice. “It’s dreadfully confusing!”

—Lewis Carroll, Through the Looking Glass and What Alice Found There

Hello javascript, I promise to call back

I went to a job interview the other day for a javascript developer (though it was advertised as a UI developer). It was pretty tough interview, coding an MVC javascript object with Kendo UI and answering some tough questions about javascript language patterns. The toughest being: explain the difference between a defer, callback and promise (and there might have been another one…) I got sidetracked and never really answered this which has been kinda bugging me. I’m not sure I actually know the answer—this is a depth of javascript programming I haven’t explored much (and certainly don’t get an opportunity to explore in my ‘UI specialist’ job) but I’ll have a stab. Then I’ll look it up.

First up, I think they are all asynchronous techniques. Async is all the rage, I started hearing lots about it when news about node.js started hitting the blogs. There was a bit of it back when AJAX was a hot buzzword, but it was limited to handling of HTTP responses then (which pretty much had to be async—delaying your whole program to fetch a resource over the net would be too slow). Now we’re using async all over the place!

My layman’s understanding is that a good use of async removes bottlenecks. Say you need to read a file or fetch data from a server or spin off a complex computation? Have that run separately and let your program keep running. You’ll pick that up when it’s ready. In synchronous coding, your code would be stuck waiting for everything to execute in order. That’s my understand of async coding. And I think callbacks, defer and promises are async patterns.

Callbacks I know about. A function that ‘calls back’ takes another function as an argument. It will call that function at the appropriate time (when it finishes what it was doing)—for example: when a HTTP response is received, when an event occurs, when an animation completes. jQuery has plenty of callbacks.

Defer I’m not sure about. I know there is a defer attribute in html for script elements, which indicates the browser can delay executing the script. I have a feeling there might be another concept called defer which is a programming pattern though.

I have only recently encountered promises on the Javascript weekly mailing list (which is excellent) and haven’t read the articles about them. I think they are similar to callbacks, if not a specific type of callback. The name itself is also a clue, I think the ‘promise’ relates to how the function calls back. I even think it might be a callback API. And I think at this point I’ve missed it and need to do some research 😉

I’ll be back to update this article after that!

[Update: ok, it looks like promises are a pattern for callbacks which make the code easier to read. A promise returns an object immediately. That object has methods to register callbacks. ‘Then’ and ‘When’ seem to be conventions for the method names. That reminds me of behaviour-driven development, but has nothing to do with it. Well, maybe I have seen the promise pattern in some BDD code. Aha! Chainable callbacks. It seems a promise is an alternative to throwing exceptions too, nifty! I’ve added some references to the end of this post.]

[Update 2: I can’t find much extra detail on defer, unless they were asking me about $.Deferred in jQuery, which looks to be a sort of promise factory.]

I really enjoy coding in javascript but I’ve never been a full-time developer (nor wanted to be). I don’t even know if I’d even qualify as a paradev! To my workmates it probably looks like I code a lot, but there’s no pairing with another javascript coder and challenging ourselves to explore the latest best practices in javascript. It would be pretty awesome to do that every day and really push those limits—but there are lots of other interesting ideas to explore! Another article I read this week was contentiously titled Why UX Designers Need To Become Project Managers (to which I say—cool! But it better be PRINCE2 and it had better embrace product-based planning—absolutely no PINO!)

I could do advanced javascript on my own time, and I do a little—when I’m not busy with other hobbies—playing bass, gaming and family. I’m happy with the balance I have going. Also, sometimes I like to play with graphics and HTML semantics, and only get into scripting when it ‘progressively enhances’ my already useful code 😉


  1. Asynchronous Programming in JavaScript with “Promises”
  2. What’s so great about JavaScript Promises?
  3. You’re Missing the Point of Promises (this article is great!)

Saturday afternoon coding

It’s high time I talked a little about the coding I do. Since my job transformed into a “User Interface Specialist” I’ve been back to coding — implementing the user interface for web applications. After years of being a backseat developer (i.e. doing QA for other developers) and choosing to try out the BA field instead, this change was thrust upon me. Go figure. Anyway, coding is a lot of fun. Although the pay isn’t quite as good. It is good honest productive work though. Gotta love that!

Those who follow my tweets may often be amused/confused by the references to coding. Our development team has been introducing the agile way into Queensland Government (I am sure we are not the only team doing this). I sometimes get my hands dirty into the java code (usually acceptance tests with Selenium), or even the struts2 setup, but usually I’m working on good ol’ HTML, CSS and javascript. I’m on my own a lot as I resist working in a closed in meeting room. There’s a good vibe in there, but also a distinct lack of natural lighting. Why get up in the day if you don’t even see the sun? I digress …

So I am on my own, fumbling along my own agile journey. Learning the zen of coding. One of the key pieces I have been working on is javascript form validation, and having worked on it the old way — code stuff and deal with problems when it breaks — I’ve been trying this red, green, refactor (aka Test Driven Development) idea. And, I have to say, I am liking it.

I contribute a lot of the code towards that in my own time. I rationalise giving up my time because the code has been made open source, a few of us have “joined forces” on a project named “use the forces”, to collaborate on code and products which we aren’t afforded time to collaborate on at work. We are compelled into meetings to discuss improving productivity, just not encouraged to work together productively. There is paperwork to write after all! Sorry if that sounds a little scathing: I’m a worker, not a talker (outside my blog!), and I have high expectations that leadership have yet to exceed… At any rate, I can make open source contributions as often as I wish, and I can enjoy go home on time day every day at work. It’s sweet and I Like It.

That was a long ramble. For people who wonder how I do what I do, why I do it, what it’s like, here is an insight into a Saturday afternoon coding session. I wrote these notes while coding, for this post. This is what coding is like for me. Distractions, warts and all.

do an update or checkout, make sure the source is the latest

fire up firefox with firebug (portable apps), it’s 3.5.2

good idea to test with multiple browsers, but one while developing. don’t have IE6.

talked myself into runnning IE8. Press F12 to get developer toolbar, toggle to IE7.

using e-texteditor (like textmate) on windows

run the tests. forces tests are in test/jquery-1.3.2.html (this is a wrapper to run all the tests)

find the file and right click and choose open with Firefox (I already had firefox running so it used the portableapps one and not the installed version — it doesn’t have the add-ons I need!)

may be a little slow downloading YUI to run tests (especially if downloading a game from steam in the background over 3G broadband)

1 test failing. find it, fix it, save it. run again.

can run in both Firefox and IE8 in parallel (even if encoding video in the background, if you are an avid multitasker, I recommend a multicore CPU — it’s essential for GTA IV anyway!)

tests passed, all good, don’t forget to check in (even if being distracted by Buffy – the first episode where Spike and Drusilla appear – and the kids playing trains)

now we’re ready to code something new.

(after we send the kids back to the Wii and outside for a splash in the wading pool)

there’s a bug discovered in the confirm validation whilst playing with the UI, which reminds me that there’s a demo form so you can interact with the UI whilst working. whilst coding to tests should be enough, I like the immediate feedback from trying it out (when coding UI), and there’s no real point running the test if I know it isn’t working anyway.

here’s the demo form. it has email and confirm email, and they are setup to work, like this.

type ‘’ and ‘foo’ and tab away (validation runs onblur/onchange) the error appears.

correct the error, ‘foo’ becomes ‘’ and the confirm validation is happy.

but what if it happened the other way? let’s reload the form. and … confirm validation correctly highlights the problem.

fix the first field and tab on through … the validation hasn’t kicked in.

This is exploratory testing. It’s also a good old fashioned user-centred design technique “put yourself in their shoes”, thinking through how users will interact with the application. Don’t just think of one way they may use it, think of all the different ways they may use it. It’s not just random typing and clicking.

does Buffy really plan to use that machete on spike? oh. on the salad. ok.

look away from the tv.

Is this a bug?

You do have to decide if issues found are bugs, or possible features, or just interesting anomalies to note.

This is a bug, forces validation must be intuitive and easy to use and this clearly fails that. That’s part of the design goals.

now, at this point we could start solving the problem and I already have an idea in my head it’s related to the onblur/onchange trigger happening only on the con
firm field. I probably need to track the dependency between the two fields and run the validation when either changes.

This line of thought is very dangerous, because it overlooks a more important problem.


if there is a bug, shouldn’t that show up? it’s passing all the tests, so there is a gap in the test coverage.

before we do anything else, let’s capture the problem as a test. our test should set the wrong value for email, the right value for confirm email, and verify the confirm validation message appears. it should then correct the email value, and verify that the error has disappeared. This test should fail, because we haven’t fixed the code yet. But, that’s important too, that’s how we verify the test is coded correctly.

ah Angel playing at Angelus. Cool, but not the same as when Angelus really takes over.

Let’s code …

coded a new test. it’s in unit/forms.ui.js

must confess not having a great handle on unit vs integration vs acceptance tests. This feels like it might be more than a unit test, but the important thing for now is getting the tests in place. I am going to need to sort it out one day.

The new test fails, as expected.

Unfortunately it’s failing in the wrong place, the error message didn’t even appear. Debug the test. I insert “this.wait(null, 10000)” in to pause the test so I can see it.

aha, I forgot the setup step. I have to specify that the field needs confirm validation.

That’s done with this: $(‘#confirm-email’).forces_attr(‘type’, ‘confirm’);

I’m going to place that in the setUp method of the test case (see YUI3 for more) because it seems likely I will forget this again. I hope it won’t upset any other tests, but there’s an easy way to check this — run the tests again!

remembering to remove that 10 second wait will help. the test failed on it. which is useful when debugging. and extra useful in this instance for allowing me to grab a screenshot. and I saw the UI displaying the right thing so I have some confidence.

remove the pause, run the tests again.

everything passed. This is not good. Our test has not caught that bug. Let’s put the pause back in and find out why.

The UI is showing the right thing. The value is valid and confirmed, but the alert message is still being displayed. The test is supposed to check it doesn’t show that message. Something is wrong with the test.

ah, I was going to fix using a console log. But I’ve noticed, it is using $(‘#email-confirm’) instead of $(‘#confirm-email’). D’oh. Mistakes like this are the bane of any coder’s life. Especially when they don’t throw any syntax errors.

I can see this error in the previous test (that I copied from). A bit disturbing. Search and replace.

success! the test now fails at the expected point. we’ve now achieved the “Red” from red, green, refactor. We have a working test.

Don’t check in at this point. That would mean the next person who updates their copy from the project has this test failing and probably no idea why. They’ll try to fix it, we’ll be coding ourselves, it could lead to conflicts. It also erodes faith in the build if you update to the latest source and it’s broken. Like when we went to start and had to fix that other broken test. Not good.

So hold off checking in!

But it is a good time to take a quick break and help daughter play Purble place on Windows7. Now that she’s setup and happily occupied …

What comes after red? Green. We have to fix the code now so that it passes the test.

I’m going to change the way confim works, as I said before:

It currently uses this: $(‘#confirm-email’).forces_attr(‘type’, ‘confirm’)

I don’t really like this, the “forces_attr” function is a pseudo for attr() and it makes sense to use attr(‘type’, ’email’) as email is a valid type (HTML5).

There’s no such thing as the “confirm” type.

How about $(‘#confirm-email’).forces_isConfirmationFor(‘#email’) ? I like the explicit way this associates the two fields together. We’ll need to change the tests. It’s an easy change. As with any change, run those tests again.

Now it fails on a javascript error – we haven’t implemented that function.

Let’s solve that.

Coding time! Write a new stub function. It belongs in jquery.forces.forms.core.js

Run the tests.

This has broken the old confirmation validation as well. That’s ok. It needed refactoring, you can see it was a bit heavy on processing, running through all form fields to find the previous one. This direct association will be more efficient.

Although I don’t like the idea of the confirmation being of a field elsewhere in the form, but that may be personal bias. Hmm… I could make this method isConfirmationOfPreviousField() and hard code that. But maybe another designer will have a good reason for separating the fields. In fact, I read something recently about that. Let’s allow it.

Remove the old validation.

*sigh* youngest daughter tipped a whole bunch of paper on the floor. That’s a bit distracting. I better pick it up. ok, tidy again.

let’s recode the validation. We know the tests are ok, let’s just code until it works. I’m not describing my coding here today.

much excitement over the matchup game. two excited girls. “i won daddy!” that’s lovely girls.

I’m coding. Ok, now they’re making me laugh. ok, discipline. code.

Let’s flesh out this forces_isConfirmationFor method.

It occurs to me that now that I am tracking the associated field, I’d like that exposed. The UI code will need to know that, as it knows what label to display (e.g. doesn’t match “Email”)

let’s put a test in for that. That’s so simple it really will be a unit test. I’m putting it in unit/forms.js because it relates to core (not UI) functionality. new test case to find the confirmation field. note that it uses the same method, but passes no arguments. That seems to make sense to me.

Back from emergency track repairs to the new Thomas train set and with relatives arriving for a BBQ, may not accomplish much more. Oh, BBQ later, this is whipper snipping time. I have the best inlaws.

Let’s try to get that test to pass.

First attempt at code, run the tests. Fails, but we get an interesting message.

ok, fixed. I just had to remember we passed “#input1” to the function, not a jquery object, and the function had to turn it into a jquery object. I wonder if it works if we pass a jquery object? That deserves a new test.

It passes. Fantastic. That’s jquery working nicely for us.

Note the comma placement in adding that test. If an extra comma slips in, IE becomes very unhappy. It doesn’t like a comma after the last item in an object. It caught me out recently, so it is fresh in my mind. Let’s check the tests in IE8. It’s much slower. I am looking forward to the performance improvements IE9 promises.

Good. It returns the same results as FF. Let’s recap.

We can now specify a field is a confirmation for another field, and find out what that field is. Those tests
pass, we’re confident that functionality will continue to work.

Let’s work on addressing those other tests, and implement the actual validation. We’ll reproduce the functionality we had before. When the confirmation field is updated, it’s validated. (That won’t solve the original bug).

Doesn’t seem like we’ll need much code. And now I realise I don’t have a good test for this. The tests are based on checking the UI shows the correct value. I just want to test that the field state is correctly flagged as “invalid”. If the field is invalid, the UI should work anyway. But because I’m refactoring I need to work on the UI too. I want more test coverage so I can get confidence this bit is working before I code the UI. Really, I should have those tests already in place. Still learning the ropes and anticipating the right tests.

I will comment out the new code and write the tests (to get them “red”)

Refactored to combine the two previous tests, and added two new ones to check valid/invalid status.

And conveniently missed out a comma which caused a syntax error. Easily fixed.

Good thing about running these tests frequently is you find these things quickly. I probably should be pairing to avoid more of these mistakes in the first place. I’ve made so many mistakes so far, can you imagine if I hadn’t tested anything yet? Sorting through it all later would be a nightmare!!

Some more bugs in the test fixed, and we’re at the right state now.

4 tests are failing. That’s a lot, I think one at a time is ideal. I don’t think red, green refactor is about lots of failing tests! You want a much shorter cycle between red and green. Anyway, 4 tests failing. 2 are the pre-existing UI ones, 2 are to test how the confirmation validation is implemented (not how the UI looks).

Let’s see if uncommenting our code fixes that.

Nope, there was a bug. 11 errors showed up.

When that happens, you know something what you just changed has got a (usually simple) flaw. In this case, “isConfirmationFor()” vs “e.isConformationFor()”. Simple. But important! One can’t call methods without objects (well, you can, but that’s a ninja secret).

Fixing that and we return to 4 errors. That’s a bit better, but means the implementation did not pass the tests. Why not?

Let’s introduce some logging … hmm, it’s not logging anything for those two tests. Is it even validating anything? More logging. Nope, doesn’t seem to be. Aha, in that test case I will need to enable validation for the test form.

That was indeed the problem with the tests, they pass now.

So, we know that validation works for the confirm field (but not the source) field. It’s not working at the UI level though, let’s fix that up.

Wow Super Smash Bros Mega HEAVY brawl is a lot of fun. But it doesn’t get the coding done. That was very distracting Daniel. But great fun!

Quick run through and … we’ve restored things to where they were!

Now, I’m cooking. Not “cooking” as in “coding successfully”, but “cooking” as in “cooking at the BBQ”.

When I’m back, we can fix that bug so the confirmation validation occurs when either field is updated! Write some more unit tests first …!

* * *

Um, didn’t get to any more coding that Saturday. I ate tea, watched Robots, played L4D2 scavenge mode. It was awesome! More coding tomorrow. Maybe.

Ok, 5:51 pm the next day …

running the tests is even slower now YUI3 needs to download over shaped (64 kbps) broadband. If you can call it broadband.

1 test failed. It’s that bug, the confirm alert doesn’t go away when the original field is corrected. I’m gonna write another test for this, that’s not at the UI layer.

Test works. (It failed at the expected point.) Let’s code the validation (not the UI) so it works.

When the confirmation is setup, it now stores the “confirm” field as a “validation dependency” for the original field. When validating, it will check for dependencies and validate them. I’m aware that if this was called twice, things will go a little awry.

For example:



The second call will result in #email having a validation dependency for confirm2, that overwrites the one for confirm1. I don’t consider this a bug, because I don’t currently need to deal with more than one validation at a time. So I have not coded tests around it. Note that $(‘#confirm1,#confirm2’).forces_isConfirmationFor(‘#email’) should work anyway. But consider that an undocumented feature. It is certainly not a requirement so there are no tests guaranteeing it will work.

Tests run and there are lots more failures. Nothing new should be failing, there must be an error in the code changes I made.

This time, I’m using undo to return the code to the state it was. I don’t feel like debugging. Yes, that’s reset everything nicely. Sometimes this is the more efficient approach. You learn to judge when. Depends how much code you invested and how wrong things went!

Coding attempt #2.

OK, the validation dependency is now stored and there’s a test to verify that part works.

Now to invoke that dependency during the onchange validation. It’s not needed onsubmit, because ALL fields within the form are validated anyway.

Wow. Everything just passed with one line of code!

Because jquery runs on an array of objects, it was a snap to add the dependend fields in. Basically the change was control.forces_validate() to control.add(‘dependents’)).forces_validate().

I love jquery.

The UI has passed as well. I guess it was already setup to work when the valid/invalid events fire.

Still, let’s test the demo form and see it in action.

The demo form isn’t working. It’s still using forces_type(‘confirm’). Let’s update it to the refactored version.

$(‘#email-confirm’).forces_isConfirmationFor($(‘#email’).forces_attr(‘type’, ’email’));

It works!

Important to note that this new validation will not run against empty fields (this is by design). If you *require* confirmation, then you need to make the field required also. Otherwise, it implements optional confirmation, as in it may be omitted, but if present must be valid. I don’t have a use case for that, but it is the design pattern I follow for all validation.

This is the code people are likely to want.

$(‘#email,#email-confirm’).forces_attr(‘required’, true);

$(‘#email’).forces_attr(‘type’, ’email’);


There are many ways to rewrite the above, but that is a simple way to show how it works.

Let’s do an IE8 check of the tests. All passed.

Ready to check in, preparation steps.

Run compile.bat to combine and minify the JS code.

Run the tests against the minified version. I like to do that in Chrome, just for something different.

All passed.

Let’s check that code in. Don’t forget a handy comment.

We’re done! Let’s eat tea.

Believe it or not, that’s how I code. It is far less adhoc than it seems. And when I am less tired, I might even add in all the extra screenshots I captured and this post may even make sense.

It might have been quicker to just read the revision notes 😉