Forcing deprecated technology is bad

Adam Alesandro
Signalbase Blog
Published in
3 min readJan 2, 2017

--

Recently, a key component of a vendor’s system broke after a user applied a Microsoft Windows update. Because this is one of our largest clients I felt that I should do what I could to resolve the user’s issue. This component was a HTML page loaded inside a Windows client so, naturally, I copied the source link and dropped it into an IE window and opened developer tools. The first thing that hit me was:

DOCTYPE expected. Consider adding a valid HTML doctype.

Maybe I just began Web Development at a time when declaring a DOCTYPE was ‘mandatory’, but I was both shocked that there wasn’t one and very suspicious that this could be the issue. I created an additional page and added a DOCTYPE but it still didn’t fix the issue so I decided to stand down and wait for the vendor to put a fix/bulletin.

By the end of the day there was still no word from the vendor and the client’s IT was hesitant to roll back the Windows update because it contained significant security patches for IE. I took another look at the page load in the IE developer tools and noticed that the structure looked something like this:

index.html (provides the bootstrapping)
|-> sidebar.html
|-> dashboard.html
|-> .... other assets ....

Interestingly, the sidebar and dashboard were being initiated by index.html and their HTTP status showed as ‘aborted’. This also seemed very suspicious so I looked at the index.html page source and saw that both assets were being loaded into IFrames. I am no IFrame expert but I do know that they are quirky, so a quick test that the sidebar.html page would load directly (test successful) confirmed that we are on the right track. A quick Google search on IFrames not loading in IE led to another missing element on the page:

<meta http-equiv="X-UA-Compatible" content="IE={IE_VERSION_HERE}">

Adding this tag with IE=edge allowed the page to load normally- though it looked a little strange. Despite the slightly off layout, the page was fully functional. Now we have a fix, so we can wait for the vendor to advise on the ‘real’ fix.

I had the opportunity to find out that the reason the layout was still a little off was because the vendor was trying to force IE to render in IE7 mode previously and since that doesn’t work after this update we are obviously getting a different view with the ‘edge’ mode turned on.

How we can do better

The real issue here isn’t that a Windows Update broke a piece of code. It’s that for approximately 10 years this vendor kept forcing Internet Explorer to render their pages using a deprecated rendering mode. Despite each new release of IE the vendor just let it keep getting worse and worse until one day a Windows Update broke it. Perhaps a visual:

|---IE7---|
|---------|---IE8---|
|---------|---------|---IE9---|
|---------|---------|---------|---IE10---|
|---------|---------|---------|----------|---IE11---|
|<<<<<<<<<<<<<<<<<<<<<10 years>>>>>>>>>>>>>>>>>>>>>>|

Not making the change when IE8 was released was at least understandable. But when IE9 was released, some flashing lights and alarms should have gone off and said “We need to update the parts of this code that are IE7 dependent because we are now two versions behind.” We cannot treat backward compatibility as given… instead we must treat it as a gift that buys us a little time to update the code that requires the backward compatibility.

Adam Alesandro is the Founder & CEO of Signalbase, Inc. Signalbase designs, builds and deploys technology solutions for Private Fund managers.

--

--