Blog

IE9 will support border-radius natively (yay!), but that still leaves all those users with an earlier version of IE in a world filled with dangerous sharp corners and no relief in sight. There are a ludicrous number of different scripts that have been created to try to solve this problem, but each and every one has one (or often several) of these fatal flaws:

1. Requires style information to be resupplied in JavaScript
2. Generates a huge number of DOM elements
3. Creates corners that are not anti-aliased
4. Unmaintainable, unreadable, or just plain bad code
5. Inadequate documentation
6. Requires additional plugins or images
7. Breaks support for background-image/background-repeat
8. Breaks direct descendant selectors
9. Breaks in IE8
10. Causes severe memory leaks due to circular references

So, I decided to come up with something better. RoundRect is a new, MIT licensed library (based loosely on the DD_roundies 0.0.2a source) that uses VML to provide a zero-configuration, nearly-fully-featured implementation of border-radius in IE. It still has some rough edges and comes with its own list of caveats (check the link for more info), but it does more, works better, and is better written than any other library that I’ve come across for creating round rectangles in IE. Check it out!

Update 2011-03-01: Use CSS3 PIE unless you have very specific requirements.

A major issue with large web applications is the difficulty in generating meaningful error reports for problems that occur on end-users’ machines. While debugging web apps during development has become exceedingly easy thanks to the great developer tools that Web browser manufacturers provide (and Firebug ;)), the task of automatically retrieving a stack trace from a remote machine is still painfully elusive.

Today, I’ve finished initial work on a small project that I am already using on an upcoming application to help alleviate this problem; I hope that it can help you too. Based on the hard work of Andrey Tarantsov, TraceKit is a JavaScript library that automatically normalizes and exposes stack traces for unhandled exceptions across the 5 major browsers: IE, Firefox, Chrome, Safari, and Opera.

TraceKit leverages native browser support for retrieving stack traces from Error objects where available, and squeezes out as much useful information as possible from browsers that don’t. It integrates neatly with jQuery, automatically wrapping all of your event handlers and AJAX callbacks so that you get the most useful stack information possible across the widest range of browsers without needing to tediously wrap everything yourself.

Finally, it attempts to extend support for column-level granularity of the top-most frame to all browsers, in order to allow you to debug even minified JavaScript. This does not work perfectly, and won’t until all browser manufacturers are exposing good stack trace information, but it ought to be more useful than nothing.

At under 8kB minified, and 3kB minified + gzipped, TraceKit should be suitable for any project that needs to be able to send back stack traces for error reporting and analysis. The best software is software that doesn’t generate any unhandled exceptions; I hope TraceKit helps you achieve that goal.

Get TraceKit on GitHub

I have been spending some time in jQuery chat lately, and something that comes up fairly often is the desire to repeat an action every n milliseconds. “No problem”, many will say. “Just use setInterval.” I consider this to be terrible advice.

Reason #1: setInterval ignores errors.

setInterval has a nasty habit of not paying any attention to whether or not the code it calls generates errors. This means that if, for some reason, an error occurs in part of the code that is called by setInterval, it will continue to call that code over and over again. Demo

Reason #2: setInterval does not care about network latency.

Let’s say you are polling a remote server for any new data on a fixed interval using AJAX. (Note: If you are doing this, you are probably doing it wrong; use backoff polling instead.) For some reason (server overload, temporary network connectivity loss, Slashdot effect, satellite/dial-up user, whatever), these requests are taking longer to complete than you thought they would. setInterval doesn’t care. It will continue firing those requests off, over and over again, until your client’s network queue is filled up with AJAX calls. Demo

Reason #3: setInterval does not guarantee execution.

Unlike setTimeout, there is no guarantee that an interval will actually execute when you ask it to. If the function you call on an interval takes too long to complete, some invocations will simply end up being dropped. Demo

The solution is simple: setTimeout

Instead of using setInterval, make the function call itself using setTimeout at an appropriate moment. In both of the above demos, function a does it wrong using setInterval, and function b does it more properly with setTimeout.

But what if I absolutely need the event to occur at the same interval every time?

If you want to ensure that your events are occurring on an ‘even’ interval, you can calculate the difference between your intended delay and the amount of time the last call took to complete and adjust your setTimeout delay appropriately. It is important to note, however, that JavaScript timers are not high-precision. You will never ever get absolutely even intervals, even if you use setInterval, for a variety of reasons (garbage collectors, the fact that JavaScript is single-threaded, solar flares, etc.). In addition, all current browsers will clamp the minimum timeout value to somewhere between 4ms and 15ms. So don’t worry too much about the difference!

Update 2011-03-01: I added the 3rd reason I inadvertently omitted from the original article.

UPDATE, 2011-06-21: The code formerly hosted here has been upgraded and moved to a GitHub repository.

ECMAScript revision 5 adds native support for ISO-8601 dates in the Date.parse method, but many browsers currently on the market (Safari 4, Chrome 4, IE 6-8) do not support it. Today, I wrote a simple duck punching replacement for Date.parse that will provide support for ISO-8601 strings if the native browser does not.

n.b. yes, I am aware that there are at least two other implementations of this on the Web; they are not nearly as efficient, they do not support all dates that ES5 supports, and they do not provide seamless support via the native Date.parse method.

YuMeWrapper is an ActionScript 3 wrapper around YuMe Network’s library SWF for publishers. It provides a consistent abstraction of their ActionScript 3 SDK, as well as much more thorough documentation of the YuMe SDK than what YuMe themselves provide.

This wrapper supports all of the standard YuMe library functionality, including pre-roll, mid-roll, overlay, and post-roll advertisements, with two exceptions: midroll playlist prefetching is not supported, and extra fullscreen options are not supported. It also provides loads of additional fixes and functionality that does not exist in the YuMe library core.

Get more information and download YuMeWrapper