Claws, fangs, fur...

What would you expect when you see this javascript?

/* assume context is an HTML5 Canvas 2d context */
var g = context.createLinearGradient(0,0,width,height);
g.addColorStop(0,'hsl(0,0%,0%)');
g.addColorStop(1,'hsl(0,100%,100%)');
return g;

Would you expect a gradient flowing from black to white, with grades of red in the middle? Me too!

For a yet unknown reason, all tested Canvas-supporting browsers decided to show only shades of grey. No red.

In order to see red, we actually need to add a specific colour stop between the two already present:

var g = context.createLinearGradient(0,0,width,height);
g.addColorStop(0,'hsl(0,0%,0%)');
g.addColorStop(0.5,'hsl(0,50%,50%)');
g.addColorStop(1,'hsl(0,100%,100%)');
return g;

But that, obviously, fails to show a fully saturated red anywhere in the gradient.

On a slightly related topic: why we need to pass the hsl() (or the rgb()) colour creator as a string beats me. Why not just add an hsl() function to your javascript parser? Only because javascript refuses to accept 0% and 100% as numbers? Well, then let us specify those as fractions between 0 and 1, just like alpha transparancy.

But no... that would make the notation inconsistent with the CSS3 notation... and we all know that the CSS3 colour module has been a fixed recommendation for years, right?

Not.

Ah, the virtues of Canvas. Get me talking.

Or rather, don't. I've been busting my ass the past couple days to get the save and print functions to work in my Canvas Composition Studio, the very first implementation of the Canvas element of its kind in the entirety of the internet. The new ones, that is, not the ones you will find in the application as we speak.

I learned many a new thing trying to get these functions to work. That's why I love programming: I keep on learning. Every day is a surprise.

A listing:

1. When opening a url using javascript:window.open(), some browser implementations (Opera, Firefox, Chrome) don't wait for the new window to finish loading before returning to resume the programming logic. This race condition is particularly tricky if you want to use that new window and its contents. When is it loaded? Not all browsers implement a ready-state. Do I wait? How long do I wait? Can I safely assume the new url will be loaded within my waiting time? So I had to turn the logic around and work with a call-back method, a pattern I already use heavily in the rest of that application. I prefer call-back methods over 'regular' ajax, whenever I control both the caller and the called.

2. Opera 10 doesn't like to print data:uris. Firefox and Chrome lack that problem. It took Opera a good 5 minutes to spool a 60KB data:uri. A bug report was filed.

3. Google Chrome thinks a data:uri is a violation of cross-domain access security. Since 'data:something...' does not equal 'http://www.someth.ing/', Chrome thinks the two stem from different domains. Try manipulating that in iframes, ajax, and other similar constructions.

4. Most browser implementations (Opera, Firefox, Google Chrome, Internet Explorer) do provide a print method that is accessible by javascript, but not a save method. (In this case it doesn't matter for Internet Explorer since it doesn't support Canvas.toDataURI(), since it doesn't support Canvas, but it's the principle that counts). So why the one, but not the other?

5. When the canvas image you wish to print can be given different background colours, instead of attributing those colours to a style setting, draw them using Canvas drawing techniques. Why? Because whether or not the background colour gets printed, in most browsers depends on a user setting. In some browsers this setting is hard to find. In Opera 10, if the background colour is omitted, and the base canvas picture happens to contain an alpha transparent gradient, you will find most of the picture shows up posterized white and black. A bug report was filed.

I'll be working on Canvas implementations for a while. I'm looking forward to get my hands on the 3D-context.

Hallvord R. M. Steen just published a blog post on his blog 'Miscoded' about how browser sniffing breaks in Opera 10, because web developers didn't think past the 1st digit.

I thought: hey, I don't use browser sniffing except for detecting MSIE, and then let MSIE do the detection itself using conditional comments. Instead, I use feature detection. My scripts should be fine.

Right?

Wrong.

In the Canvas application we discussed a few weeks ago, and in every other javascript-heavy application we produce, feature detection determines what a browser can and can't do. Almost anything is checked before using it. Including the ability of the browser to create an HTMLCanvasElement.

MSIE doesn't support the Canvas functionality yet. Not even in version 8 beta 2. The competition, obviously, does, for better and for worse. Some browsers have an awful implementation. Maybe MS thinks it's better to wait with publishing their Canvas support until their development nears perfection.

So, MSIE doesn't support the Canvas element. As a result, what do I expect from the execution of the following in MSIE?
var c = document.createElement('canvas');

I expect an 'undefined', or a false, or a null. Anything except an HTMLCanvasElement.

Guess what MSIE 8b2 does?

No, I said: Guess.

Well, OK, I'll spill the beans. MSIE 8b2 creates a new HTMLCanvasElement. It doesn't have Canvas support, but it will still create the element. So here we are, with an HTMLCanvasElement, but without a context, or any predefined properties, apart from it being an element node.

Our feature detection was based on the ability of the browser to create the HTMLCanvasElement. We assumed that any browser that doesn't support the Canvas functionality, would also refuse to create that element. We would detect that, and hand it an image element instead. We were wrong.

Now we have to switch our detection to something else. Like the ability to get a 2d-context. Oh wait... we did that already, which is why our scripts didn't break anywhere. We just ended up with emptiness where an image should have appeared.

Thank you, Microsoft. Not.

The past couple of months I've been working at programming a game community web site. One of the applications we include is an altar dress-up, much like a doll dress-up and comparable to the house dress-up at Gaia Online's. We've decided to build this using Canvas, one of the new html5 elements.

Just to piss off the Internet Explorer users? Microsoft's excuse for a browser still does not include canvas support, not even in version 8 beta 2.

No... we are looking forward to Microsoft implementing some version of the canvas element in the near future. We expect they have about 1 year, before the rest of the world passes them by and leaves them behind. Currently, all competitive browsers have versions available that include canvas support to some extent. Competitive... that means Opera, Chrome, Safari, and Firefox (and other Gecko derivatives), ranged from least to most used.

Luckily for us, just in case Microsoft will choose to bereft their unfortunate audience from the powerful abilities of the canvas element, we've ensured our altar dress-up application will do bitmap images too.

Just because we're nice that way.

Unfortunately for us, the quality of the canvas implementations of the browsers mentioned leaves much to be desired. From what we've seen, Opera's implementation is best, and Chrome's is worst. Chrome fails at radial gradients and serialisations, Safari fails at patterns (turning the source image upside down), and everything looks a bit blurry in Firefox. All of them except Opera have problems with arcTo(). Opera also is the only one that currently can output the canvas resulting image and save it to a PNG image. On the downside, Opera has a problem with showing the outer lines of a radial gradient at the desired opacity level, making for jagged edges, and leaves ghost trails of outlines upon resizing outlined elements.

For some reason, we have a problem resizing our canvas elements. The html5 working draft stipulates that the drawing must be redrawn after resizing the canvas... but for some reason, all of the browsers set a limitation of 300 by 150 pixels. The element does get larger... but the drawing is cut off. Very weird, as the drawings themselves are vectors and theoretically scale to any size. Very weird too, as the backdrop on our application is another canvas element, also resized, much larger than 300 by 150 pixels, and has no problem displaying a linear gradient on its entire surface. So that leaves us with a puzzle to solve.

The biggest problem with this application is not the canvas... but the keyboard events used to move elements around on top of the canvas. We know we can use javascript to capture the keyPress, keyDown and keyUp events, and it works pretty decently after figuring out the browser differences and how to start the capture unobtrusively.

The problematic part is stopping the browser from executing their own browser functions after capturing a key combination. Who'd have thunk that Firefox would switch tabs ctrl+page-up? Who'd have thunk that some screen applications rotate the screen on ctrl+alt+arrow? It seems cancelling the original browser functionality seems to work in Opera only... only it works too ambitiously, also cancelling the combinations I chose not to cancel at all, like ctrl+r. It's yet another puzzle to solve.

And this is why we found it safe to start out using the canvas element: it may take a long time for us to figure it all out, and by that time, the specification will be ready and the browsers will have caught up. Well, all of them except Internet Explorer. Shrugs. Not my fault.

One thing I am looking forward to, and may even build myself, is a digitizer application, that allows a user to load any image, then go around clicking from one point to the next, tracing its outlines, and having those points converted to a canvas drawing instruction automatically. That'd increase the amount of available canvas drawings dramatically. That's right: it's my idea, and you heard it here, first.

Other things I predict to see pop up within a year: converter applications that convert Blend, Director, Expression, Flash, GL, Illustrator, Postscript, SVG, V(R)ML, WMF, and WML images to Canvas. From vector to vector. Not that difficult. Just a lot of work to account for all variations.

These are exciting times, opening the internet to a whole load of better looking applications.