Skip to main content

Web Browsers You Should Support

As a web developer, generally speaking, you should consider supporting the following browsers (at the time of this writing):

  • Chrome (latest) - the browser that sets the bar for the others; you should be using it and supporting it
  • Internet Explorer 9+ - the browser that finally caught up with the times a bit; basically, a Chrome wannabe.  I still say that IE sucks... even if it really doesn't anymore.  Yes... I'm sour about IE8 and below.
  • Internet Explorer 8 - the old, sad browser that we sadly still have to support for a while.  CSS 3 is not well-supported here, so we use projects like CSS3 PIE or whatever.  By the way... IE8 sucks.  I can't wait until this comes off of the list.
  • Firefox (latest) - the browser that was once awesome and has sadly suffered recently because it's slower than Chrome... but hey, lots of people still use it.
  • Safari (latest) - Watch out for Safari as more iPhones, iPads, Macs, and more overly-priced Apple products flood the market and artificially drive Apple's stock price through the roof
  • Mobile - If you support Chrome, your site will probably work on Android, and if you support Safari, it will probably run on the iPhone and iPad.  The only work left to be considered is supporting various screen sizes with responsive web design.
Hmm... who didn't make the list?  Here are the browsers you should not consider supporting:
  • Internet Explorer 6 - fewer than 1 out of 200 people still use IE6 world-wide.  Unless you are building a website for the Chinese (who are a bit behind the times with IE6 usage over 10% and falling), you should NOT consider supporting IE6.  Instead, save hours of your life.  If a colleague or friend decides to support IE6 for their web app, you should laugh at them.
  • Internet Explorer 7 - with less than 2% usage world-wide, don't waste your time on IE7's poor support and stupid bugs.  Instead, save even more hours of your life.  Trust me on this one; you are better off thinking about responsive web design than supporting a dying legacy browser.
  • Any other browser (like Opera) - these browsers aren't being widely used, and to be honest, these browsers often support web standards the best... kind of like Chrome.  So, if you support Chrome, your site will very likely work in Opera or any other off-the-wall browser out there.
If an unsupported browser hits your site, be nice to the user.  Here are some suggestions:
  • Explain to the user why they have an unsupported web browser, but most importantly, tell them how to upgrade.
  • Send IE6 and IE7 users to the IE8 download page
  • Send IE8 users running Windows Vista or Windows 7 to the IE9 download page
  • Or maybe... send all IE users to the Chrome download page  :)
  • If any other unsupported browser hits your site, just let them be.  Don't warn them or anything unless absolutely necessary.  They probably know that they are using a old or off-the-wall browser, and if not, then they are among a small percentage of the population that won't be able to use your website.  Oh well...

Comments

Popular posts from this blog

Developing a lightweight WebSocket library

Late in 2016, I began development on a lightweight, isomorphic WebSocket library for Node.js called ws-wrapper .  Today, this library is stable and has been successfully used in many production apps. Why?  What about socket.io ?  In my opinion, socket.io and its dependencies are way too heavy .  Now that the year is 2018, this couldn't be more true.  Modern browsers have native WebSocket support meaning that all of the transports built into the socket.io project are just dead weight.  On the other hand, ws-wrapper and its dependencies weigh about 3 KB when minified and gzipped.  Similarly, ws-wrapper consists of about 500 lines of code; whereas, socket.io consists of thousands of lines of code.  As Dijkstra once famously said: "Simplicity is prerequisite for reliability." ws-wrapper also provides a few more features out of the box.  The API exposes a two-way, Promise-based request/response interface.  That is, clients can request data from servers just as easily as se

Computer Clocks Cause More Issues

Two nights ago, a leap second was added to system clocks running Linux, causing much-undesired havoc. On July 1st at 12:00 AM UTC, both of my Amazon EC2 instances fired an alarm indicating high CPU usage. I investigated to find that it was MySQL that was eating all of the CPU. I logged in and ran SHOW PROCESSLIST to find that no queries were running (these servers don't get hit much after business hours). I stopped MySQL, CPU utilization dropped back down to 1-3% (as normal). I restarted MySQL, and it started eating a lot of CPU again. Then, I restarted the server (shutdown -r now), and the problem went away. Both servers had the exact same problem (running Ubuntu 12.04 LTS). In my particular case, MySQL began eating CPU, even after being restarted.  It was a livelock. The only relevant item I saw in the syslog was: Jun 30 23:59:59 hostname kernel: [14152976.187987] Clock: inserting leap second 23:59:60 UTC Oh yeah... leap seconds.  Those are super important.

JavaScript Sticky Footer and Scroll Effect

This post talks about two different HTML/JavaScript effects: How to keep a page footer stuck at the bottom of the browser window. How to create a scrolling <div> without using a scroll bar OK. So... you have a website. You want a header stuck at the top of your page and the footer stuck at the bottom of your page. The stuff in the middle, you want to be able to scrollable. But, you don't want those ugly scrollbars to the right of your scrollable text. Maybe, instead, you'll have up arrows and down arrows above and below your <div>. When you mouseover the arrows, the text in the <div> will move up or down and create a scrolling effect. Suppose your page looks like this... <html> <head> <title>Test</title> </head> <body> <div style="position: relative; width: 700px; margin-left: auto; margin-right: auto;"> <div id="header">Header</div> <div id="scrollUp&q