kaioa.com

Keep them in check

There is no coupling whatsoever between your CSS and your markup. But don't get me wrong – this is a very good thing. However, this also means you can't use your markup to verify your CSS and of course it also means that you can't use your CSS to check your markup.

If you create a relatively complex website with more than 2000 lines of CSS this gets pretty annoying. With practice this just gets more annoying, since the impact on your productivity becomes more apparent with each project. During a site's lifetime you'll often notice how theoretically solid structures start to crumble. One mistake in the markup, another one in the CSS, and sooner or later everything will be in a somewhat inconsistent state.

If you come from a programming background this feels just plain wrong. It's almost like your selectors happen to coincidentally select some things here and there. There is no clear way to define a structure and to check if your markup and CSS adhere to your rules. There is currently only one way to check it: the dreaded, time-consuming, and error-prone manual one.

Also, if things are inconsistent – and chances are this happens right off the bat – it's very difficult to reason about it. You might look at two pieces of markup and their corresponding CSS and both might wrong in different places. Sure, you can just refer to your documentation… eh, yea, who am I kidding? No one knows how stuff like that is supposed to be documented. And if they do, it probably still won't happen.

Caching makes it feasible

Generally speaking: off-screen rendering allows you to cache expensive drawing operations in some sort of image, texture, or buffer. With the new Canvas API the vector drawing operations for example can be a bit taxing. Same goes for gradients or patterns (Firefox 3.x). Or well, anything that requires many drawing steps or per-pixel calculations.

If you have used any other 2D drawing API in the past, you'll probably picture this a bit more complicated than it actually needs to be. As it turns out, it's surprisingly easy with Canvas since the drawImage function can also take another Canvas as parameter. So, there is no need to construct an actual image – you already got one, kinda.

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.