kaioa.com

Can we fix it? No, it's f-ed. :)

In today's episode of Pick your Poison we'll take a brief look at popular options for dealing with Internet Explorer's rendering issues, glitches, and bugs. Basically, it's all about feeding specific versions of IE version specific property/value pairs which happen to yield the desired result(s).

I say "happen", because those pairs are always complete nonsense and they will usually break the layout in horrible ways if a sane browser were to interpret them. Well, we aren't talking about sane browsers today, but we need to make sure that we won't get in their way with these questionable and awkward workarounds.

If you're already familiar with these concepts, you can jump right to "The Small Twist" at the bottom of this article.

Keep them in check

Update: This whole thing has been superseded with a more uniform and rigid concept. You can check an early draft outline over at the OOCSS Google Group.

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.

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.

Interchangeable presentation

You know the drill

If you didn't ignore the web for the past few years, you've probably heard it a million times by now: separate your content and presentation, use CSS for presentation, and say yes to semantic markup. There is no doubt that it's the right thing to do, given the sheer amount of benefits.

In a nutshell: it makes your life easier by lumping those pieces together which belong next to each other. It's somewhat akin to the proximity usability rule. It also keeps the noise down; if you want to change parts of the presentation there are no content bits in the way and vice versa. There is also a lot less overhead since those style sheets can be cached on the client side. In extreme cases it can save as much as 200kb of utterly pointless bloat. Additionally, proper CSS usage also paves the way for the ultimate killer feature: interchangeable presentation.

Decisions, decisions...

Legacy Ball Chains

A few weeks ago when Microsoft announced their "opt-in for the default behavior" strategy I was disgusted. Quite frankly I still am. As I see it it's just another scheme to pave the way for more legacy cruft. Don't get me wrong, I'm not disappointed. After all it's what Microsoft always did, but the way they did that - pretending they are doing everyone a favor - was just a bit too annoying. Why can't they do the right thing? Just once.

"Backward compatibility", they say. But wait a minute - don't we already have a tool for that? Yes, we do. Conditional comments (another Internet Explorer specific thing) are used for this kind of things for a couple of years. In a nutshell: you create a website with a good browser (i.e. not IE), and then you work around IE's issues with override style sheets targeting specific IE versions.

The strategy was always to lean forward; fix the issues of the current and previous IE versions and hope that the next one doesn't need extra workarounds. Back when IE7 was released that didn't really work out, because it still had some of IE6's problems and a few new ones on top of that. I should have seen that coming.