According to Jeremy Keith,
“the solution is not to make leaner, faster pages just for mobile users; the answer is to make leaner, faster pages for everybody” (http://adactio.com/journal/1716). However, you cannot build everything in a browser that was made a decade ago. Even if engineers have crafted patches for legacy browsers, this results in more costly complexity for development and testing. We need to gain influence on browser usage.
Technical maturity and usage data can be combined into a grading (A to C) of browsers. This is different for each web application and its intended audience. If a Grade B browser like IE7 cannot fulfill a requirement, the response could be: “Inform user about reduced functionality and link to user education program.” The application should not sniff for a browser, in fact it should detect the capability of a browser with respect to a certain feature. Though this machinery stays under the hood. A Graded Browser Support promotes clarity in requirements, and reduces engineering costs.
During office hours, the usage of outdated browsers (which are one or more major releases behind) is much higher than after work, at least for business customers. Some IT departments are required to lock-in their employee’s browsers for various reasons. This does not explain the remaining usage of IE7 after work. User education should not be left to the browser vendors only, it should become part of our commitment to usability, performance, and security.
Finally, a feature-driven influence on browser usage is justifiable, if not necessary. Enhance features progressively: legacy browsers get a basic functionality; recent browsers get more capable features.