It was a bug because I said so
A screenshot came in six weeks into a build. The client’s finance director had opened the staging site on the machine in the back office, and the layout had come apart down the left side of every page.
The message attached to it was three words. Is this a bug?
Which is a completely reasonable question. I did not have a completely reasonable answer, because the honest one was “that depends on whether we support that browser,” and nothing anywhere in the project said whether we did. Not the proposal, not the estimate, not the ticket, not a wiki page. So it got settled in a corridor, on the spot, with the account manager standing there and the client copied on the thread, by whoever was under the most social pressure at that moment (read: me). I said yes.
Then I fixed it. You always fix it, and that’s the problem.
The customer is always supported
None of what went wrong there was technical, which took me an embarrassingly long time to see.
If you never write down which browsers you’re building for, you haven’t left the question open. You’ve answered it. The answer is all of them, because that’s what anybody reasonably infers from silence, and honestly it’s what I’d infer too. Nobody buys a website and assumes it comes with an unlisted set of machines where it doesn’t work.
So the absence of a promise reads, to everybody who isn’t me, as a promise of everything. Every old laptop in every back office is then a defect instead of a limit, and defects are free, because they were in scope by implication and nobody ever put a number on them.
I wrote a post a year or so ago about IE8 being a client and not a browser, the entire argument of which was to go and get the client’s own numbers before you build anything. I’d like it noted that I wrote that, and then stood in a corridor in week six of a build making it up as I went. Asking turns out to be the easy half. The half I kept skipping is writing the answer down somewhere it can be read back to me.
Grading on a curve
The instinct is a list of browsers with checkmarks next to them, and that falls over immediately, because “supported” isn’t one thing. A site can be perfectly usable somewhere I’d never promise it looks right.
Yahoo published a thing called Graded Browser Support about a decade ago, which I confidently attributed to the BBC in that older post and was wrong about. I’ve been quietly using its shape ever since. Three grades, instead of a line with browsers above it and below it.
Grade A is where it looks right and works right, we test it every sprint, and a visual difference is a bug. That should be a short list, and on most of what I work on it’s current Chrome, current Firefox, current Safari, current Edge, iOS Safari and Chrome on Android.
Grade B is where it works. Everything is readable, every form submits, every link goes where it’s supposed to. It may not look identical. Rounded corners might be square, a grid might be a stack, an animation might not happen. IE11 lives here on nearly everything I build now, along with the old Android stock browser. It’s the grade doing all the actual work in the document. Every progressive enhancement I write is a Grade B decision made early, including the flat hex I left sitting under a custom property a couple months ago so Edge and IE11 would keep getting a green button.
Grade C is where we don’t test and we don’t fix. It gets HTML and enough CSS that a browser from 2004 can cope with it, which mostly means not fighting the browser, because HTML degrades on its own if you leave it alone.
Three grades beats a column of checkmarks because Grade B is the honest answer to most questions and a checkbox can’t hold it. “Does it work in IE11” has the answer “yes, and the cards come out in one column,” and that sentence is the entire negotiation.
Whose browsers are they anyway?
Which browser lands in which grade isn’t mine to decide. It isn’t a blog post’s either, and January is thick with blog posts telling you what’s dead this year. The client has the real answer sitting in their own analytics, usually untouched, and the marketing person will export it if you ask.
Current share is the least useful number in there. I want the trend over 12 months. A browser at 2% that was 4% last year will be at 1% not long after launch, and the site is going to be live for years. So you’re building for the window instead of for today. IE8 halved roughly every year for as long as I watched it, and Microsoft stopped supporting it a year ago this month, along with 9 and 10, which took that argument out of my hands entirely and, not gonna lie, I was glad.
The trend won’t tell you who those people are, though. I’ve been caught by that one before. A share going down isn’t on its own a reason to drop a row off the bottom. It’s a reason to ask a question with a number attached to it.
Three places or it isn’t real
A matrix in a document nobody opens is the style guide problem again, and I’ve now learned that one often enough to at least see it coming. So it goes in three places, and it’s the same matrix in all three.
In the proposal, in a sentence somebody non-technical can read and agree to. Not a table of version numbers. Something closer to this: current versions of the major browsers get the full design, IE11 and older mobile browsers get a working site that may look simpler, and anything older than that gets readable content.
In the test plan, as the list somebody actually opens before launch. If it isn’t in that list you don’t test it, and if you don’t test it you can’t promise it, so the list and the promise have to be the same list.
And in the repo, machine-readable, because half the toolchain will read it for you now.
"browserslist": [
"last 2 versions",
"ie 11",
"> 0.5% in US",
"not ie <= 10"
]That last line is doing more than it looks like. last 2 versions means the last two of every browser it knows about, and the last two versions of Internet Explorer are 10 and 11, so without it I’d be prefixing for a browser I had just finished telling the client we don’t test. Autoprefixer reads that array, which means the prefixes in the built CSS come out of the promise we made instead of out of a preset somebody copied off a blog in 2014. That’s the part I find genuinely satisfying. The commercial decision and the build output stop being two unrelated things that disagree with each other a little more every quarter.
It doesn’t stop the screenshot
Worth being plain about, since I spent a while expecting otherwise. The screenshot still arrives. It changes what happens next. There’s a document to point at, and the conversation becomes “that’s Grade B, here’s what Grade B means, would you like to move it up, and what would you like to drop to pay for it.” That’s a normal conversation between adults about money. Without the document it’s me appearing to invent an excuse in real time.
It also can’t be a wish. If you write Grade A and don’t test it, you’ve written a lie with a table around it. And it goes stale, because a matrix is a snapshot of an audience and audiences move. So I’ve started putting the date and the source of the numbers in the document itself, so a year from now it reads as out of date instead of authoritative.
I did write one for that project. I wrote it in week seven, four days after the screenshot, which is the worst possible week to write one, because by then it isn’t a decision. It’s a negotiation about something that already happened, and everyone on the thread can see exactly what you’re doing. The client agreed to it and was perfectly nice about it, and I can’t shake the feeling that what they agreed to was a tidy description of a call I’d already made in a corridor.
The version I want is one page, in week one, when everybody is still enthusiastic and nobody has anything to defend yet, which is precisely when it’s easy to agree and precisely when nobody thinks to bring it up. It takes an afternoon, and it’s allowed to be bad. A rough matrix naming three browsers and three grades answers “is this a bug” better than the best one I have ever written in week seven. I’d rather have that question settled by a page somebody skimmed in January than by whoever happens to be standing in the corridor six weeks later, and for most of my career it has been the corridor.