It's funny how eternal the IE6/7/8 struggle felt at the time and now it's essentially ancient history. All that knowledge of how to coax CSS into doing things cross-browser circa 2004-2010 is basically useless to me now. Those years were my HS hobby -> college -> career transition period and it's amazing that I didn't give up because of how god damn convoluted basic frontend development was back then. And it was so discouraging because you could do things by the book (er, spec) and they'd work flawlessly in Firefox, but look assbackwards in IE6.
Sure, I miss the magical cowboy days, when it was entirely normal to write a ream of spaghetti that did something incredible, but I really, really don’t miss the “our customers are complaining that the site looks bad on IE4 at 640x480 in 16 colours and the purple gorilla has to go why did you add it” calls.
Oh, and IE for Mac. Back then one kept a bottle of scotch and a pistol in one’s desk.
Not to worry, we'll eventually have a similar experience moving from Chrome to whatever comes next. Their market share is in the IE6 digits now, and Pepperidge farm remembers how advanced and sophisticated IE6 was considered when it launched.
A lot of us felt like such pioneers in those days. Writing frontend web apps was an emerging and rapidly changing art. Those of us on the bleeding edge read Ajaxian.com and Douglas Crockford. I was writing internal SPA apps for Firefox+IE6 with Prototype.js and ExtJS.
My co-workers strongly disagreed with my approach -- to build for Firefox first, then hack it to work on IE. "Why bother when 95% of your users are on IE? That's a waste of time."
But those apps are still being used, almost 2 decades later, with no modifications required (besides a couple of weird edge case hacks for later versions of IE).
I remember DHTML before the word Ajax was coined. It is somewhat sad we didn't push this forward to its absolute limit. Instead 20 years later we have very different set of Front End tech.
And XLST... Actually pretty cool, a standardized way to render XML files. Too bad XML was way too verbose and clunky that everyone basically walked away from it.
The furthest DHTML got was "here's a cool JavaScript you can add to your page to make it do this". I used to download these from DynamicDrive.com. It took Crockford and Ajax to birth front-end development as we know it today (albeit without modules, CSS 2, or ES5+).
It didn't help that so many JavaScript books of the time treated the language like a toy.
A lifetime of dirty browser hacks is suddenly flooding back. Kids these days will never appreciate what we had to go through to make a page render anywhere near consistently in different browsers.
Tricks like crafting css that only some browsers could parse.
height/**/: 300px;
Or the insane sliding doors technique we used to get rounded corners.
The fact that select inputs were rendered by the OS so you had to find them all and hide them when you opened a modal so they didn’t sit on top of your content.
The desire to support custom files that drive us into swapping all the text for blocks of Flash after the page loaded.
It was almost better than the 20 level deep nested table layouts full of shims we had to do.
The most memorable hack was the voice-family hack for IE 5.5 IIRC. I remember reading about it and how the hack was so nice as to reset the voice-family afterwards. To date I still don't think voice-family is really supported anywhere; really shows how optimistic CSS was at that time.
You didn’t have to hide selects, you just (just, hah!) had to dynamically generate an empty iframe and shim it one z-level below your absolutely positioned div.
We accidentally discovered the max number of assets circa 2011 in a very large Rails app in development mode (which loaded CSS/JS files individually without concatenation). I forgot what it was but it was much lower than you'd anticipate.
I think I got hit by that being not exactly 4096. Some elements would grab a selector handle, then disappear, but take the handle with them. It's been too long, and my memory is too crap, to be sure. But I think I sat there growling cursewords for a few days until I worked that one out.
I... don't think this \9 is intentional! If I remember correctly, any attribute value would mess up IE < 9.
At this time, I was favoring using conditional comments to deliver tweaked simplified CSSs for the IEs. They were not only buggy, they were slow, so for a while it made some sense.
There were two things, \0 (escaped null) and \9 (which I think was could be any other escape sequence, but that 9 was customarily used). I don't remember the difference in browsers they'd target, the information will still be out there somewhere, I'm sure, though you'll have to sift through dead links.
> IE7.js is a JavaScript library to make MSIE behave like a standards-compliant browser. It fixes many CSS issues and makes transparent PNG work correctly under IE5 and IE6.
Adding to the pile of anecdotes of dirty browser hacks we're proud of: In 2002 (few years before Ajax went big) I rolled my own Ajax-y thing using a hidden iframe with a form inside it to send & receive data from the server while the user never saw a page reload. The app I used it on was for a client whose rather bad idea failed a year or so later but I'm proud of my part of it as a junior dev with a crazy idea!
I love/hate that era so much.