Follow through on my fontready patch

I recently created a patch for Firefox that allows one to listen to the ready state of fonts loaded via @font-face.

I have some examples on it.

First to get a more visual example, I will show images as to why this is useful and needed badly inside the browser.
This is an image of a div using some custom font, and a canvas drawing some text using the same font. As you can see above, the fonts are different. What is actually happening is there is a moment where the div is also incorrectly drawn, then when the font is loaded, it gets updated. This has been coined asFOUT. The canvas never gets the update, or the FOUT, because it never knows to clear the canvas and redraw the text. One way around this is to constantly clear the canvas and redraw, and once the font it loaded, it will update, and bring along the FOUT with it. Also, you could setup an offscreen div, and measure text on it until it is not the same size as the default font, meaning your new font is most likely ready to go. Both solutions are hacks and suboptimal.

In my last post, I talk about my attempt to listen for font ready states. Given the same example above, this is now what I get on the first load:
As you can see, both fonts are the same. This is because I setup a listener for “fontready” and draw my canvas in there. This also gets rid of the FOUT. The event looks like this:

One annoyance I noticed with this is fontready and DOMContentLoaded may become a race condition if not carefully implemented, because the dom must be loaded before the canvas can be drawn to. Example of this is if the font is ready before the document, and thus the canvas is not ready, and the font loading is lost. There are ways around this, though, and is not a huge deal, just something that must be accounted for, and is quite common in web development. I solved this by creating the font inside my DOMContentLoaded event. Looked like this: