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.
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.
In a nutshell: A static initializer is executed whenever you do anything with that class. It's executed before whatever you wanted to do (e.g. calling the constructor or accessing a field). It's also only executed once.
Many moons ago I released some code which utilized a static initializer. That code worked fine back then, but recent versions of the Flex SDK compiler don't really like it. Well, to tell the truth I also didn't like it, because the construct I used was sorta ugly and, well, pretty wrong.
Update: Good news, everyone! A proper proposal for this kind of thing is already on its way. :)
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.
About a week ago a friend of mine released his very first indie game – for the iPhone of all platforms. Sounds like a bit of a pain and probably it actually was. The game is basically a bigger and better version of one of his old games. The old one was written in C++ for Win32 (the source is also available over there). Later on he also ported it over to the GBA.
The new version looks and sounds pretty cool. If you're interested check out the video over at the official site. By the way, all models were done with everyone's favorite box modeler Wings3D. And the final audio cutting was done in Audacity. Both tools are mind-boggling awesome for these tasks. Check them out if you haven't yet.
Well, about a week has passed and he only sold a dozen copies so far. In the meantime it was pirated a few thousand times. Ouch. So, if you got $2.99 to burn (and an iPhone to boot) you can make one poor student very happy.
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.

Oh boy... I totally forgot to post this. A year ago Farbrausch and Neuro (their site has been down for a while) made a nice real time invitation demo for Nvision 08 featuring gorgeous vector graphics, which were done with Inkscape.
Check the demo if you got a decent Windows machine. Otherwise (or if you're just a bit lazy) take a look at the video over at YouTube.
By the way if you'd like to save the video you can do that easily with the Video DownloadHelper extension for Firefox.
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! :)
: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.
This is the updated extension for Inkscape which simulates 9 different types of vision. It's a color effect and therefore it can be found over at Effects->Color->Color Blindness after installation.
It still supports the same set of modes: