I thought long and hard about that until I found some JS out on the web that will basically add media query support to our grandpa holding up the fast lane… IE.
I start out by developing general base styles and make sure everything is decent between 1024-1280px wide, as this low-res is likely to be found on those who still use old IE. I set the body to max-width of 1280 so it stops scaling if old IE is running on a larger screen. Then, I set max-width back to 100% in a media query to let it use all the real-estate available. I add the JavaScript I mentioned above, then close IE immediately and discontinue any tweaking for it and begin building for real browsers. In the day that web clients want basically four interfaces in one, it’s just not feasible to assume you can build code for phones, tablets, SD, HD, “retina” iPads (seriously… people who buy iPads have no use for 3000px displays – this is ridiculous – they use them for Facebook) AND on top of all of it, support Internet Explorer 7? I get it, it’s all supposed to be backwards-compatible but it’s not.
If a client asks for IE8 support on top of all of the above, we have to charge more because of the significant amount of time it adds to the project. If they also throw IE7 in there, we take 1.5x the additional IE8 support cost, and that’s their legacy browser support cost. Usually, when we do user analysis and look at trends, they realize that a.) legacy IE is “dead enough”, b.) the cost to tweak and hack everything to display as designed/well on old IE is nowhere near worth the time, investment or code clutter because, c.) someone on IE7 clearly doesn’t care/notice the web looks/works like crap to them (or else they would have upgraded by now) and/or don’t know how to use a computer well enough to find web information and aren’t going to effectively receive the purpose of the site, if not are lost or aimlessly browsing. The only other people who are on old IE are possibly corporate workers at companies with poor IT leadership who lock users down to old IE7 to “ensure security” (WHAT?!) or have an old web app coded by careless fools that only works in IE7 (and haven’t found out how to work compatibility mode in IE9.) Keeping in mind that this corporate user is very, very rare, doing anything beyond the bases to support IE is beating a dead horse. Businesses so cheap they can’t ditch a web app they bought in 2001 (that’s probably never worked and held back workflow the entire 10 years they’ve had it) are probably not after a modern HTML5 responsive web app or anything that would require marketing with such a website. And if they are, they’ll get the information they need – just not how your designer wanted it. You just can’t blast out the timeline to support every ancient technology in the world. If you build it right to start with, it will support old IE “well-enough” to provide information – which is what the web is for. If we’re going to support IE7, what’s stopping a client from asking for AOL support. Most are simply unaware of the required work until they see the longer timeline & legacy costs. Makes no sense when all that work is done and they still have a crappy experience because they haven’t upgraded. If anything, put a message in the footer saying it won’t display properly because they haven’t bothered to upgrade yet.
IE sucking behind, you know what also sucks? This BS:
-webkit-min-device-pixel-ratio: 2
min–moz-device-pixel-ratio: 2
-o-min-device-pixel-ratio: 2/1
min-device-pixel-ratio: 2
and now that Windows 8 is out and IE10 is available, we get another:
-ms-min-device-pixel-ratio: 2
And I want to slap Mozilla for making some random declarations different than the rest. Also love how Opera uses the webkit conditionals because “web developers are being lazy and not including all of them.” First off, it is ridiculous to blame web devs for omitting code when the code is there… five effing times, and you’re just choosing not to read the base declaration because it’s not “standardized” yet, and W3C’s CSS people need to get a clue and start doing rolling standards with CSS as they had to with HTML, and second of all, no one uses freaking Opera. I omit Opera on purpose, bitches. Don’t act like I’m lazy when really your usage share on my analytics sheets are 0.2%. The lone Opera user that probably didn’t even speak the same language and accidentally wound up on that page had to see the fallback experience. Ohh no! Big deal. Don’t care.
Most of the time when I only include webkit conditionals it’s because the declaration is targeting mobile devices. With that statement, you can hit the Droids, iOS and Blackberrys with one punch. So good job Opera, you’re applying styling that’s meant for an iPhone. Fail. Yes, I know Mozilla makes a Firefox for Android that barely functions, Opera has like 15 browsers in the Android market that no one uses and has made browsers for various ancient handheld technology that’s not CSS3 capable, nor used anymore, nor displayed large enough on the hardwares two-pixel screen to show anything but your web’s logo. I’ll only hack my code to pieces if the usage numbers are there to back it, and IE on mobile hasn’t even acquired enough users for me to care to add 500 lines of “-ms-stupid-conditional-code-killer” with the other mobile declarations. Don’t talk to me about lazy web developers when CSS has taken on 5 times as much code to be authored because of this and causes nonstop issues such as Mozilla’s inability to stay with the format of the rest. No, we aren’t enjoying having to Google what every browser’s little hack is called for every little attribute. No, I’m not including all of that code for browsers that are used so little that I don’t even bother testing in them. Go ahead and read the -webkit- declaration Opera, just remember it doesn’t matter because when it comes to my users, no one will see it. I don’t want to hear the “oh Opera just said a lot of developers don’t know they’re forge…” because that’s BS too. No one forgets it. Many remove it from code snippets they paste in from tutorials. This is why we build fallbacks. Didn’t forget. Not lazy. Don’t care.
I cannot believe we are still having to do this, and I’m sure in the future we’ll be fighting about when it’s appropriate NOT to keep doing this, but one thing’s for sure – I want to punch some people in the face for not addressing developers issues on the basis of standardizing the same way we did in the 2000s… back when the web was broken and hacked to pieces with sht code. The browsers are ready because we’ve been using it already. Our clients are ready, they’ve been demanding it for years already. Users are ready, they’ve got it on 4-inch screens already. Many, many new CSS specs are ready & waiting for standardization. To me, these are already standardized because they display the same across all browsers and are used in mass across the web. If I hear “backwards compatible” as I hack out 500 lines of code into 2500 to support the technology that’s actually being used today, I’ll kill someone. Get a clue. Electronics manufacturers don’t make the technology to last longer than 5 years (two if we’re talking about phones or Macbooks) and marketing directors to information archivists alike don’t give a flying crap that some ’90s technology that’s in a landfill by now doesn’t recognize their CSS. If it doesn’t recognize it, it will ignore that declaration, life moves on and in the end, no one even knew the difference, and if they did – they didn’t give a sht, if they did give a sh*t, they wouldn’t be trying to browse the web on a god damned Wii. Information is in the markup, if that’s there, then the web has done its job. I understand their logic, but I just think they have broken the web once again by forcing major version standardization, not understanding the real-world and how the web they’re working on is actually managed and are moving several-dozen times slower than the technology itself. Their little experimental hack schema has become a permanent part of the next decade of CSS and has already started to break things.
Lazy developers… screw Opera.
