IE8 is a client, not a browser
A practice wanted the text on their homepage photo to stop fighting the photo. The fix was a panel behind the text, white and a little see-through, with rounded corners and a soft shadow. It took me about 40 minutes in Chrome.
Then I opened it in IE8, which took the rest of the afternoon.
None of it works there. IE8 has no rgba so the see-through panel is either solid white or a proprietary filter with the opacity written at the front of the hex code for some reason. There’s no border-radius so the corners are square, and no box-shadow so the shadow is an image or nothing.
Each one was 30 minutes to an hour and each one was worth doing in the moment. At no point did I add them up.
I spent about 3 hours on a browser used by 1.8% of that practice’s visitors. I know it was 1.8% because I went and looked in their analytics afterward, which is, uh, about 3 hours later than I should have looked.
Nobody decided to do that. That’s the part I keep coming back to. Nobody told me IE8 was in scope and nobody told me it wasn’t either. The theme already loads an ie8.css in a conditional comment so I took that as the answer and started patching.
Money makes the world go round
I’d been treating browser support as a property of the project, like it was in the spec or the platform and somebody had handed it down. “We support IE8” was a fact about the world that I then had to work within.
But it’s a purchase. Somebody is paying for it in hours and those hours aren’t going into something else, which makes it exactly like everything else anybody pays for. I think it doesn’t get treated that way because it arrives in the language of technical constraint instead of the language of money.
Once I saw it that way, it got much easier to bring up. It stopped being me announcing what somebody’s visitors can’t have and became me showing what a thing costs. Those land completely differently. The first one is an argument and the second one is a receipt.
Go and get the number
The analytics almost always exist. Every practice we look after has Google Analytics on it because the marketing side lives in there. It took me 10 minutes and it changed the whole question.
Some things I looked at, having now done this once instead of zero times:
- Percentage of sessions, not users: They differ more than you’d think and sessions is closer to the thing you care about.
- Trend over the last year, not just the current figure: IE8 has been halving roughly annually. A number that’s 2% today was 4% a year ago and will be 1% a year from now, and the site is going to be up for years.
- Whether it’s concentrated: This is the one that surprised me. A good chunk of that 1.8% came from the practice’s own city on weekdays during office hours. I think it’s the front desk. So the people most likely to open this site in IE8 are the people paying for it, which is a very different 1% from a thousand strangers. Base rates are a starting point, not the answer.
Yet another spectrum-not-binary
I was also wrong to think of support as a line with browsers above it getting the site and browsers below it getting nothing.
I’ve since stolen the idea of tiers, which I think came out of a style guide from the BBC of all places. One group gets the full thing and a second group gets a version that works and looks plainer. A third group gets readable HTML and no styling to speak of. That’s considered a supported outcome instead of a failure.
That sounds like a compromise but it’s just describing what happens anyway, except on purpose. The alternative isn’t “IE8 gets an identical experience.” It’s “IE8 gets an experience nobody has specified, which somebody discovers on the front desk computer and reports as broken.”
Three hours vs. two minutes
I took the 1.8% to the person who scopes our work. Their first response was “Don’t we support IE8?” That’s more or less where I’d started too.
Then they looked at the number and that was the end of it. IE8 gets the solid white panel with square corners and no shadow, which is a perfectly good panel. The conversation took about two minutes.
So I’d like us to try the same two minutes before anything gets built instead of after. Something like “Here’s what the analytics say about this practice’s visitors and here’s roughly what full support for the older browsers costs on a job this size. There are three ways to go: full support, a plainer version, or readable content and nothing more. Which one?”
And then whatever gets picked goes in writing. Picking wrong isn’t how this goes badly. It goes badly when nobody picks anything and then somebody opens the site on an old computer and is surprised, and now it’s a defect instead of a decision.
Full support is a fine answer too. If it turns out the front desk lives in IE8 and the doctor hears about every square corner, that’s a reason. I’m not saying IE8 support is wrong. I’m saying it should be a sentence somebody said out loud.
Ask more questions
Look before you write any CSS. The analytics take 10 minutes and the fallbacks take an afternoon. Write down what was decided in language the client would recognize instead of in terms of vendor prefixes.
I’m still figuring out the broader version of this and it probably applies to more than browsers. I think a lot of what feels like technical debt is just decisions that were never made explicitly. Somebody defaulted and defaults are invisible, and invisible things don’t get budgeted for.
Better tooling doesn’t fix that but asking earlier does. Asking is free and mildly uncomfortable, which is why nobody does it.
Maybe all of this is obvious where you are. The jobs I get are smaller than most. But I did spend 3 hours on 1.8% of an audience without ever noticing so I’d at least go and look at your numbers.