Hardware acceleration bleeding into subsequent elements, and how to fix it

I'm really sensitive to stuff like anti-aliasing, so when elements on one of the pages I was styling ceased to be anti-aliased in Safari and Chrome, part of me died a little.

I suspected this was somehow related to the fact that I was using a 3D CSS transform on a small part of the page (for a little extra zazz), so I tried to narrow it down to a minimal reproduction. Sure enough, the 3D CSS transform was causing the anti-aliasing to disappear. 

Doing a little reading, I found that Webkit switches hardware acceleration on and off in parts of a page depending on a number of factors. If your element has any kind of 3D transformation applied to it, it gets hardware acceleration. Even if you change the opacity of an element, it gets hardware acceleration. When an element gets hardware accelerated in Webkit, sub-pixel anti-aliasing no longer works.

That's all well and good, but there were no 3D transformations applied to most of the page! Yet I was still seeing the aliasing. At this point, I realized that this must be some sort of browser quirk, so I set out to fix the problem. 

For a minimal test case, I created this HTML

The HTML resulted in this (notice how the second article's heading is aliased):

Screen_shot_2011-03-31_at_9

To be fair, the bottom heading *was* anti-aliased, but it wasn't sub-pixel anti-aliased, and the anti-aliasing still left the text looking jagged.

The solution(s)

My old foe, position:relative, was the culprit (you sneaky, sneaky property). Due to other elements on the page, the article element had position:relative. Removing this property got rid of the aliasing problem! I'm not sure why this was the case, but it worked for me.

Screen_shot_2011-03-31_at_10

Another solution is to explicitly set -webkit-font-smoothing:antialiased. The downside to this is your anti-aliasing will not match the rest of the page (since the rest of the page is sub-pixel anti-alised). I prefer sub-pixel anti-aliasing, but that's just me.

Anyway, I know this is a pretty obscure problem to have, but I'm sure there's at least one of you out there scratching your head about it.

N.B.: It looks like the latest Webkit nightly fixes this problem, so look forward to better looking text.

Cross-email-client compatible background image helper

If you've ever dealt with HTML email before, you know that it's a really big pain in the behind. Email clients differ widely in their HTML and CSS support, so it's almost impossible to create compatible HTML layouts without the use of tables and other archaic front-end techniques.

One of the most fundamental things you may want to do in an HTML email is add a background image to some element. While this task is easy in most web browsers, it's not so with email clients. I stumbled across an article on Campaign Monitor that outlined a method for adding background images that is compatible with many (still not all) modern email clients.

Needing to use this method fairly often, I thought I'd turn it into a Rails view helper. This is what I came up with:

It's not perfect, but it does the trick for me.