WordPress and I are through. We’d been together a long time, but things had started to go sour: it was needy and high-maintenance, susceptible to the wiles of passing charlatans, and finally I’d had enough. I told it “so long” and went off to find greener pastures.

Ran into this one today, in somewhat unusual circumstances: I had a hover style where buttons inside a table row only appeared when the mouse was over the row, and if you clicked on one of the buttons but moved the mouse into another row before releasing...

In these times of effectively unlimited quotas, there’s no need to ever delete email. And I don’t—all my various accounts’ inboxes combined add up to somewhere around 20,000 emails. Having all your emails is great, but accessing them quickly is at...

The IE z-index bug had been around since IE4 or 5, and was finally fixed in IE8. It’s still an issue in IE7, however, and chances are that you, the web developer, still have to support it. You should read Aleksandar Vacić‘s in-depth characterization of the problem to really understand what’s happening, but what it boils down to is this: the CSS 2.1 spec says that a positioned element with any integer z-index value (i.e. not auto) should create its own zero-based stacking context, and use the integer value specified to decide its place in its parent stacking context. In other words, if the positioned element has a z-index of auto, its stacking context is inherited from its parent. Internet Explorer, however, creates a new stacking context for elements with any z-index value, including auto, which wreaks all kinds of havoc and generally causes mayhem in your previously neat and orderly layouts.