Specific changes for this update include:
|Chrome ||Latest stable|
|Safari||5.||iOS 3.||iOS 4.|
This edition of the GBS update represents a departure from our previous updates in that we are moving away from mapping browsers directly to experience grades (e.g. “A-grade” and “C-grade”). Rather than prescribe what user experience is appropriate for which browsers, we’ll focus on defining an efficient baseline test strategy that maximizes test coverage and minimizes the testing surface. For example, IE6′s still-significant global marketshare warrants continued testing; however today’s GBS allows for the IE6 user experience to be different from the IE9 experience.
In order to streamline testing and minimize resource requirements, we no longer specify which operating system should be tested on. The only exception is when the browser is tightly coupled with the OS version, in which case we refer to the OS version rather than the browser version (e.g. “Safari iOS 4″). This allows us to focus test coverage on browser versions, and minimize redudant testing across platforms. Issues with the same browser across versions are negligible, and generally related to higher-level OS differences, such as key handling and available fonts. Code that is known to touch upon cross-platform issues should be tested on as many platforms as possible, but this testing generally can be isolated to the specific issues rather than running a full regression test of all features. We recommend aligning operating system testing priority with your user base.
IE6 still has a significant enough global market share to warrant a verified acceptable user experience. One common misconception with the Progressive Enhancement strategy has been that once a browser enters “C-grade” that it becomes “unsupported”, when in fact it really means that it should be delivered the HTML-only experience. Now that we no longer prescribe which browsers receive what experience, this is left for projects to decide based on their users and resources. The GBS focuses on specifying which browsers need a verified usable experience based on factors such as market share and influence. Defining what is “usable” and specifiying acceptable levels of degradation are left for teams to decide. We still promote a simple Progressive Enhancement model, and discourage projects from creating new tiers without accounting for the additional costs in development, testing, and maintenance resources.
We expect to make the following changes in the next update: