CodeSOD: And it was Uphill Both Ways

Среда, 25 Сентября 2019 г. 09:30 + в цитатник

Today’s submission is a little bit different. Kevin sends us some code where the real WTF is simply that… it still is in use somewhere. By the standards of its era, I’d actually say that the code is almost good. This is more of a little trip down memory lane, about the way web development used to work.

Let’s start with the HTML snippet:

In 2019, if you want to have a sidebar full of links which allow users to click, and have a portion of the page update while not refreshing the whole page, you probably write a component in the UI framework of your choice. In 1999, you used frames. Honestly, by 1999, frames were already on the way out (he says, despite maintaining a number of frames-based applications well into the early 2010s), but for a brief period in web development history, they were absolutely all the rage.

In fact, shortly after I made my own personal home page, full of

tags, creative abuse of the tag, and a color scheme which was hot pink and neon green, I showed it to a friend, who condescendingly said, “What, you didn’t even use frames?” He made me mad enough that I almost deleted my Geocities account.

Frames are dead, but now we have which do the same thing, but are almost entirely used for embedding ads or YouTube videos. Some things will never truly die.

  IE4 = (document.all) ? true : false;
  NS4 = (document.layers) ? true : false;
  ver4 = (IE4||NS4);

  if (ver4!=true){  
    function MaximizeWindow(){
        alert('Please install a browser with support for Javascript 1.2. This website works for example with Microsofts Internet Explorer or Netscapes Navigator in versions 4.x or newer!')
        self.history.back();
        }
    }
  
  if (ver4==true){
    function MaximizeWindow(){
    window.focus();
	window.moveTo(0,0)
	window.resizeTo(screen.availWidth,screen.availHeight)
      }
}

Even today, in the era of web standards, we still constantly need to use shims and compatibility checks. The reasons are largely the same as they were back then: standards (or conventions) evolve quickly, vendors don’t care about standards, and browsers represent fiendishly complicated blocks of software. Today, we have better ways of doing those checks, but here we do our check with the first two lines of code.

And this, by the way, is why I said this code was “almost good”. In the era of “a browser with support for Javascript 1.2”, the standard way of checking browser versions was mining the user-agent string. And because of that we have situations where browsers report insanity like Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36.

Even in the late 90s though, the “right” way to check if your site was compatible with a given browser was to check for the features you planned to use. Which this code does- specifically, it’s looking for document.all or document.layers, which were two different approaches to exploring the DOM before we had actual tools for exploring the DOM. In this era, we’d call stuff like this “DHTML” (the D is for “dynamic”), and we traversed the DOM as a chain of properties, doing things like document.forms[0].inputs[0] to access fields on the form.

This is almost good, though, because it doesn’t gracefully degrade. If you don’t have a browser which reports these properties- document.all or document.layers, we just pop up an alert and forcibly hit the back button on your browser. Then again, if you do have a browser that supports those properties, it’s just going to go and forcibly hit the “Maximize” button on you, which is also not great, but I’m sure would make the site look quite impressive on an 800x600 resolution screen. I’m honestly kind of surprised that this doesn’t also check your resolution, and provide some warning about looking best at a certain resolution, which was also pretty standard stuff for this era.

Again, the real WTF is that this code still exists out in the wild somewhere. Kevin found it when he encountered a site that kept kicking him back to the previous page. But there’s a deeper WTF: web development is bad. It’s always been bad. It possibly always will be bad. It’s complicated, and hard, and for some reason we’ve decided that we need to build all our UIs using a platform where a paragraph is considered a first-class UI element comparable to a button. But the next time you struggle to “grok” the new hot JavaScript framework, just remember that you’re part of a long history of people who have wrestled with accomplishing basic tasks on the web, and that it’s always been a hack, whether it’s a hack in the UA-string, a hack of using frames to essentially embed browser windows inside of browser windows, or a hack to navigate the unending efforts of browser vendors to hamstring and befuddle the competition.

[Advertisement] ProGet can centralize your organization's software applications and components to provide uniform access to developers and servers. Check it out!