IE8 is a client, not a browser
A fifth of the time estimate went on 1.8% of the audience. Nobody told me to do that, I just never asked.
I spent about a fifth of the time estimate on a browser used by 1.8% of that client’s visitors. I know it was 1.8% because I went and looked in their analytics afterward, which is roughly four months later than I should have looked.
Nobody decided to do that. That’s the part I keep coming back to. There was no call where somebody said “let’s allocate a fifth of the build to IE8.” It accumulated in half-days. A gradient that needed a fallback image. A layout that needed a conditional stylesheet. Rounded corners, which we ended up dropping. rgba shadows that had to become solid. Each one was fifteen minutes to an hour, each one was obviously worth doing in the moment, and at no point did I add them up.
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 in the platform, something handed down. “We support IE8” was a fact about the world that I then had to work within.
It isn’t. It’s a purchase. Somebody is paying for it, in hours, and those hours are not going into something else. Which makes it exactly like every other line item on a project, and the reason it doesn’t get treated that way is that it arrives in the language of technical constraint rather than the language of money.
Once I saw it that way the conversation got much easier to have, because it stopped being me telling a client what their users can’t do and became me showing a client what a thing costs. Those land completely differently. The first one is an argument. The second one is a quote.
It arrives in the language of technical constraint rather than the language of money, which is the only reason nobody argues about it.
Go and get the number
The analytics almost always exist. Somebody has Google Analytics on the site, usually the marketing person, and they’ll export it if you ask. It takes them ten minutes and it changes the entire shape of the discussion.
Some things I’ve learned to look at, having now done this on three projects rather than zero:
- Percentage of sessions, not users: They differ more than you’d think, and sessions is closer to the thing you care about.
- Percentage of revenue, if it’s a shop: This is the one that actually moves people. On one site IE8 was 2.1% of sessions and 0.3% of transactions, which tells a much sharper story than either number alone.
- 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% by the time the site’s been live six months, and the site is going to be live for three years.
- Whether it’s concentrated: Once, the IE8 traffic was almost entirely one corporate network on a locked-down SOE, and they were the client’s largest customer. That 1% mattered enormously and so we supported it. Base rates are a starting point, not the answer.
Yet another spectrum-not-binary
The other thing I had wrong was thinking of it as a line, with browsers above it getting the site and browsers below it getting nothing.
The version I’ve since stolen, which I think came out of a style guide from the BBC of all places, is to have tiers. One group gets the full thing. A second group gets a version that works and looks plainer. A third group gets readable HTML and no styling to speak of, and that’s considered a supported outcome rather than a failure.
Which sounds like a compromise and is actually just describing what happens anyway, except deliberately. Because the alternative is not “IE8 gets an identical experience.” The alternative is “IE8 gets an experience nobody has specified, which we’ll discover in QA and patch until we run out of time.”
Having the conversation
The version that’s worked for me is short and boring, in week one, before anything is built. Something like: here’s what the analytics say about your visitors, here’s roughly what full support for the older ones costs as a share of the budget, here are three options at different prices, which one would you like?
And then, crucially, whatever they pick goes in writing. Because the failure mode isn’t the client choosing wrong. It’s the client choosing nothing, and then someone in a review just before go-live opening the site on an old laptop and being surprised, and now it’s a defect rather than a decision.
I’ve had a client pick full support with the number in front of them, and that was completely fine! It was their money and they had a reason, which was a large slow customer that they didn’t want to annoy. The point was never that IE8 support is wrong. The point is that it should be a sentence somebody said out loud.
Ask more questions
Ask in week one. Get the analytics before you write any CSS. Write down what was agreed, in the proposal, in language the client would recognize rather than in terms of vendor prefixes.
And I think the broader version, which I’m still working out and which probably applies to more than browsers: a lot of what feels like technical debt in client work is just decisions that were never made explicitly. Somebody defaulted, and defaults are invisible, and invisible things don’t get budgeted for. The fix isn’t better tooling. It’s asking earlier, which is free and mildly uncomfortable, which is why nobody does it.
Maybe all of this is obvious where you are; my projects are smaller than most. But I did spend a fifth of my time on 1.8% of an audience without ever noticing, so I’d at least go and look at your numbers 🫠