( The YUI Target Environments Matrix is here)

About the Browser Test Baseline and Operating Systems

The Browser Test Baseline provides a baseline set of browsers that should be tested. It is designed to maximize coverage with limited testing resources by testing the smallest possible subset of browser combinations and leveraging implicit coverage from shared core browser engines. At the very least, all listed browsers should be tested in one operating system, in order to provide "baseline" coverage. Testing on multiple operating systems should be accommodated after all browsers have been verified with baseline coverage and should start with features that have known platform-specific issues. The test platforms should be chosen based on usage statistics and market trends.

The Browser Test Baseline defines the current set of browsers that should receive a verified, usable experience. However, trying to deliver the same "A-grade" experience across all tested browsers is neither cost-effective nor common. We support a tiered approach to user experience design, development, and testing, and encourage each project to define their own tiers that serve their users and their testing resources best.

Graded Browser Support: What and Why

In the first 10 years of professional web development, back in the early '90s, browser support was binary: Do you — or don't you — support a given browser? When the answer was "No", user access to the site was often actively prevented. In the years following IE5's release in 1998, professional web designers and developers have become accustomed to asking at the outset of any new undertaking, "Do I have to support Netscape 4.x browsers for this project?"

By contrast, in modern web development we must support all browsers. Choosing to exclude a segment of users is inappropriate, and, with a "Graded Browser Support" strategy, unnecessary.

Graded Browser Support offers two fundamental ideas:

  • A broader and more reasonable definition of "support."
  • The notion of "grades" of support.

What Does "Support" Mean?

Support does not mean that everybody gets the same thing. Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web. In fact, requiring the same experience for all users creates an artificial barrier to participation. Availability and accessibility of content should be our key priority.

Consider television. At the core: TV distributes information. A hand-cranked emergency radio is capable of receiving television audio transmissions. It would be counter-productive to prevent access to this content, even though it's a fringe experience.

Some viewers still have black-and-white televisions. Broadcasting only in black-and-white — the "lowest common denominator" approach — ensures a shared experience but benefits no one. Excluding the black-and-white television owners — the "you must be this tall to ride" approach — provides no benefit either.

An appropriate support strategy allows every user to consume as much visual and interactive richness as their environment can support. This approach—commonly referred to as progressive enhancement — builds a rich experience on top of an accessible core, without compromising that core.

Progressive Enhancement vs. Graceful Degradation

The concepts of graceful degradation and progressive enhancement are often applied to describe browser support strategies. Indeed, they are closely related approaches to the engineering of "fault tolerance".

These two concepts influence decision-making about browser support. Because they reflect different priorities, they frame the support discussion differently. Graceful degradation prioritizespresentation, and permits less widely-used browsers to receive less (and give less to the user). Progressive enhancement puts content at the center, and allows most browsers to receive more (and show more to the user). While close in meaning, progressive enhancement is a healthier and more forward-looking approach. Progressive enhancement is a core concept of Graded Browser Support.

What are Grades of Support?

While an inclusive definition of browser support is necessary, the support continuum does present design, development, and testing challenges. If anything goes, how do I know when the experience is broken? To address this question and return a sense of order to the system, we define grades of support. There are three grades: A-grade, C-grade, and X-grade support.

Before examining each grade, here are some characteristics useful for defining levels of support.

Identified vs. Unknown

There are over 10,000 browser brands, versions, and configurations and that number is growing. It is possible to group known browsers together.

Capable vs. Incapable

No two browsers have an identical implementation. However, it is possible to group browsers according to their support for most web standards.

Modern vs. Antiquated

As newer browser versions are released, the relevancy of earlier versions decreases.

Common vs. Rare

There are thousands of browsers in use, but only a few dozen are widely used.

Three Grades of Support

C-grade

C-grade is the base level of support, providing core content and functionality. It is sometimes called core support. Delivered via nothing more than semantic HTML, the content and experience is highly accessible, unenhanced by decoration or advanced functionality, and forward and backward compatible. Layers of style and behavior are omitted.

C-grade browsers should be identified on a blacklist.

Summary: C-grade browsers are identified, incapable, antiquated and rare. QA tests a sampling of C-grade browsers, and bugs are addressed with high priority.

A-grade

A-grade support is the highest support level. By taking full advantage of the powerful capabilities of modern web standards, the A-grade experience provides advanced functionality and visual fidelity.

A-grade browsers should be identified on a whitelist. Approximately 96% of our audience enjoys an A-grade experience.

Summary: A-grade browsers are identified, capable, modern and common. QA tests all A-grade browsers, and bugs are addressed with high priority.

X-grade

X-grade provides support for unknown, fringe or rare browsers as well as browsers on which development has ceased. Browsers receiving X-grade support are assumed to be capable. (If a browser is shown to be incapable — if it chokes on modern methodologies and its user would be better served without decoration or functionality — then it should considered a C-grade browser.)

X-grade browsers are all browsers not designated as any other grade.

Summary: X-grade browsers are assumed to be capable and modern. QA does not test, and bugs are not opened against X-grade browsers.

The Relationship Between A-grade and X-grade Support

A bit more on the relationship between A-grade and X-grade browsers: One unexpected instance of X-grade is a newly released version of an A-grade browser. Since thorough QA testing is an A-grade requirement, a brand-new (and therefore untested) browser does not qualify as an A-grade browser. This example highlights a strength of the Graded Browser Support approach. The only practical difference between A-grade and X-grade browsers is that QA actively tests against A-grade browsers.

Unlike the C-grade, which receives only HTML, the X-grade receives everything that A-grade does. Though a brand-new browser might be characterized initially as a X-grade browser, we give its users every chance to have the same experience as A-grade browsers.

Beyond the Three Grades

In recent years, we have seen a proliferation in tiers of support above and beyond the three grades identified above, where certain subsets of features are implemented only on certain subsets of browsers. Defining and implementing tiers of user experience should be done by each individual project. Overall, we promote the simplest Progressive Enhancement approach possible and discourage projects from creating new tiers without accounting for the additional costs in development, testing, and maintenance resources.

Quality Assurance (QA) Testing

Grading the browser ecosystem enables meaningful, targeted, and cost-effective QA testing. As noted, representative C-grade testing and systematic A-grade testing ensures a usable and verified experience for the vast majority of our audience. A-grade testing must be thorough and complete, while C-grade testing can be accomplished with one or two representative browsers (e.g., Netscape 4.x and Lynx), or by using a modern browser with CSS and JavaScript disabled.

It's worth reiterating that testing resources do not examine X-grade browsers.

Representative testing of the core experience is critical. If you choose to adopt a Graded Browser Support approach for your own projects, be sure your site's core content and functionality are accessible without images, CSS, and JS. Ensure that the keyboard is adequate for task completion and that when your site is accessed by a C-grade browser all advanced functionality prompts are hidden.

Conclusion

Graded Browser Support provides an inclusive definition of support and a framework for taming the ever-expanding world of browsers and frontend technologies.

Tim Berners-Lee, inventor of the World Wide Web and director of the W3C, has said it best:

"Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network."

Updates Archive

This page is the permanent home of the GBS strategy. Updates are publicized on the YUI Blog. You may always reference past updates on the blog via the links gathered here.

From:https://github.com/yui/yui3/wiki/Graded-Browser-Support#about-the-browser-test-baseline-and-operating-systems

Graded Browser Support的更多相关文章

  1. 测试你的浏览器是否支持WebGL(Does My Browser Support WebGL)

    测试你的浏览器是否支持WebGL(Does My Browser Support WebGL) 关于WebGL:WebGL是一种3D绘图标准,这种绘图技术标准允许把JavaScript和OpenGL ...

  2. [TypeStyle] Use fallback values in TypeStyle for better browser support

    You can increase the browser support of your CSS using fallback values and vendor prefixes. This les ...

  3. BAT及各大互联网公司2014前端笔试面试题--Html,Css篇

    很多面试题是我自己面试BAT亲身经历碰到的.整理分享出来希望更多的前端er共同进步吧,不仅适用于求职者,对于巩固复习前端基础更是大有裨益. 而更多的题目是我一路以来收集的,也有往年的,答案不确保一定正 ...

  4. 各大互联网公司前端面试题(HTML/CSS)

    Html篇: 1.你做的页面在哪些流览器测试过?这些浏览器的内核分别是什么? IE: trident内核 Firefox:gecko内核 Safari:webkit内核 Opera:以前是presto ...

  5. 面试题HTML +CSS

    HTML+CSS部分1.行内元素和块级元素?img算什么?行内元素怎么转化为块级元素?行内元素:和有他元素都在一行上,高度.行高及外边距和内边距都不可改变,文字图片的宽度不可改变,只能容纳文本或者其他 ...

  6. 前端Html和Css面试题

    前端Html和Css面试题Html篇:1.你做的页面在哪些流览器测试过?这些浏览器的内核分别是什么? IE: trident内核 Firefox:gecko内核 Safari:webkit内核 Ope ...

  7. 面试题2:BAT及各大互联网公司2014前端笔试面试题:HTML/CSS篇

    BAT及各大互联网公司2014前端笔试面试题:HTML/CSS篇 Html篇: 1.你做的页面在哪些流览器测试过?这些浏览器的内核分别是什么? IE: trident内核 Firefox:gecko内 ...

  8. BAT及各大互联网公司前端笔试面试题--Html,Css篇

    注意 转载须保留原文链接(http://www.cnblogs.com/wzhiq896/p/5931347.html )作者:wangwen896 整理分享出来希望更多的前端er共同进步吧,不仅适用 ...

  9. 第十一章:WEB浏览器中的javascript

    客户端javascript涵盖在本系列的第二部分第10章,主要讲解javascript是如何在web浏览器中实现的,这些章节介绍了大量的脚本宿主对象,这些对象可以表示浏览器窗口.文档树的内容.这些章节 ...

随机推荐

  1. R语言-数据高级管理

    数学函数 abs() 绝对值 sqrt() 平方 ceiling() 向上取整 floor() 向下取整 trunc() 截取整数部分 round(x,digits = n) 保留几位小数 统计函数 ...

  2. OAF_开发系列09_实现OAF预提取LOV设定(案例)

    20150712 Created By BaoXinjian

  3. jsoncpp初使用

    一 前言 由于最近一个c++项目需要使用json这种数据格式来传输数据, so上网去寻找合适的类库,毕竟对于这种不是很新的技术, 自己造轮子有点得不偿失. 从百度上翻了翻, 基本上就boost跟jso ...

  4. Mybatis 批量更新 ORA-00911: 无效字符的错误

    使用<foreach></foreach> 批量insert时报错 ORA-00911: 无效字符的错误 <foreach collection="list&q ...

  5. 同时闪烁多个要素代码(ArcEngine)

    /// <summary> /// 根据查询条件构造/// </summary> /// <param name="where">查询条件< ...

  6. [转]Installing SharePoint 2013 on Windows Server 2012 R2

    转自:http://www.avivroth.com/2013/07/09/installing-sharepoint-2013-on-windows-server-2012-r2-preview/ ...

  7. lombok

    参考http://blog.csdn.net/mlinge/article/details/51340362

  8. 树莓派摄像头模块转成H264编码通过RTMP实现Html输出

    官方原帖 http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=45368&sid=b81f6551e478f0f6e172aa ...

  9. linux svn 用户配置

    1:创建存放仓库的目录 mkdir -p /home/svn/ 2:创建svn仓库 svnadmin create /home/svn/evansource 3:配置仓库(一共三个文件夹auzhz.p ...

  10. PHP性能优化大全(转)

    PHP优化对于PHP的优化主要是对php.ini中的相关主要参数进行合理调整和设置,以下我们就来看看php.ini中的一些对性能影响较大的参数应该如何设置. # vi /etc/php.ini (1) ...