Progressive enhancement and graceful demotion in the CSS3

The two concepts of progressive enhancement and graceful demotion are fire after the advent of CSS3. Because the low-level browser does not support CSS3, but the CSS3 effect is too good to give up, so in the advanced browser to use CSS3, and in the low-level browser

Only the most basic functions are guaranteed. The goal of both is to focus on different experiences under different browsers, but they are different in focus, leading to different workflows.

Progressive Enhancement (Progressive enhancement): Build a page for a low-version browser from the start, complete the basic functionality, and then get a better experience with performance, interactivity, and append functionality for advanced browsers.

Graceful downgrade (Graceful degradation): Build the full functionality of your site from the start, then test and fix it for your browser. For example, the first use of CSS3 to build an application, and then gradually for the large browser hack so that it can be in the lower version of the browser normal browsing.

In traditional software development, the concept of upward compatibility and backward compatibility is often mentioned. Progressive enhancement is equivalent to upward compatibility, while graceful demotion is equivalent to backwards compatibility. Backward compatibility refers to the high version support for the low version or the later developed version support and compatibility with the earlier developed version, very little upward compatible. Most of the software is backwards compatible, for example, Office2010 can open a Word file built office2007,office2006,office2005,office2003, But with Office2003 can not open with office2007,office2010 and other built Word file!

The difference between the two:

Graceful demotion and progressive enhancement are just two points of view of the same thing. Graceful downgrades and progressive enhancements focus on the level of performance of the same website under different browsers in different devices. The key difference is where they focus, and how that attention affects the process of work.

The elegant downgrade point of view is that Web sites should be designed for the most advanced and sophisticated browsers. Test work in browsers that are considered "obsolete" or functionally missing is scheduled in the final stages of the development cycle, and the test object is limited to the previous version of the main browser (IE, Mozilla, etc.). In this design paradigm, older browsers are thought to offer only a "poor, but passable" browsing experience. You can make small adjustments to fit a particular browser. But since they are not the focus of our attention, other differences will be ignored in addition to fixing larger errors.

The progressive reinforcement view is that the focus should be on the content itself. Notice the difference: I didn't even mention "browser" three words. Content is the incentive for us to build our website. Some sites show it, some collect it, some seek, some operate, and some websites even contain all the above, but the same point is that they all involve content. This makes progressive enhancement a more reasonable design paradigm. That's why it was immediately adopted by Yahoo! and used to build its "tiered browser support (graded Browser)" strategy.

Case Analysis:

(1) Code

    . Transition {/* progressive enhancement notation */          -webkit-transition:all. 5s;          -moz-transition:all. 5s;          -o-transition:all. 5s;             Transition:all. 5s;    }    . Transition {/* Graceful downgrade notation */              transition:all. 5s;           -o-transition:all. 5s;         -moz-transition:all. 5s;      -webkit-transition:all. 5s;    }

(2) Prefix CSS3 (-webkit-/-moz-/-o-*) and normal CSS3 in the browser support situation is this:

Long ago: Browser prefix CSS3 and normal CSS3 are not supported;

Not long ago: The browser only supports prefix CSS3, does not support normal CSS3;

Now: The browser supports both prefix CSS3 and normal CSS3;

Future: The browser does not support prefix CSS3, only supports normal CSS3.

(3) Progressive enhancement of the wording, priority to the availability of the old version of the browser, and finally consider the availability of the new version. In the case of the time 3 prefix CSS3 and normal CSS3 are available, the normal CSS3 will overwrite the prefix CSS3. Elegant downgrade, the first consideration of the availability of the new version of the browser, and finally consider the availability of the old version. In the case of the time 3 prefix CSS3 and the normal CSS3 are available, the prefix CSS3 will overwrite the normal CSS3.

In the case of CSS3, I'm more of a progressive approach. Because some properties of the prefix CSS3 may be implemented in the browser in a way that is not the same as the normal CSS3 implementation, the result is that the normal CSS3 will prevail. If you're curious what the attributes are in the prefix CSS3 and the normal CSS3, the explicit effect is not the same.

(4) How to choose

Make your decision based on the version of the client that your users are using. Please note my wording, I do not use the browser, but with the client. Because the concept of progressive enhancement and graceful demotion is essentially a compatibility choice between low-version software and high-version software in the software development process. Server-side programs rarely have this problem, because developers can control the version of the server running the program, it does not matter the gradual enhancement and graceful degradation. But the client program is not what the developer can control (you can't always force users to upgrade their browsers). Our so-called client, can refer to the browser, mobile terminal equipment (such as: mobile phones, tablets, smart watches, etc.) and their corresponding applications (browser corresponding to the website, mobile terminal equipment corresponding to the corresponding app).

Now there is a very mature technology that allows you to analyze the version scale using your client program. If the lower version of the majority of users, of course, preferred the progressive development process, if the majority of high-level users, in order to improve the most users experience, it is of course preferred to use the elegant downgrade of the development process.

But what about the facts? The vast majority of large companies adopt a progressive approach, as business first and the user experience is never top of the line. For example: Sina Weibo website front-end update, with this million-level users of the site, it is absolutely impossible to pursue a special effect without considering the low version of the user can not be used, must be to ensure that the low version to the high version of accessibility, and then to gradually enhance the new features to provide users with a better user experience. But there is no counter-example. If you're developing a teenager-oriented software (or website), you know that people in this group always like to try new things, always like cool effects, and always like to update their software to the latest version (unlike our older users). In the face of this situation, the incremental development process is an election.

The above content is CSS3 in the gradual enhancement and graceful downgrade explanation, hope can help everybody.

What is the difference between progressive enhancement and graceful demotion?

About progressive enhancement and graceful downgrade _html/css_web-itnose

A brief talk on _javascript techniques of JavaScript progressive enhancement and smooth degeneration