Browser drift

I have been using a standard feature of the Chrome Web browser for the last several years in my Chalktalk program. About a week ago, in the middle of giving a presentation to a class full of students, I found that in the course of several hours it had mysteriously stopped working.

My friends, I was a victim of browser drift.

I had literally just tested everything a few short hours before my talk. In that time, my computer must have upgraded to the latest version of Chrome, which had proceeded to — well — break stuff.

Now, a week later, after many hours of debugging, I have figured out how to get around the problem. Essentially, I have completely abandoned that feature of Chrome.

Instead, I implemented something entirely different, which happens to look and behave the same to end users. It’s kind of like dynamiting an entire building down to its very foundations, and then using entirely different construction techniques to erect a new building which just happens to look exactly the same.

Browsers are built according to standards that are carefully overseen by large and quite conservative committees. One would think the programs we write for the Web would therefore be immune to this sort of nuttiness.

Alas, I should know better. After all, my NYU webpage is littered with the sad rotting corpses of once beautiful Java applets that will never again come to life.

One thought on “Browser drift”

  1. One (painful) solution is to make your code also work on Firefox, so you get the benefit of the overlapping part of the “standard” that’s actually standard. This is a bit like a lawyer trying his case in two courts to see which one acquits his client.

    The “other” browser pretty much has to be Firefox though, since many of the remaining browsers (Edge, Opera, etc.) are now using Chrome’s Blink engine.

Leave a Reply

Your email address will not be published. Required fields are marked *