kaioa.com

I ♥ Komodo :3

Komodo Edit – the open source spin-off of Komodo IDE – is hands down my personal open source application of the year. It had a massive impact on my productivity and it made web development so much less of a pain.

I used so many different text editors in my life, but none of them comes anywhere near the sheer awesomeness of Komodo. There is proper Unicode support, smart indent (which actually behaves smart), remote file editing (FTP, FTPS, SFTP, and SCP), Code Intelligence (~IntelliSense™), and lots of polish on top. It supports many languages and runs on the three most popular platforms (i.e. Windows, Mac OS, and Linux). It's also extremely stable, which is very important for this kind of tools.

The ActiveState guys are also very helpful and surprisingly responsive. For example there were some issues with active mode FTP, but after a bit of nagging and poking around in the code (mostly nagging though) the problem was solved. Just like that. I also asked for some shortcut which basically does the same as a double click; selecting the word below the caret. A few minutes later the JavaScript macro was there (thanks Todd!) and it even made it's way upstream; the next version of Komodo will include it as a regular command.

Well, it does fit

I really like standards and absolute strictness when it comes to things which are interpreted by zillions of different programs. After all, a scenario like this just asks for trouble. Validators do help there and as I wrote a few months ago they can really help you avoid many issues, potential issues, and also future issues.

However, I do like automation a bit more and herein lies the problem: 100% standards compliance isn't always an attainable goal. And if you simply can't get a perfect score, you cannot use those validators for your automated tests. A test which always fails isn't really helpful.

There are many things, which never will be valid and you can't do anything about it. Proprietary or legacy content management systems and components thereof are a good example. Another source of pain are those bloody rich text editors. Some of them produce amazingly awkward markup with zillions of font tags all over the place for good measure.

A simple sprite sheet

Update: Good news, everyone! A proper proposal for this kind of thing is already on its way. :)

CSS sprites are a nuisance

While CSS sprites offer nice performance benefits (less connections/overhead), they are troublesome in every respect. Putting lots of tiny images with different dimensions into one bigger image is fiddly and very hard – np-hard in fact. But that's the smallest issue. It doesn't need to be perfect after all. Deflate will happily squish all that extraneous white-space to virtually nothing.

One of the real problems is CSS. It just isn't flexible enough to let you do everything you might want to do with your sprite sheet. For example repeating parts of the image isn't possible. And if you want to display a sub region of an image in the upper right of some element, it only works if that sub region is in the lower left of the sprite sheet. So, the best thing you can do is to use elements in the size of the sub region and use background-position to slide the image around, but that usually means extra markup for something that should be very simple.

But it doesn't stop there. The real nightmare is maintenance. A year or two and several iterations later it becomes very hard to figure out which parts of the sheet are used. Where can you add one? Which one can be removed? How many places do you have to fix if you move this column a bit up? It all becomes a mess of fuzzy uncertainty.

CSS sprites are a huge time sink. They waste my time, they waste your time, and they also waste the time of millions of other front-end developers. It's about time to do something about it.

Zing!

This topic has bothered me for quite a while. There are really some people out there who believe that validators are something for standard lunatics; that passing the validation with flying colors is just another pointless bullet on someones nerdy checklist. That the sole reason for valid markup and styling are some kind of bragging rights.

That's not the big idea. It really isn't.

When you write other kinds of code, there usually is a compilation step involved. If something goes wrong, the compiler will tell you where it couldn't figure out what you meant. With that information at hand you can quickly take care of the issue.

Now, with CSS and (X)HTML things look differently. There won't be any kind of direct upfront feedback (unless you serve your documents as application/xhtml+xml). Things will either look as intended or they won't. If they look right is also a completely different story.

That's some shiny logo

CSS grid frameworks in a nutshell

There are various CSS grid frameworks, which try to make the life of front-end designers easier. There's YUI Grids, Blueprint, a bunch of other frameworks, and well, the 960 Grid System.

All those frameworks do their magic through non-semantic classes, which are added to your containers. While this sounds pretty bad, it actually isn't much of an issue in reality. Well, that is if you don't use those classes in your content. Fortunately there is very little reason to do so if you're using some kind of CMS – and if you aren't, you probably should.

Personally I happen to like the 960 one most. It's pretty minimalistic while offering enough flexibility. It's also shipped with a bunch of templates for Fireworks, Illustrator, Omni Giraffe, Photoshop, and Visio. Inkscape, however, was missing. It's time to fill that gap! :)

pew pew

Know your :target

:target is one of those sparkling new CSS3 pseudo-classes. Unlike the other (pseudo-)classes it got some semi-dynamic properties without any kind of client-side scripting. Well, :hover and :active are also somewhat dynamic, but we're used to that stuff by now.

The :target pseudo-class is supported by all modern browsers. IE6 and IE7 are of course way too old. Unfortunately IE8 still doesn't support this. Pretty disappointing, isn't it?

However, this shouldn't stop you from using :target. If it's used as intended it only adds small visual cues which improve usability a bit. Dropping them won't break the site, but they are surely nice to have. Wikipedia for example uses :target to highlight the footnote you jumped to and anyone with a decent browser benefits from this small tweak.

I'll show you how :target is used on Wikipedia – or more precisely: in general, and I'll also show you some rather experimental things you haven't seen before.

The hashes match

I just finished a tiny web application. And by tiny I do indeed mean tiny. It's a single file and less than 8kb in size (thanks to GZRepack). You can check it over at riddler.kaioa.com.

It allows you to store the hashes of answers to some question in an URL. If someone clicks on that URL he/she is then asked for the solution. If it matches any of the up to 5 hashes the icon and the border turn green and he/she can then start the next round.

*squish*

SWF gaiden (side story)

This is some kind of spin-off from my previous mini project. As I said back then Deflate is everywhere. SVGZ files are just gzipped SVGs for example. I thought it would be nice to have some specific tool for SVGZs, but since it's just GZip I decided to generalize it a little bit.

It's basically a logical sub step on the way to the next SWF re-compression utility. It spawns several worker threads which invoke different ZIP utilities with different switches. E.g. with 2 cores there are 2 worker threads by default, which means it can keep up to 12 cores busy with the current default configuration (it contains 12 tasks). At the end the smallest Deflate stream is extracted and put into a GZip file.

The tool is similar to PNGOUT, OptiPNG, or PNGCrush insofar as it clearly puts the priority on size over time — except that it's for GZ/TGZ/SVGZ/etc. files instead of PNG.

Hrrrrrngh!

Intro

With web games you want hits — lot's of hits. A million per month or more if possible. Of course this means lots of traffic. While broadband became faster and cheaper during the last couple of years, traffic is still somewhat expensive. In order to get a nicer cost/income ratio there are apparently two options: reduce the costs and/or increase the income.

As you might have guessed I'm about to tackle the former with brute processing power. If you reduce the file size by 1% every 100th served file is free. With 5% it's every 20th file and with 10% every 10th file. If the price for that are only a few minutes of processing power it looks like a really good deal, doesn't it?

A series of tubes (or not)

I'm using this network stuff for about a decade by now. I always just filled the required values in and never thought about it much. Well, until yesterday that is. It began with something simple; I wanted to read something over at one of Sun's sub domains.

"Address Not Found", Firefox complained. I briefly looked outside the window to confirm that it doesn't rain frogs or something. Alright, it's Just one of those random DNS issues.

It's just a temporary problem, but it didn't really feel like waiting this time. One forehead slap later I grabbed some DNS server IP, added it to my TCP/IP configuration, and everything was sorted.