In the meantime, I’ve been carefully watching WebKit creep closer and closer to implementing the W3C File API (Go Kinuko!). Something I’ve been eagerly waiting for more browsers to do so you can open up local files in SVG-edit.

And then it hit me.

Why not a comic book reader done directly in the browser?

In case you don’t know, comic book archive files are just ZIP or RAR files containing JPEG images. Browsers can handle images. Some browsers can now handle opening local files. Even binary ones. So theoretically you could write unzip/unrar in pure JavaScript, extract the JPEGs, turn them into data: URIs and shove them into an <image> element. You can even do the unzipping in a separate thread using Web Workers.

Theoretically.

kthoom was how far I was able to get in a weekend.

Some limitations:

• Unzipping is slow. None of the code has been optimized yet and I’m probably doing a lot of really stupid things.
• Only supports CBZ files, not CBR files at the moment – I am accepting patches
• Unzipping is really slow. I need to provide visual progress reporting from the Web Worker thread, I know.
• kthoom will crash Firefox 3.6 about half the time. Firefox nightly (3.7) seems to handle it just fine. I opened this bug.
• Did I mention that unzipping is slow?

If I’m honest, this was really an exercise to see just how easy/hard it would be to do something like this in the browser – and to get some hands-on experience with Web Workers. And hey, I’m not the first or even second person to think of doing unzip/deflate in JavaScript either.

It was my first experience writing JavaScript to handle binary files. It was fun. It took a weekend.

Some essential tools: Firebug, a hex editor, pen & paper, a clear mind, patience.

Now swinging my attention back to stuff I should be working on…

I came up with two simple practices that I intend to follow going forward to produce readable JavaScript that minifies better:

1. Reduce Early Returns

When I’m writing code, sometimes I think of error situations after I’ve written the main body of a function. This often results in me inserting a quick early return at the top of a function:

  function foo() {
    if (garbage > 0) return;
    // rest of function here
  }


This gets the error condition “out of the way” and I don’t have to think about it anymore. However, it is usually better practice to write this as:

  function foo() {
    if (garbage == 0) {
      // rest of function here
    }
  }


Early returns are sometimes debatable, but in general they make your code harder to read (particular if your return is embedded deeper in the function than at the top in my simple example). They also have the side effect of making your code larger: that extra ‘return;’ is 7 more characters compared to the two required for the braces.

In my experiments YUI Compressor does not rewrite my code to the second example, eliminating the early return. On the other hand, the Closure Compiler does.

2. Collapsing Variable Declarations

This one is pretty straightforward. Instead of writing this:

  var x = 5;
  var y = 2;
  var z = "foo";


write this:

  var x = 5,
      y = 2,
      z = "foo";


It looks just as readable and reduces the extra ‘var’ characters.

Again, as with the first case, YUI did not reduce my code while Closure Compiler did.

What Else?

By the way, I don’t mean to imply that the Closure Compiler is an overall better minifier than YUI Compressor.

These are just two simple examples, but I’m interested in learning some more best practices that will keep my un-minified code readable but produce tighter JS when minified.

It may sound silly to worry about 3 characters here and 5 characters there, but I think about it this way: it doesn’t hurt my code at all to follow the practices above and it has the potential to reduce size when minified (by even a very small amount), so why not follow it? This is similar to when I retrained myself to consistently use the pre-increment operator in C++ for-loops in case the loop variable is an iterator: doesn’t reduce the readability of my code and has the potential to improve the efficiency (read more).

So what else?

I decided to go with my Solitaire demo because it was the most complete, didn’t infringe on any copyrights (looking at you Tetris), and most visually recognizable. It’s not the most innovative, but then again the point of this is not necessarily to win any prizes. It’s really about increasing awareness.

Unfortunately, the SVG (26kb) and JavaScript (16kb + 21kb) totaled 63kb. I did some cleanup of the SVG, minified the JS and then put the script inline with the SVG and then gzipped it. The result was a .svgz file that was 9kb. Perfect!

I then got an email from a friendly marketing/evangelism person at Microsoft who said that the engineers did not know how to open the svgz file to review the code to ensure it was under 10k. Woops! I explained to her that I thought it would be ok for the SVG to be gzipped, much as PNG/GIF files use compression and sent her the uncompressed SVG file for them to review. After all, SVG is just an image format, right?

Was I following the rules? Did Microsoft give me a fair shake? See for yourself. Who knows, maybe this is the first time a Microsoft admin had to figure out how to serve SVG on a Microsoft web server.

Out of curiosity, I later tried to see how far I was able to get down the Solitaire game: 5811 bytes. Not bad for a complete game that has scalable graphics. I’d be curios to see the equivalent SWF file.

I don’t expect you to vote for my entry, but what I do expect you to do is now go out and submit .SVGZ entries to the MIX 10k challenge. That one SVG entry is looking pretty lonely. If I can get Solitaire down to 5811 bytes, surely you can do better?

Thanks a lot to Amy, the evangelist/marketing person who really was quite patient with me.

Flickr Badges

Flickr is a pretty popular site for sharing photos with friends, family and the world. Flickr even lets you embed ‘badges’ of your recent or popular photos into your own web page using HTML or Flash. Of course the Flash badge has some animation effects that are not easily achievable in HTML. I thought I’d use FakeSmile + SVG to create my own badge. I started with some backend code that Rob has had kicking around in his repository for almost two years.

You can see the results to the right and also on my personal info page. The badge has been tested in Firefox, Opera or Safari. There seems to be some trouble with the Renesis 1.1 plugin for Internet Explorer, so please stay tuned there. The badge can be seen full-browser here (sorry for the low-quality rasters, I’m only grabbing 75×75 pixel thumbnails from Flickr at the moment).

The images are cached from Flickr using a bit of PHP and the Flickr feed is checked every hour for new photos. If you want to see the source of the PHP, please click here.

SMIL Timesheets

Others have started experimenting with FakeSmile, too. Usually the people that I talk to that have used SMIL are pretty delighted with the technology. It’s a shame that it’s not well-supported across modern browsers yet – perhaps it has something to do with the slow public response rate of the SYMM Working Group?

However, while Opera (and now WebKit) have started to support SMIL within SVG, there are no browsers that support SMIL Timesheets yet. So FakeSmile will have to do for now (here’s another alternative that I have not experimented with).

You can think of SMIL Timesheets as the counterpart to CSS for web pages. If stylesheets are like the set decoration of your web page, then timesheets are like the choreography. What’s really nice about this is that you can have a nice, concise bit of markup representing your content (the images, in this case) and then you can externally link to a separate timesheet to animate the web page. You can use CSS selectors to apply animations to any of your web elements and use the same timesheet across multiple pages. You can see my SMIL Timesheet here.

If anyone wants to send me a SMIL timesheet with other cool effects, please feel free (look for my email address here). Perhaps I’ll eventually have my PHP pick a random effect one day.

FakeSmile

The FakeSmile script has come a long way since David released it a few months ago. It implements a decent amount of SMIL and SMIL Timesheets so that you can actually use these technologies now while the browser vendors catch up. David has also recently included a full version of jQuery inside the FakeSmile script, so it’s beefed up with lots of power now. I think he will probably be releasing minimized/compressed versions eventually.

[Update: I should also acknowledge Damian Cugley for being the original inspiration behind Rob starting his project]

As with all experiments of late, you need a cool browser like Opera, Firefox or Safari to see this stuff. I’d be interested to hear if Konqueror 4.0 supports it. Internet Explorer will just not do, I’m afraid.

I currently use SMIL in my menu above, in the leering FakeSmile icon to the right (which I’ve inlined to see what happens when it gets aggregated in feed readers like Planet Venus), and now in my comment box when you focus and blur it.

Yes, this is just shiggles and not very productive – but I’m not alone in experimenting with some advanced web features on my blog.

Yes, SMIL intermixes “presentational”-type markup with “content” markup – but SMIL Timesheets looks to me like an attempt by the SYMM Working Group to address this. Maybe something in the future for FakeSmile to support?

And yes, it’s kinda fun. SMIL is the blink tag of the new millenium…

Oh, and in case you missed it above, I’ve started using SMIL in my blog’s comment textarea – that’s XHTML, not SVG. The FakeSmile library supports a limited subset of SMIL functionality in not just SVG content but on any attribute in a XML-based language (provided you properly namespace where required, like in XHTML):

That’s what makes XHTML so attractive to me – the X is for eXtensibility. While I still support the effort, the current HTML 5 activity is mostly focused on SVG (and to a lesser extent MathML) integration with text/html. I hope they do address more flexible extensibility within HTML5 at a later date. It would be great if someone had already done HTML+SMIL so there was some basis off which to work. Snarkiness aside, I will admit to not understanding the ins-and-outs of namespaces within HTML and all the problems it poses, but I’m trying to learn in my spare time…

One semi-amusing footnote: You won’t see the textarea expand when you focus it in Opera. This is because Opera supports SMIL-in-SVG already, so the FakeSmile script is not executed (short-circuited). It would be great if Opera went ahead with XHTML+SMIL support. I’m not sure why that hasn’t happened yet…

[Update: David has fixed his library to allow Opera to use the library for XHTML+SMIL as well as interpolate between properties with units (i.e. 2em).]