Take it with the usual grain of salt that should accompany any news of global browser trends, but, extrapolating out from the 2011 trend in StatCounter's Global Stats Chrome appears set to surpass IE as the most-used desktop browser some time next summer. And that will finally end the 13 year domination of the market by Internet Explorer.

Though, I'm a little sad that Chrome's market share is also coming at the expense of Firefox.

It started with an idle perusal of recent Flickr photos from my contacts. Jeremy Keith is currently in Chicago for DrupalCon, and after a page of tantalizing food and architectural photos, I found myself back in Brighton looking at his photos from a laboratory-related exhibit at the Lighthouse Gallery.

One especially mundane photo in particular caught my eye, his capture of a placard on a fruit fly breeding chamber. In particular what I noticed was the usage of the Latin genus name drosophila.

I'm quite familiar with the word because Dr. Gordon Tener -- my grandmother's brother and a father figure to my own dad -- had a long career as a professor of biochemistry at the University of British Columbia here in Vancouver. During his tenure he researched, among other things, ribonucleic acid (RNA) and the genetic organization of drosophila melanogaster, otherwise known as the common fruit fly.

Dr. Tener died two years ago, and as I was looking at Jeremy's photo I realized that I may never have punched his name into Google to see what the internet knew about his life and achievements. So I did, and eventually I stumbled across a Blogger site set up to document the extended family history of the Tener family.

The top of the site references something called the Tener Book, which was a genealogy published in the fifties that I'd never heard of. And what do you know, there on page 79 are references to Dr. Tener and my grandmother, which means this book is about my family history, back 20 generations through nine centuries and five countries, complete with photos of various great-great-great-great grand-relatives and a family crest I didn't know about.

All from a photo of a fruit fly breeding chamber.

It's easy to take for granted just how much information we have at our fingertips these days, but then mind-blowingly personal discoveries like this come along every now and then and put it all in sharp focus. The internet is amazing.

I've decided to slap a Creative Commons license on the entire darn Chalkwork Family and make them completely free for personal use, starting right now.

I've been considering doing this for quite a while. These icons represent a lot of hard work for me between 2006 and 2009, so you can imagine I've thought through the implications of making them available for free download without a pay barrier: will people use them commercially and not pay? Will they abuse the license terms? Will some redistribute them elsewhere? Will they modify them and claim them as their own?

The answer to each of those questions is, inevitably, yes. I've been on the web long enough to know that no matter what you intend to happen, someone will always find a way to do the complete opposite of that sooner or later. But you know what? I can live with that.

I'm of the opinion that DRM and increasingly consumer-hostile content protection laws are kludgy ways of protecting outdated business models. By offering a product for download, I've effectively been treating the pay barrier as a form of copy-protection all along. Which has worked well enough for my purposes, but if I'm being honest with myself I don't think I really need that protection.

People who appreciate your work do the right thing. Just as those who download music are more inclined to buy it, my bet is that those who download these icons for personal use may one day come back and pay for commercial use. If they don't, were they ever likely to buy them in the first place? I doubt it.

It's not all philosophy and rhetoric, I'm genuinely curious to see what happens next with the commercial sales since they've been on a steady decline over the years. I tried an AdWords campaign for a while, but that didn't do much to reverse the trend. Will opening them up under a free license provide an extra boost? Maybe, but then maybe I just killed all future sales. Hard to say.

Most of the money I was ever going to make happened at the beginning, the long tail isn't proving that profitable. Sales over the years have at least paid for the time I spent creating the family so I'm happy with the overall return, but there's clearly not much left to lose now so I'm willing to experiment a little.

Share and enjoy.

Note: if you're having trouble downloading the full files, it's not just you. Downloads appear to be getting cut off halfway through. Lots of data transfer is making weird things happen; I'm looking into it.

But where Boilerplate focuses on basic document setup, external files, scripts, and bug fixes, it strikes me that it doesn't do much hand-holding when it comes to basic document semantic patterns. As I've been working more and more HTML5 into my projects, I'm noticing a common template emerging.

I'm sharing this as a minimum viable starting point since I'm still getting comfortable with the new semantics myself. Combined with Boilerplate, I'm feeling more and more confident that I'm beginning to use HTML5 properly. Don't consider it canonical by any means, there's likely a lot of room for improvement and it's most certainly wrong in places. Comments / suggestions for improvement are more than welcome.

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>pageTitle</title>
  <link rel="stylesheet" href="default.css">
  <script src="default.js"></script>
</head>
<body>


<div id="accessibility">
  <a href="#nav">Skip to Navigation</a> |
  <a href="#main-content">Skip to Content</a>
</div>


<header role="banner">
  <div class="masthead">
    <a href="#"> ....site title or logo, purposely not an h1.... </a>
  </div>
  <nav id="nav">
    <ul>
      <li><a href="#">
        ....main site nav list....
      </a></li>
    </ul>
  </nav>
  <div id="secondary-nav">
    <ul>
      <li><a href="#">
        ....other non-primary navigation doesn't belong in a nav element....
      </a></li>
    </ul>
  </div>
</header>


<section id="main-content" role="main">
  <h1> ....page title here.... </h1>
  <article>
    <header>
      <h2>....article heading if needed....</h2>
      <h3>....article sub-heading if needed....</h3>
    </header>
    ....article content here....
  </article>
  <article>
    ....use more article elements if appropriate; if not, I still use divs....
  </article>
</section>


<aside id="sidebar">
   ....site sidebar here....
</aside>


<footer>
  .... footer content here ....
</footer>


</body>
</html>

You'll notice I'm a believer in reserving h1 headings for the page title, and not the site / company name. I'm still not sure I get how to use the revised heading order so I'm sticking with old school h1-h6 for now.

Thanks to the pave the cowpaths philosophy that guided HTML5 development, it feels almost too easy. It's not much more than a tweak to my previous XHTML template: change a few ids to their corresponding elements here and there, replace various divs with sections, articles and asides where relevant, and add / remove extra attributes where necessary. Done.

It's basically a set of image filters that render in the browser. Greyscale, sharpening gaussian blur and more on the web, no ImageMagick or GD required. It allows you to take an image like this:

And using a simple class and a couple of HTML5 data-* attributes, render it in a number of different ways:

I skipped the jQuery and went full Javascript on this one, but it ought to play nice alongside most other Javascript libraries out there. More on how to use it, and there's a real-time demo page you can play around with. (works best in Safari and Chrome, thanks to their speedy Javascript engines and support for the HTML5 range form input)

Since I'm using canvas to pull this off I'm automatically excluding IE8 and lower from the equation (it works great in the IE9 beta), which meant that I could also save out the images as dataURLs. The upshot? You can use the output images the same way you would any other image within a web page; as a CSS background, as source for a canvas animation, and if you really want, you can even Right Click -> Save As to save the filtered image to your hard drive.

(And this blog template is really starting to show its age. In a fit of irony worthy of an entire extra verse by Alanis, I had to pre-render the effects above and save them as separate images instead of showing them rendering realtime, because the HTML5-friendly PaintbrushJS doesn't play nice with an XHTML doctype.)

All browsers that support the CSS text-shadow and box-shadow properties also support the new CSS3 RGBa syntax. Which means you can safely combine them today.

That's handy, because it means no worrying about matching a precise hex colour shadow to a specific hex colour background. Instead just let the browser blend. An example:

p {
  text-shadow: rgba(0, 0, 0, 0.2) 0 1px 0;
}

That will produce a paragraph with a 20% opacity black drop shadow that will blend into any background colour below it. A paragraph like this one.

Previously I might have created the drop shadow in Photoshop, then used the eye dropper tool to pull out the composited shadow hex value after the transparency was applied to the background colour. No more!

Over the past few months I've been collaborating with Chris Glass on the newly-launched Joyent site. (When someone comes to you and says, hey, we have Chris Glass helping us out with this project and we'd like the two of you to work together, you jump at that chance.)

I was tossing around ideas for building an interactive infographic Chris had designed, and thought of at least four different ways of pulling it off. We're reaching this interesting point with front end web technology where we now have actual choices besides Flash for jobs like this. I considered CSS3 animations and the Canvas element before ultimately deciding on PNGs with alpha transparency and jQuery transitions and fades.

I put off browser testing as long as I could, but just this week prior to launch I realized it was very broken in all versions of Internet Explorer. I had a plan to back out to a static graphic in IE6, assuming IE7 and IE8 would treat the PNG + animation combo like any other reasonably modern browser. I was wrong.

It seems that IE's implementation of PNGs with alpha transparency is still buggy or incomplete in some way. When you place a PNG with alpha on a static page, you'll never be the wiser. It's when you adjust the opacity of that PNG that you run into problems. Take the following example:

I'm overlaying this slightly-transparent image of three triangles atop a few different backgrounds. So far so good. IE7 and IE8 keep up. But if I apply further transparency to the image in the form of a jQuery fadeIn or an opacity value, things go a little haywire:

That's the same setup as before, only with an opacity value of 0.99 (almost completely opaque) applied to each img element. In non-IE browsers, the previous two examples ought to look the same. In IE7 and IE8 on the other hand, the previous example instead looks like this next one:

Of course, no version of IE supports the CSS opacity property yet, so jQuery instead applies the opacity by exploiting the IE-proprietary AlphaImageLoader filter. This ends up being the root cause of the (seemingly well-known) bug. The suggested fix is to apply the transparency to the parent element instead, but I've had little success with that workaround.

What did work was a little library called DD_belatedPNG that applies PNG transparency via VML instead of AlphaImageLoader. It's designed for IE6, but it works just fine in IE7 as well. For IE8, I was forced to throw out an X-UA-Compatible meta tag and step IE8 down to IE7 mode for this particular page.

It's still not perfect. I noticed a faint white bounding box poking through at lower opacities that forced me to slightly adjust hover effects for all versions of IE. But you know, for all that, it's darn well good enough.

Let's be honest; Photoshop is absolutely terrible at saving transparent PNGs for web use. Your choices are between an 8-bit with 1-bit transparency (better than a GIF in terms of file size, but no better in terms of transparency options) or a huge 32-bit PNG with alpha transparency. There's no middle ground. You can run the resulting files through various PNG reduction utilities (PNGOUT, Pngcrush, or my personal favourite PngThing) but when the savings are a few hundred bytes off an 80KB file, the returns are slim.

I'm not in the practice of using Fireworks, so those of you who do can start gloating now. But as I thought about the problem a bit, I remembered that Fireworks has a few more options. Specifically, I remembered that you can save out 8-bit PNGs with alpha transparency, which seemed like the right mix.

And the resulting lower byte counts were respectable: 95KB › 11.7KB. 28KB › 4.6KB. 38KB › 8.9KB. 36KB › 7.1KB. 45KB › 7.3KB. 28KB › 4.7KB. etc.

When I casually mentioned the smaller files I was able to produce on Twitter I was a little surprised by the response. Seems that a lot of people don't know about this, so a quick write-up feels like it's in order. Here's my process.

1. Save out a full 32bit PNG from Photoshop

Any file format with transparency will do really. You could probably even just open the PSD. But I start here.

2. Load it into Fireworks.

3. In the Optimize palette, adjust the settings to PNG 8.

You'll probably want to go further and find a colour level less than 256 that works with your image for more savings, but this is the starting point anyway.

Figure: an image open in Fireworks with the Optimize panel shown, adjusted to PNG 8, 32 colours, with Alpha Transparency selected.

4.Export.

File > Export, then pick a spot for your smaller file.

And that's basically it. Clearly this only works for images that would normally do well with lower colour levels, you won't be using this for photographic elements any time soon. But for those that work, you can throw the result through one of the previously-mentioned optimization tools to shave off a few more bytes too.

SVG has been around for ages, whereas Canvas is still relatively new. (Mozilla's Vladimir Vukićević has a good overview presentation of the differences between the two, and when and where to use each.) SVG support is built into plenty of graphic editing tools; Canvas support is so far sadly lacking, although Matt May pointed me to this YouTube video that shows off the upcoming Canvas support Adobe's CS5 suite will have, whenever it becomes available.

In the meantime, most of the Canvas demos we've seen thus far have mostly featured simple primitive shapes like lines and ellipses for good reason: it's too hard to build up a reasonably complex vector image by manually plotting bezier curves.

Over the past few days I've tried out various ways to get around this problem. I came up with two methods of taking vector shapes out of Illustrator and rendering them with Canvas, both involving an intermediate step as SVG first.

So to start, from Illustrator (or any other vector editing application capable of doing so) export your artwork to SVG. You'll find the SVG option in the Save As / Save a Copy dialog, and I've found the SVG profile you choose doesn't really make much of a difference (though for the sake of argument I've been using 1.1).

We'll use this happy little cloud image as our reference file:

1) Manually

This method is only theoretical so if you're looking for the actual how-to, skip ahead to #2. I figure it might be worth writing this up anyway because, even though I couldn't get it working, perhaps it'll provide enough of a starting point for someone else to pick up where I left off and build a proper converter.

SVG and Canvas are both essentially vector drawing tools; Canvas is more pixel-oriented, but you are certainly able to plot lines and curves mathematically. Canvas is also limited to fewer primitive shapes, but there are obvious parallels between the two.

I spent a bit of time looking into the bezier commands in particular. In SVG, to plot a bezier curve, you do something like this:

  <path d="C x1,y1 x2,y2 x,y" />

In Canvas, it's this instead:

  ctx.bezierCurveTo(x1,y1, x2,y2, x,y);

Different syntax, but the same basic components: you're drawing a line from the current pen position to the x, y value, and before that you have two additional points (x1, y1 and x2, y2) that set your handles. (More SVG path commands, Canvas path methods.) It's worth noting that SVG is more forgiving about commas; each coordinate must be separated by a comma for the Canvas method, but they're strictly optional in the SVG example. This is relevant because Illustrator's SVG export seems to be wildly inconsistent about when and how many commas each command uses.

Given the similarities, I thought it might be fairly straightforward to manually tweak the SVG output into Canvas drawing functions. M becomes moveTo, C becomes bezierCurveTo, and so forth.

  <path d="
    M 62.58, 31.96
    c -0.711,0 -1.811,0.062 -3.181,0.165
    c -0.566 -6.309 -5.862 -11.255 -12.318 -11.255
    c -2.363,0 -4.564,0.675 -6.442,1.824 "/>

Becomes:

  ctx.moveTo(62.58, 31.96);
  ctx.bezierCurveTo(-0.711,0,-1.811,0.062,-3.181,0.165);
  ctx.bezierCurveTo(-0.566,-6.309,-5.862,-11.255,-12.318,-11.255);
  ctx.bezierCurveTo(-2.363,0,-4.564,0.675,-6.442,1.824);

This did not work. I suspect the absolute vs. relative coordinate difference between SVG's c and C commands tripped me up, but after a half hour or so of poking around this was all I had to show for it:

Still, even if I'd have managed to get it right, I'd rather not have to manually massage my SVG output every time I want a new Canvas drawing. Which leads me to method #2.

2) Automatically

One of the main reasons I bothered to attempt a manual conversion in the first place was because after an extensive search it appeared that people are mostly interested in converting Canvas to SVG. There are very few articles and tools that cover going the other way, which is what we're after. Maybe I didn't come up with exactly the right search term, but I was finding so little I almost gave up entirely.

Then after one last shot in the dark, I managed to stumble across SVGToCanvas, a Java library that promised to do exactly what it sounds like, with a few disclaimers and a major caveat:

• You need Java 6. Otherwise known as 1.6, this comes installed with Mac OS X Snow Leopard but previous versions will need to upgrade. I believe this is the download necessary for Leopard, if you're on an even older version you're on your own. No idea what the Windows situation is, but this might be a good place to start.
• You need to run it on the command line. I know this will freak out some designers, but really, it's not terribly difficult.
• You mainly get outlines for now. This would be the big ugly caveat. Sometimes you get colour and gradients, sometimes you get mixed-up colour and gradients, mostly you don't. Plan to re-add them manually. Hopefully this will work better in a future version of the library, but still, having outlines is a solid start.

Still with me? Great, go grab the JAR file and drop it on your hard drive somewhere easy to find. For now, probably best to drop it in the same folder with the SVG files you're going to convert.

Now, load up the terminal, and find your way to the same directory. Here's a quick command line primer that ought to get you going. The cd, ls, and pwd commands in particular are the ones you need.

(If you need a bit more help than that: put the SVG and JAR files in a folder on your Desktop called 'canvas'. When you open up the terminal, type this minus quotes: 'cd ~/Desktop/canvas'. Hit return. You're good, keep reading.)

Run the converter with the following command:

  java -jar svg2canvas.jar -o cloud.html cloud.svg

From left to right: we're invoking Java with the SVGToCanvas library, then by -o cloud.html we're specifying the output will be written to cloud.html, otherwise it just displays the output in the terminal (which can be handy if you'd like to just copy and paste without managing temporary files). Then finally at the end, cloud.svg is the input SVG file that we had previously generated from Illustrator.

That generates an HTML file which contains a canvas element and the Javascript necessary to render the cloud:

In this case it worked, though it added a stroke. When it's just the outline, you can restore the colour by manually tweaking the code. Add a fillStyle method before the draw, and a fill after:

  ctx.fillStyle(#4a6481);

  ... (drawing commands here) ..

  ctx.fill();

Not too difficult for simple shapes. I'd hate to have to manually re-add the subtle gradients for more complicated illustrations, but it's nice to know the outline conversion is fairly robust:

One more thing: I'd recommend flattening the vector art as much as possible. Join shapes that can be joined, expand effects and compound paths and masks, and generally clean up the artwork to as few points as possible. Smaller file sizes, more chance of success upon conversion.

So there you go. It's still a fairly painful way to get your vector work into a canvas, but until we get some better tools or built-in support for our existing tools, it's one way to fill the gap.