Repository Updates
iOS Theme for jQuery Mobile
Good news! I’ve just pushed some major changes for my iOS jQuery Mobile theme. It now works with jQuery Mobile 1.1.0, which was a bit of a struggle. It also forced me to do some major code cleanup, delivering cross browser gradients and various enhancements I had been putting off.
A full list of changes and resolved bugs follows:
- Supports jQuery Mobile 1.1.0 (this was a nightmare)
- Code cleanup more strictly obeys my coding conventions
- All gradients and effects are now cross browser compatible (Issue #2)
- Updated slider toggle to iOS 5 style (Issue #7)
- Got dialogs looking as close to native as possible considering jQuery Mobile doesn’t support overlayed dialogs (they’re standalone pages) (Issue #3)
The changes have introduced a few minor visual quirks relating to the .ui-focus box shadows etc, but hopefully these will be rectified in the near future.
jQuery Gantt
I made some minor code changes, but the most important thing here was the addition of documentation. The original creator didn’t provide any, so hopefully this makes a bit more sense. I’m sure I’ve missed something here and there (holidays?), but I’ll fix that up as we go.
The changes:
- Added documentation and better demo with bootstrap popovers
- Works with latest jQuery 1.7.2
- Merged pull request for “undefined error”, thanks Nathan Colgate.
- Code and folder cleanup
Front End Development Guidelines
The page now passes HTML5 validation. Apparently some people care about this.
3D Accordion Effect - UX Lab 006
I posted the following experiment as a way of demonstrating just how far the line has blurred between web based animation and OS based animation. I saw Dribbble shots (one and two) by Indian designer Pranav Pramod and was inspired to replicate the effect in CSS3.

Unfortunately nothing is ever as easy as it seems. If it was, someone else would have already posted a similar effect. The problem is that when animating something with a 3D transform with a forced perspective, there is no way to measure or mirror the actual height represented in the browser using CSS. If you animate the parent element from 0px in height to 30px, it’s a straightforward linear animation. The 3D transform, on the other hand, changes on a non-linear scale because of the perspective.
There are two solutions, neither of which are desirable.
The first involves JavaScript, which frankly I had tried to avoid. In this example, the animation is triggered by the addition of a CSS class via JavaScript - but could just as easily be bound to an :active:target CSS event. The only way to get the actual browser rendered height of the element is to get it via JavaScript with the obj.clientHeight getter. While discussion pointed to wrapping the object in a parent element and not needing JavaScript at all, this does not work in all browsers.
Instead the JavaScript method involves binding a function with requestAnimationFrame which sets the parent objects height to mirror the calculated height of the transformed object. Accurate, but if we wanted to perform calculations many times per second, why did we bother animating with CSS at all?
The other method, considerably less accurate and very fiddly, is to match the easing or timing of the two animations. It may be possible to create a custom timing function using cubic-bezier which matches the rate of easing of a 30px tall object, rotating from -90deg to 0deg, with a perspective of 400 units. But why would you? That’s shit house.
Maybe in this instance a flat out Canvas animation would have been much more sensible. You’re still performing a function every ‘x’ milliseconds, but at least the canvas itself may be hardware accelerated. Until CSS animation matures, we will most likely have to abuse the JavaScript add-ons such as the one described earlier. Or even better yet, sever the ties with HTML and CSS and - get this right - use graphical languages for what they’re intended.
Ninja Edit: Also, you can’t yet animate background gradients so the whole 3D effect on the depth of the flaps is kind of impossible for now.
Sad-face Edit: The second I posted this, someone posted pretty much the exact same thing to Hacker News in a much more polished way. Check out Paperfold CSS.
Vertically Centering DIVs
The ability to vertically center a DIV in HTML is one of the holy grails of web development, along with sticky footers and just generally making shit work in IE. I had to vertically centre something recently, and I was sick of using the dirty hacks involving absolute positioning, negative margins and extra HTML elements.
The solution below works in all modern browsers, and is supported in IE8 and above.
<div id=”centered”>
I’m centered vertically and horizontally
</div>
#centered {
position: absolute;
top: 0;
right: 0;
bottom: 0;
left: 0;
margin: auto;
width: 200px;
height: 200px;
}
It is listed as Method 4 on this page, but frankly should be Method 1.
The reason I love this solution so much is that we have all been using margin: 0 auto; to horizontally center things for yonks. This answers the age old question of, well, why doesn’t it work vertically either? Another big plus is no extra HTML elements. Generally you’re forced to create one to horizontally center an item. Another to offset it 50% from the top and, depending on your cross browser confidence, another to negatively offset this with a margin. ■
Front End Development Guidelines - Update
Well that was a wild ride indeed! Since release, the front-end development guidelines I posted have gone bananas. Tens of thousands of page views, plenty of GitHub forks and followers, and even a kind word or two. Many thanks to Paul Irish and other figureheads for tweeting about the resource I put together. It really helped spread the word about what I was trying to do, and in turn pulled in some great comments and suggestions logged through the GitHub issues interface.
As we stand, there are currently 8 open issues and I’ve managed to close 20 others.
Some of the most recent changes I’ve made include:
- Rewriting the section on commenting your JavaScript. My team leader at my previous employer put this one together when he was proofing my work, and slipped it in. A lot of people have flagged it as a massive WTF and it has seen been replaced.
- I’ve merged in a range of spelling and grammatical changes. What can I say? Me dun speak english good-like.
- Added the new “micro clearfix” to the section on clearing floats.
- Added a section on commenting CSS blocks (handy!).
- Further discussed whether remapping “this” to “self” is a good idea.
- Added section IDs for deep linking (but no way to easily do so, as yet).
- Removed the Gotham web font, which I embarrassingly left in, ignoring my own advice.
Thanks for reading and contributing, be sure to send through any further suggestions using the issues interface or via my email address listed on the right.
My role with my last employer involved creating websites, applications and widgets with front end technologies like HTML, CSS and JavaScript. Other parts of my job included code reviewing commits and running training exercises to spread the knowledge around. When I handed in my three weeks notice, they were quick to ask me to write up guidelines on the best way to write maintainable, clean and accessible code. What follows is a GitHub hosted document, allowing for revisions, forking and issue logging - a concept I “borrowed” from the great resource JavaScript Garden.
Considering my knowledge is all gleamed from many years of reading Hacker News and following Twitter links, it definitely has holes. I am completely self taught in that regard. So although I can’t vouch for the accuracy of all the information, hopefully you can log any corrections or raise any questions via the issues interface.
Linking JavaScript Objects to HTML Elements
Alternative Title: The jQuery $.data() Function is Awesome
![]()
The Workflow creation tool I’ve been working on and blogging about (design & code pattern) would have been impossible without forcing myself to learn object oriented (OO) JavaScript. It was a pretty steep learning curve for a designer, and I soon came across the common pitfalls of writing OO code. The factory pattern structure I linked to above took care of most of the problems like: pushing pseudo-class objects to an array, easy find methods without the use of hash tables, and deleting objects non-destructively.
One thing that took me a while to wrap my head around: How do you form a relationship between the “back end” object instances and the HTML/DOM objects you output from these?
Say you have the classic Person object example:
var collection = [];
var Person = function(params) {
this.name = null;
this.age = null;
$.extend(this, params);
collection.push(this);
}

When I came across the problem of being able to link back to the object itself, the first (and laziest) solution that jumped to mind was searching using an instance’s unique ID. Creating the objects initially gives you the chance to ensure the HTML and back end instance shared the same ID. At a later point when you need to find the instance, you can loop through your objects with class manager shorthand findBy() function:
Manager.prototype.findBy = function(p, v) {
for(var i = 0, len = this.objs.length; i < len; i++) {
if(this.objs[i][p] === v) {
return this.objs[i];
}
}
};MyManager.findBy(“id”, 999);
This made a lot of sense initially:
- HTML attributes can only be strings.
- Make the HTML element and the back end object share an ID
- Loop through and match the object when required
![]()
An Example
In this example, we have to get the ID from the HTML element, convert it to an integer and then finally: loop through all the instances until it finds a match.
// get the ID value
var theID = parseInt($(this).attr(“objectID”), 10);
// silly loop to find the object
$(collection).each(function(i, item) {
if (item.id === theID) {
item.birthday();
}
});
But why bother looping? Maybe a hash table would be better suited to your scenario, but for me I wanted something more dynamic.
![]()
The Better Way
The jQuery $.data() method is awesome. On face value it’s like the native $.attr() method but doesn’t restrict you to a string value. What this incredibly long-winded post boils down to is the realisation that you can bind your HTML elements directly to their back end objects via the use of the data attribute. No (visible) loops.
// set the data attribute originally
$(obj).data(“personObject”, self);// call birthday on the object directly
var theObject = $(this).data(“personObject”);
theObject.birthday();
You don’t even have to declare a reference to the object, you could just as easily chain up your calls. A word of warning though: this can get a bit confusing if you’re using a chaining library like jQuery, especially if your object prototype functions share names like “remove()”. ■
$(document).ready() before CSS ready
I ran into a bit of an issue today that was causing some real headaches. Essentially, the $(document).ready() event is fired before the CSS has finished loading and rendered out. This was breaking a dodgy resizing script in IE6 through to IE8, where a height was resized before the padding was applied from the stylesheet. The result was a cropped window of content, visually ‘off’ by the padding amount.
You’ll find plenty of articles online telling you to call the stylesheet before any JavaScript and blah blah blah… but if you’re already doing that, you’ll have to Google a lot deeper to find the solution.
Using the $(window).load() event ensures the CSS and images etc have loaded before the function is fired. Oh how I wish I knew this 24 hours ago!

Read more about the difference between document ready and window load.
