This chart lists browsers that receive A-grade support as defined by Graded Browser Support. All YUI projects, including YUI 2 and YUI 3, aim to provide full A-grade support.

C-Grade Browser List (Draft)

This list represents browsers from which CSS and JavaScript should be withheld. This list is in draft status. Discussion of the C-Grade list and the A-Grade matrix takes place in the comments section of the latest GBS update.

• IE < 6 (including Mac OS versions)
• Safari < 3
• Firefox < 2
• Opera < 9.5
• Netscape < 8

We recommend testing your C-Grade experience in one of the above browsers or in a modern browser with JavaScript and CSS disabled. As part of your standard QA process, verify that JavaScript and CSS resources are withheld from the above browsers based on user agent.

GBS Updates Archive

This page is the permanent home of the current A-Grade chart. Updates are publicized on the YUI Blog. You may always reference past updates on the blog via the links gathered here.

• GBS Update, 2009 Q4
• GBS Update, 2009 Q3
• GBS Update, 2009 Q1
• GBS Update, 2008 Q3
• GBS Update, 2008 Q1

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 prioritizes presentation, 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-, C-, 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.

The 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 are 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 are 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 include all browsers not on the C-grade blacklist or the A-grade whitelist

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- and X-grade Support

A bit more on the relationship between A 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 and X-grade browsers is that QA actively tests against A-grade browsers.

Unlike the C-grade, which receives only HTML, 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.

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 regime for your own web applications, be sure your site’s core content and functionality is 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.

In 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.”

Incoming search terms:

• list of yahoo grade a browsers
• yui grade browser
• yui graded browser support chart
• yui upload text file edit

• Screen size: You have a much smaller canvas;
• Input devices: Mobile devices generally do not have mouse input, and therefore are missing some or all mouse events (like mouseover);
• Processor power: Mobile devices have slower processors that can more easily be saturated by JavaScript and DOM interactions — and processor usage affects things like battery life in ways that don’t have analogues in desktop browsers;
• Latency: Most mobile devices have a much higher latency on the network than do terrestrially networked PCs; this can make pages with many script, css or other types of external files load much more slowly.

There are other considerations, many of them device/browser specific (for example, current versions of the iPhone’s Safari browser do not support Flash). The goal of these sections on YUI User’s Guides is to provide you some preliminary insights about how specific components perform on this emerging class of mobile devices. Although we have not done exhaustive testing, and although these browsers are revving quickly and present a moving target, our goal is to provide some early, provisional advice to help you get started as you contemplate how your YUI-based application will render in the mobile world.

This article sponsored by San Diego dentist

Incoming search terms:

• yui mobile
• yui for mobile
• mobile yui
• yahoo ui mobile
• YUI and mobile
• yahoo yui mobile
• yui mobile app
• yui and mobile support\
• yui mobile?
• yui mobile support

YUI Loader adds value in the following ways:

1. Reliable, sorted loading of dependencies: YUI comprises more than two-dozen components, many of which work together to provide the best possible compromise between compartmentalization and code reuse. Because of this, YUI components often need to load with specific dependencies in a specific order. YUI Loader understands which components depend on one another, and based on this knowledge it ensures that the right resources are loaded in the right order.
2. Safe, efficient mechanism for adding new components to a page on which YUI may already be present. Often as developers we write modules that can live in many contexts. In writing a module, we may need to support a variety of scenarios — the module may be introduced into a page on which all of its YUI dependencies are already present, a page on which some but not all are present, or a page on which no YUI content exists at all. YUI Loader looks at the environment as it exists on the page and pulls in only the additional files your module needs to function.
3. Automatic use of rolled-up files. YUI Loader knows about all of the built-in rollup files that ship with YUI — like the yahoo-dom-event.js file that contains the Yahoo Global Object, the Dom Collection, and the Event Utility, three components that are commonly used together. By automatically using rolled-up files when it makes sense to do so, the YUI Loader helps you reduce HTTP requests and thereby keep your page as efficient as possible.

As you think about how you want to load YUI on the page, you may find it useful to refer to this overview of some of the most common loading strategies and their relative merits:

• “Loading YUI: Seeds, Core, and Combo-handling”, by Eric Miraglia on YUIBlog

Note: It’s important to emphasize that any client-side loading utility is expected to be somewhat less performant than solutions that write <script> and <link> elements directly to the page. The use of dynamic <script> and <link> nodes provides good performance and a useful mechanism for bringing in additional JavaScript or CSS after the page has loaded, but for optimal performance you may still wish to write CSS <link> elements to the head of the page and JavaScript <script> elements to the bottom of the page during its initial load.

1. Multiple file selection in a single “Open File” dialog.
2. File extension filters to facilitate the user’s selection.
3. Progress tracking for file uploads.
4. A range of available file metadata: filename, size, date created, date modified, and author.
5. A set of events dispatched on various aspects of the file upload process: file selection, upload progress, upload completion, etc.
6. Inclusion of additional data in the file upload POST request.
7. Faster file upload on broadband connections due to the modified SEND buffer size.
8. Same-page server response upon completion of the file upload.

Important Issue: Due to a current bug, the current version of uploader.swf hosted on yui.yahooapis.com in the YUI 2.8 branch is NOT compatible with the uploader.js hosted on yui.yahooapis.com. Until the next bugfix release, you can work around this issue by either locally hosting the older version of uploader.swf (available here), or locally hosting the uploader.js and making the following changes to it:

• On line 509, in swfObj.addVariable("elementID", swfID);, replace “elementID” with “YUISwfId”.
• On line 512, in swfObj.addVariable("eventHandler", "YAHOO.widget.FlashAdapter.eventHandler");, replace “eventHandler” with “YUIBridgeCallback”.

Important usage notes:

• Because of security changes in the upcoming Flash Player 10, the UI for invoking the “Browse” dialog has to be contained within the Flash player. Because of that, this new version of the Uploader is NOT BACKWARDS COMPATIBLE with the code written to work with the previous version (it is, however, compatible with Flash Player 9). Do not upgrade to this version without carefully reading the documentation and reviewing the new examples.
• The Uploader Control should always be served from an HTTP server due to Flash Player’s restricted local security model.
• The Uploader Control requires Flash Player 9.0.45 or higher. The latest version of Flash Player is available at the Adobe Flash Player Download Center.

Note: The Uploader Control is being released as a beta component. Please refer to the FAQ for what we mean by this designation. We look forward to your feedback in the YUI Forums.

Incoming search terms:

• william duff uploads
• yui 2 upload
• yui 2 uploader
• yui flash uploader size limitation
• yui html5 file upload
• yui upload on ios
• yui uploader on iphone
• yui2 uploader example
• yui2 uploader not working

The Rich Text Editor interface with the default YUI Sam Skin applied.The Rich Text Editor is a UI control that replaces a standard HTML textarea; it allows for the rich formatting of text content, including common structural treatments like lists, formatting treatments like bold and italic text, and drag-and-drop inclusion and sizing of images. The Rich Text Editor’s toolbar is extensible via a plugin architecture so that advanced implementations can achieve a high degree of customization.

In order to give you the greatest possible control over the size and performance of the Rich Text Editor codebase, we provide two versions of the Editor module and two versions of the buttons that live on the Toolbar:

* Editor: Editor contains all features described on this page;
* SimpleEditor: SimpleEditor contains a subset of Editor’s features. (See “Choosing Between Editor and SimpleEditor” for more details.)
* ToolbarButtonAdvanced: The advanced Toolbar buttons are based on YUI Buttons; they are more richly featured at the cost of more dependencies.
* ToolbarButton: The more simple Toolbar buttons have fewer dependencies and so are lighter on the page; they do not support progressive enhancement nor menu-button functionality. (See “Changing the Toolbar” for more about your Toolbar choices.)

Choose the right combination of features in your Editor and Toolbar to get the right tradeoff between size and richness for your application.

Incoming search terms:

• rich formatting toolbar vector
• yui editor change title
• yui 2: rich text editor
• customise yui2 text editor
• yui2 rich text editor content change
• yui rich text editor all buttons
• yui editor
• yui 2: rich text editor change the title
• user interface for text editors
• text ymfs

Known Subclasses:

YAHOO.util.ColorAnim

Events

onTween

onTween ( )