David Tong

IE bugs caused by CSS filter property fixed in jQuery 1.7

David — Thu, 17 Nov 2011 23:00:34 +0000

I assume that everyone knows about IE’s ‘filter‘ CSS property. We use it on IE< =8 mainly because they don’t support the W3C opacity property.

The new jQuery 1.7 finally added a fix to an issue with IE’s ‘filter’ property. If you look at jQuery 1.7′s source code, you see that it does style.removeAttribute( “filter” ) when opacity is 1 upon setting the opacity csshook.

The jQuery upgrade eliminates the need for us to do something like this:

1
2
3
4

j_obj.animate({opacity: 1}, 500, function() {
$(this)[0].style.removeAttribute('filter'); // remove filter property at the end of animation... no longer needed in jQuery 1.7 and higher
// alternative: $(this).css('opacity', '');
});

Why did we have to manually remove the filter CSS property for IE when opacity is 1, and why is jQuery finally doing it internally?

To recap, the filter of IE property is the cause of a few common IE bugs:

Fuzzy/ blurry text

This occurs on IE6 and IE7. Text would look fuzzy after some opacity animation if the filter CSS property is left behind. As stated early, this can be fixed by manually removing the filter property. See another blog post for more information.

Content clipping/ cut-off

This occurs on IE8 only. Elements/ containers/ divs can be cut off at the edge of the parent container even if various tricks (z-index, position: absolute, overflow: visible) are already applied. The solution is, again, to remove the filter property. See another blog post for more information. (Thanks my colleague, Pavel Sergeev, in Russia, for pointing this out.)

Other changes

When you upgrade jQuery to version 1.7, pay attention to any instance of jQuery.isNaN(), which is removed in this version of the library. Also, event.layerX/layerY is changed to event.originalEvent.layerX/layerY, so be sure to modify your code accordingly.
jQuery 1.7 is less forgiving about passing in non-function to, for example, .load(), when a function is expected. Prior to 1.7, it still worked if a setTimeout, which would return a timer ID, is directly being passed in to the event.
If you have any swf objects in your app, watch out for an “object expected” error in IE. It’s probably trying to do elem.getAttribute() on an elem that is an object DOM element (with the tag).

Integrating Canvas into your Web App

David — Wed, 17 Aug 2011 21:13:12 +0000

My tutorial on HTML5 canvas has finally been posted to html5rocks!

I demonstrated the integration of a Canvas editor and the Box application during the Hackathon in December, 2010. This article was written as a result of the project done by my colleague Hieu Nguyen and myself.

Thanks Paul Irish and other friends at Google for reviewing the article.

It’s all basic stuff, but I hope you enjoy it!

Upgrading jQuery – from 1.4.x to 1.6.x

David — Sat, 28 May 2011 11:28:33 +0000

The jQuery library, specifically its architecture of Ajax handling, has been significantly re-written in 1.5. We at Box love jQuery, but we had to skip version 1.5 because a quick jquery.js file replacement failed many of our automated test cases.

After a couple of weeks of debugging, we finally migrated to version 1.6.1. In this post, I want to share my experience upgrading jQuery from 1.4.4 to 1.6.1.

prop() and attr()

prop() is a new method to retrieve a property value of a DOM object, while attr() is used to retrieve attribute values written in the HTML source.

attr() used to be the single method to handle both cases. Basically, in jQuery 1.4, attr() first checks if the attribute is explicitly written in the HTML code, then it looks at the object created by the HTML tag, and inspects its object property. When you upgrade to newer versions of jQuery, you may need to change attr() to prop().

In our code, we had something like this

1
2
3
4
5

$('form').each(function() {
if ($(this).attr('method').toLowerCase() == 'post') {
// do something
}
});

This code used to work in 1.4.x, but it fails in 1.6.1. I then found out it fails on this case:

1	<form action="process.php"></form>

The problem is that, in 1.4, when a form has no method attribute written in the HTML code, it would return an empty string because method is a property, which happens to be an empty string, of the form object. However, in 1.6.1, the attr(“method”) call would return undefined because it is not written in the HTML code, and so doing toLowerCase() on undefined triggers error.

To fix the issue, we changed attr() to prop():

1
2
3
4
5

$('form').each(function() {
if ($(this).prop('method').toLowerCase() == 'post') {
// do something
}
});

According to the documentation, prop() should return undefined for the value of the property that has not been set. In reality, this is not true when doing prop(‘method’) on a form. As previously stated, “method” is a property of a form object even if it’s not explicitly written in the HTML code.

This is not the end of the story. It turned out that the JavaScript block shown above still fails in a form that looks like this:

1	<form action="action.php" method="post"> <input type="ratio" name="method" value="xml" />XML <input type="ratio" name="method" value="json" />JSON</form>

And when we do $(‘form’).prop(‘method’), instead of returning the string “post”, it returns two input elements! The reason, which should be obvious, is because there are two input fields that are named “method.” As a result, we need to add to the coding practice that no input elements should be named “method.”

You now probably see some of the benefits of separating prop() and attr(). In addition to clearing confusion between HTML attributes and DOM element properties, there are a few more benefits using prop() when it’s applicable:
- From John Resig: “Accessing properties through the .attr() method will be slightly slower than accessing them directly through .prop() (as .attr() calls .prop() internally in order to handle all property-related mutation)”
- Attributes like ‘checked’ and ‘value’ of input elements do not map to their corresponding properties in the DOM elements. So doing attr(‘checked’) or attr(‘value’) will only retrieve the default/ initial value, but not the current one. You browser uses the property, and not the attribute, to keep track of the current value. That is also the reason why in previous versions we had to do :is(‘checked’) and .val(). Now that we have prop() and we can rely on it in getting the current value.
- In previous versions of jQuery, both attr(‘checked’, true) and attr(‘checked’, ‘checked’) would work. When examining the value, we have to look for every possible values. Using prop, we are sure it would return boolean for things like ‘checked’ and ‘readOnly.’

If you still find it confusing, visit http://www.timmywillison.com/2011/When-to-use-.attr()-and-.prop().html for a list of recommended usage.

Ajax and parseJSON

In the Box app, we use $.ajaxPrefilter to handle Ajax calls that are supposed to return a JSON object. Our unique approach is that the backend actually returns what we called BOXON (BOX Object Notation) strings, and we use ajaxPrefilter to convert BOXON to JSON by modifying the string and calling eval(). In then becomes a JavaScript object.

This no longer works in jQuery 1.6.1 (and probably 1.5+). Basically, the new Ajax architecture in jQuery would call $.parseJSON() after ajaxPrefilter. Here is the first few lines of $.parseJSON():

1
2
3
4
5
6
7

parseJSON: function( data ) {
if ( typeof data !== "string" || !data ) {
return null;
}
//...
// convert the "data" string into an object and return that
}

Because data, when coming from our own ajaxPrefilter, is already an object, the JSON object becomes null after parseJSON, and thus the Ajax calls get a null value to work on.

To fix this issue, I had to patch the jQuery code like this:

1
2
3
4
5
6

parseJSON: function( data ) {
if ( typeof data == "object" ) return data; /* true for both Array and Object */
if ( typeof data !== "string" || !data ) {
return null;
// ...
}

getAttribute on Flash objects

We also got a weird bug that occurred in IE9 only. After we moved to 1.6.1, the “upload” button won’t work!

After some investigation, I found that it’s related to our very own upload approach. We use HTML5 upload on browsers that support it. IE9 is not one of those browsers, and so we use a SWF object to handle it. Somewhere in the code, it triggers a click event on the SWF object that checks for $.(e.target).attr(‘id’) == ‘something’. SWF objects do not implement the getAttribute() DOM method, and so it fails.

This is such a race case and probably will not be seen in your application. A quick fix I added to the code is to return immediately in the custom mousedown/ click function if the target does not implement the .getAttribute method.

Plugins

Many popular jQuery plugins have to be upgraded to become compatible with the latest version of jQuery. For example, The jQuery Form plugin needs to be upgraded to 2.80. One of the reasons is that jQuery has removed the internal $.httpData() method since version 1.5. Plugins that make use of these methods need to be rewritten.

The jQuery validation plugin is another plugin that needs an upgrade. It works perfectly once we upgrade it to the latest version of 1.8.

Sweet, now we’re on the new train!

I am very happy about the new version of jQuery. In addition to the aforementioned new Ajax architecture (which brings good stuff like “deferred“), there are performance improvements (also see http://bugs.jquery.com/ticket/7341. Now I don’t have to modify the Sizzle engine to make it faster in IE!), and a lot of nice fixes and features. If you have not upgraded yet due to compatibility issues like the ones described above, I suggest you to take some time to do some investigation and adjust the code. Don’t stay behind and miss out the good things the new version of jQuery brings to the table.

Popup blocker detection pattern

David — Wed, 13 Apr 2011 01:36:26 +0000

Have you ever wondered why popup blockers hate certain popup windows, but not others?

The underneath formula is pretty simple: if a window.open() call is not on top of a click event in the call stack, popup blockers would block it unless it’s on the exception list. This can be verified using Firebug or Chrome Developer Tools.

Call stack of window.open() triggered indirectly from a click event

Call stack of window.open() triggered from an Ajax callback

Therefore, the rule of thumb is that you should avoid calling window.open() from anything other than an user-initiated click event.

What if it’s a design requirement, or if it really works better for your application to call window.open() arbitrarily?

We used to be able to easily detect whether a popup window is opened successfully. When a popup window is created using window.open(), it would return an reference object to the new window if it’s successful, and null if something prevents it from opening. This works for all major browsers except the latest versions of Chrome (9 and 10), which always return an object.

This is explained in this Chromium ticket. The popup blocker in Chrome actually just hides the popup window behind the scene instead of blocking it from opening.

Until the Chromium ticket is closed, this is probably the most universal way of detecting popup blockers:

1
2
3
4
5
6
7
8
9
10

// try to create a popup
var popup = window.open(...);

setTimeout(function() {
if(!popup || popup.closed || parseInt(popup.innerWidth) == 0)
{
//POPUP BLOCKED
alert("Please disable your browser popup blocker in order to continue.");
}
}, 500);

For most browsers, !popup is sufficient. In case the popup is closed immediately, its closed property would be set to true. For Chrome, the window.open() would return an object, and so detecting its innerWidth (or innerHeight, outerWidth, outerHeight… your choice) after a timeout should work.

Here is my recommended pattern of detecting and solving popup blocker issues:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// For large applications, you probably need a name for the window to prevent multiple window for the same goal
var name_of_popup = 'new_window_123';
// This works just fine unless there is a popup blocker
var popup = window.open(..., name_of_popup, ...);

// Detect popup blocker
setTimeout(function() {
if(!popup || popup.closed || parseInt(popup.innerWidth) == 0)
{
// Close the window that is hidden behind Chrome's popup blocker
// This is useful because you can then reclaim the name of the window that is being hidden
// Without this, window.open(..., name_of_popup, ...) will be blocked because it is currently hidden by Chrome
popup && popup.close();

// This is just an example. Won't work unless you have popup() defined
// Use your own alert framework or modal plugin to allow user-initiated window.open()
popup("Please disable your browser popup blocker in order to continue. You may also " id="popup_openbox_blocked">click here to open the window.");

// Attach click event to the link
$j('#popup_openbox_blocked').click(function() {
// window.open() works here because it is initiated by an user's click action
// We prefer window.open() to the anchor's href action because we want to save the return reference from window.open
var new_window = window.open(..., name_of_popup, ...);
popup.close(); // Close the custom alert. Won't work unless you have popup() defined
return false;
});
}
}, 500);

Switching between box models 2011

David — Wed, 02 Mar 2011 03:18:26 +0000

Do we all hate IE because the IE box model makes more sense?

For those who don’t know and are lazy to look it up, prior to IE 6, IE used to include border and padding in its calculation of the width (and height) of a page element. This is different than the “standard” W3C box model, which defines width as only the width of the content, not including padding and border.

Box Model?

In IE 6 and 7, you have to manually enable the W3C box model by adding a doctype. IE 8 uses the standard box model by default. This makes IE more consistent with other browsers.

However, a lot people find the old IE box model more intuitive. In fact, if you set a 100px width to an element, you want it to be 100px; nothing less, nothing more. You won’t want it to appear bigger and screw your page up when there’s padding and border.

You can actually enable the IE box model on other browsers by doing this:

1
2
3
4
5
6
7
8

/* enable good-old IE box model on all divs
** add to the selector for wider adoption
*/
div {
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}

border-box means that the width (or height) is calculated border-to-border (border + padding + content width). The opposite (default) value is content-box.

Pretty cool huh?

Humm… not really. It’s only supported by IE8 (more on IE8 later), Webkit browsers (e.g. Chrome) and Mozilla browsers (e.g. Firefox). We’re missing IE6 and IE7.

Unless you don’t care about IE6 and IE7, I recommend that you don’t use border-box to switch your box model.

If you are one of the pioneers who don’t give a ____ on those bad browsers, you still need to watch out its strange behavior on IE8.

On IE8, border-box applies to width and height. It does not apply to min-width and min-height! That means if a container has a min-height, it’s going to exclude the padding and border in the calculation even if border-box is applied. The container will appear taller than expected in this case.

You can try it out on this test page: http://jsfiddle.net/XS2JF/. The one with border-box should be shorter, but they appear the same on IE8.

Conclusion: let’s not deal with box models anymore. It’s not yet 2013.

z-index misconceptions, IE bugs and fixes

David — Sat, 05 Feb 2011 03:10:52 +0000

Update (12/1/2011): Version 1.2

In the past 13 years, I have worked on numerous issues related to layering, specifically the z-index CSS property. It is one of the most misunderstood CSS properties. Surprisingly, there are not many well-written articles or tutorials on this topic.

I came across this blog post that talks about the way to fix a z-index issue. It works as it nails the key point about the parent element, but there isn’t much explanation. You can find all the misconceptions written by other readers.

To understand what z-index is, I find this to be the best beginner’s post. This post went a step further into the concept of “stacking contexts,” which is the major reason of all the bugs you would encounter.

Here are the top two misconceptions:

People say… “z-indexes are “absolute”. If an element has a high z-index, e.g. 9999, it should always stay on top of everything.”
The truth is… WRONG! An element with a z-index would stay below or above other elements in the same stacking context only! That means, if an element with a z-index 9999 that is a descendant of an element that has z-index -1 (negative one), the element is still invisible because ultimately it’s being affected by its ancestor that has a negative one z-index.
People say… “without z-indexes declared, the default should always be auto.”
The truth is… not on IE. If an element has a position CSS property other than the default “static” (i.e. absolute or relative), Internet Explorer is always implicitly giving it a 0 (zero) z-index value. When a bunch of elements with positions come together, whatever appearing later in the document structure will stay on top of elements that appear earlier in the document structure (or the DOM tree).
(A more technical way to explain this issue is that IE is creating a new stacking context on each of these elements, but it’s less easy to understand so I skip it here and stick with the implicit zero z-index explanation.)

Let’s look at an example:

z-index issue on IE

In this screenshot, the drop-down menu appears below the next gray area. While the drop-down menu has a high z-index value, the two areas (

elements) do not have any z-index values! Why the hell would elements with no z-index value cover one with high z-index value?

The bug is caused by the implied zero (0) z-index when position (position: relative in this case) is used. Because the last gray area appears later in the document, it is on top of the second last gray area, even though they have have an implied z-index value of 0. The drop-down menu is a descendant of the parent gray area that has 0 z-index value, so it is eventually covered by the last gray area.

To fix it, you can simply hardcode z-index:1 (or any value greater than 0) to the gray area that contains the drop-down menu, and make sure the bottom gray area has 0 z-index (or no z-index).

In a complex web app or any component-based web design, however, this may not be desired. If you care about the new best practice of object-oriented CSS, you should not hardcode CSS inline, and you should never target a specific instance of the generic CSS class to have a special CSS value.

Because of the reasons above, and maybe you are just lazy to find out what container to apply additional z-index, you can apply this z-index fixer jQuery plugin that I wrote for these issues. What it does is that given a jQuery object, it would go up the DOM to check if any of its ancestors is relatively positioned. Then it adds a high z-index to it to make sure that the the whole family line has high z-index values.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

/* Fixes z-index issues - Version 1.2
Update v1.2 - fixed an issue when this is being called on an element that is not in the DOM tree.

This plugin fixes z-index issues typically occur in IE. It traverses up the DOM to make sure that all the ancestors of the target element have a high z-index value.

This fixes a common z-index issue that an element with high z-index is showing underneath its ancestor's sibling that has the same explicit or implicit (e.g. IE's implied zero z-index when position: relative is applied) z-index as the corresponding ancestor.
For IE 6's z-index issues with input boxes, see the jQuery bgiframe plugin.

www.davidtong.me/z-index-misconceptions-bugs-fixes/

param obj:
recursive: boolean (default: true) - set to false to reduce the number of loops and if it still works, go for false
exclude: string - a list of class names to be excluded in the fix
msieOnly: boolean (default: false) - set to true to only apply the fix to IE browsers
zIndex: string (default: '9999') - a big number that should just be high enough to make the element-to-be-fixed stay on top of other elements
*/
(function($) {
$.fn.fixZIndex = function(params) {
params = params || {};
if (params.msieOnly && !$.browser.msie) return this;
var num_of_jobj = this.length;
for (var i = num_of_jobj; i--;) {
var curr_element = this[i];
var config_recursive = params.recursive || true;
var config_exclude = params.exclude || null;
while (curr_element != document.body) {
if (!$(curr_element).hasClass(config_exclude) && ($(curr_element).css('position') == 'relative' || $(curr_element).css('position') == 'absolute')) {
if ($.data(curr_element, 'zIndex') == undefined) {
$.data(curr_element, 'zIndex', curr_element.style.zIndex || '-1');
}
curr_element.style.zIndex = params.zIndex || '9999';
}
curr_element = curr_element.parentNode;
if (!config_recursive) break;
}
}
return this;
};

// optional function to restore z-index if needed
$.fn.restoreZIndex = function(params) {
params = params || {};
if (params.msieOnly && !$.browser.msie) return this;
var num_of_jobj = this.length;
for (var i = num_of_jobj; i--;) {
var curr_element = this[i];
var config_exclude = params.exclude || null;
while (curr_element && curr_element != document.body) {
var currZIndex = $.data(curr_element, 'zIndex');
if (currZIndex > -1 && !$(curr_element).hasClass(config_exclude)) {
curr_element.style.zIndex = currZIndex;
$.removeData(curr_element, 'zIndex');
}
else if (currZIndex == -1) {
curr_element.style.zIndex = '';
}
curr_element = curr_element.parentNode;
}
}
return this;
};
})(jQuery);

Example:

1 2	// .inner_div is covered by other page elements. Use fixZIndex plugin to fix. $('.inner_div').fixZIndex({recursive: true, msieOnly: true, zIndex: 15, exclude: '.page_container'});

// When we hide .inner_div, restore z-index (optional)
$(‘.inner_div’).restoreZIndex();

Using IE (6, 7 or 8), and open the demo page or see the iframe below. Uncomment the last line in the JavaScript portion to enable the fix.

Note that this plugin does not solve IE6′s bug that form elements always stay on top of other page elements. The solution for that particular bug is at http://brandonaaron.net/code/bgiframe/docs/

Thanks Zak Stein and Adam Platti’s suggestions to put this plugin to work.

Code Standards & Best Practices

David — Tue, 25 Jan 2011 00:34:01 +0000

This is the code standards doc that my previous team at Isobar/ Molecular created in early 2010. It was wildly circulated since its release. The doc contains a lot of knowledge that we have gathered in our combined 100+ years of web experience. You may find it useful if you are curious what best practices that third-party agencies are following.

http://na.isobar.com/standards/

IE8 Developer Tools won’t open

David — Sat, 15 Jan 2011 00:21:44 +0000

This may sound stupid, but I ran into this issue that upon pressing F12 or choosing Tools > Developer Tools, the IE Developer Tools window does not show up. It is, however, showing up in the task bar.

The issue is that when you have Developer Tools detached from the browser window, and you don’t close it before exiting the browser, the next time you open IE8 and try to run Developer Tools, the Developer Tools window will be an ‘invisible state’ (simply put…).

The solution is to right-click on the tab/ icon in your Windows task bar and choose Maximize. If there is no such option in Windows 7, hover on the tab/ icon in the task bar for a moment until an overlay pops up that shows all the IE8 instances and the Developer Tools representation view, right-click on the Developer Tools’ representation view and choose Maximize. Alternatively, you may do Alt+Spacebar, then hit ‘m’ and start using your arrow keys to move the window around. You will then be glad to see your long-lost friend!

It sounds stupid, but this is still a kind of IE bug.

Javascript shorthand for string comparison

David — Fri, 17 Dec 2010 02:10:14 +0000

I’ve decided to write a short article just to keep up the momentum.

Very often, we do something like this:

1
2
3
4

var string1 = document.getElementById("textbox1").value;
if (string1 == "test" or string1 == "staging" or string1 == "dev" or string1 == "internal" or string1 == "beta") {
document.getElementById("banner").innerHTML = "This app is not the live app!";
}

The string comparison part is just tedious.

Try to do this instead

1	({test:1, staging:1, dev:1, internal:1, beta:1})[string1]

and so the demo block becomes

1
2
3
4

var string1 = document.getElementById("textbox1").value;
if (({test:1, staging:1, dev:1, internal:1, beta:1})[string1]) {
document.getElementById("banner").innerHTML = "This app is not the live app!";
}

Very neat huh? If the string matches one of those in the associative array, it will return 1, and else undefined. If you want to go even more fancy, try out the operator ‘in’:

1
2
3
4

var string1 = document.getElementById("textbox1").value;
if ((string1 in {test:1, staging:1, dev:1, internal:1, beta:1})) {
document.getElementById("banner").innerHTML = "This app is not the live app!";
}

Or even this…

1	document.getElementById("banner").innerHTML = document.getElementById("textbox1").value in {test:1, staging:1, dev:1, internal:1, beta:1} ? "This app is not the live app!" : "";

What other rarely-used shorthands can you come up with?

Attaching events to disabled input elements

David — Tue, 02 Nov 2010 02:56:44 +0000

I encountered an issue that all the attached mouseover and mouseevent events on a disabled checkbox failed to work. After verifying the issue from a few references, I confirmed that this is an expected behavior of a disabled form element (button, input, optgroup, option, select or textarea).

Many argued that if a form element is disabled, it should not trigger any event. However, for various reasons, I just need it to trigger certain events.

For example, I may want a tooltip to appear when you hover on a disabled field to explain why the field is disabled. This requires a mouseover element to be triggered upon mouseover.

My specific problem is a special one. The checkbox is in a drop-down menu, which disappears when the mouse cursor is moved outside of the menu area (via a mouseout event on the menu). However, when you hover on the checkbox, it is considered a mouseout event of the menu, and so the menu would disappear. One way to fix that is to set a variable (bHoverMenu) to true when you hover on the checkbox. The mouseout event of the menu does a brief time out to allow sufficient time for the checkbox’s mouseover event to set the value of the variable bHoverMenu. Eventually, the mouseout event of the menu checks for the variable bHoverMenu to determine if the menu needs to be closed. Obviously, there needs to be a mouseover event on the checkbox in order to set bHoverMenu to avoid falsely closing the menu.

Long story short, I just need events to function on my disabled form elements.

After some research, I found a solution from Dan G. Switzer, II. Basically, the solution is to “add an overlay over the disabled element which I’d use as the hotspot for mouse interaction. The overlay lays on top of the element and intercepts all mouse interaction.” This is a very neat solution, but I want a slightly simpler solution that requires less code and perhaps does less DOM manipulation if that’s possible.

readonly vs disabled

I then looked up the list of attributes that a form element takes, and noticed that “readonly” may be of use. Instead of using the “disabled” attribute, we can actually use “readonly”, which does not disable any events attached to the element.

However, “readonly” merely prevents users from changing the value of a form element, not from interacting with it, and so you can still alter the “checked” attribute of a checkbox even if “readonly” is set. I found another article that explains more about the differences between these two attributes.

To fix this issue, we only need to make sure that when the readonly attribute is set, the checkbox is always unchecked. The following piece of code in jQuery will do the job:

1
2
3

$('input').click(function(e) {
if (this.readOnly) $(this).attr('checked', false);
});

1	<input readonly="readonly" type="checkbox" />

And if your input element is wrapped by a label or some other container (such as a LI), you may do this

1
2
3
4

$('.wrapperClass').click(function(e) {
var input = $(this).find('input');
if (input[0].readOnly) $(input).attr('checked', false);
});

I think this is pretty compact and sweet. Similar code can be applied to other form fields with just a little adjustment.

Bonus: In Chrome, a disable checkbox looks exactly like a checkbox that is read-only. This is not true for all browsers, and it requires some styling to make it grey-out. In my opinion, this isn’t a critical issue as long as you have a label indicating the field is disabled and you have the code (from above) that disables any interaction on the checkbox.