TVs. Consoles. Projectors and accessories. Technologies. Digital TV

Principles of responsive web design. What is graceful degradation in web design? CSS Gradual Degradation Techniques

From the author: The -webkit- prefix is ​​so common in CSS today that some sites refuse to work correctly without it. While vendor css prefixes have been a clear sign of less-than-perfect properties for developers over the past couple of years, this has led Mozilla to take a desperate but necessary step. In Firefox 46 or 47 (released in April or May 2016), Mozilla plans to introduce support for a series of non-standard –webkit- prefixes to improve browser compatibility with that prefix (even on mobile devices).

The idea is not new Microsoft Edge also supports various -webkit- prefixes for compatibility. Opera began supporting -webkit- prefixes in 2012, and then switched to the Webkit Blink engine. W3C and browser developers did not intend to use given prefix in website development:

“Official W3C policy states that experimental properties should not be used in site code. However, people use them because they want their sites to use the latest technology and look cool."- W3C page on content optimization for different browsers

However, developers always want to have access to the latest features as quickly as possible. Vendor prefixes turned everything upside down and gave Webkit dominance, but I believe prefixes had a huge impact on the rapid development of the Internet.

Mozilla and Microsoft's methods will only harm most sites. Most sites will already have –moz- prefixes enabled, or will find that with the new update, Mozilla will support the new properties without the need to make changes. However, as professional web developers, we need to put this to rest and understand that some designs may produce mixed results. You may already know which of your projects will be destroyed by this update. Web developers, it's time to rethink your approach to vendor prefixes and testing them on sites.

New prefixes

Mozilla is going to include a number of –webkit- prefixes. From what I've gathered it appears that Mozilla has no intention of matching their list with Edge properties. Not all properties need to be compatible with the Mozilla engine. Among the prefixes that Mozilla is going to add, judging by the Compatibility/Mobile/Non Standard Compatibility wiki page, are the following:

Webkit - for gradients

Webkit-transforms

Webkit-transitions

Webkit-appearance

Webkit-background-clip

Webkit-device-pixel-ratio

Webkit-animation

Some other properties may be in @-webkit-keyframes.

Cross-browser testing will be critical

If you, a web developer, did not include the -moz- prefix so as not to test new CSS properties in Firefox, and the deadline is approaching, and the client forces you to add this prefix, then you will have to retest the site in Firefox 46 or 47. These versions will be released in April or May, so you still have some time.

To test your website without waiting for Firefox 46/47, you can enable these changes in Firefox Nightly by setting layout.css.prefixes.webkit in about:config. If you have the latest version of Nightly installed, the default should be true. Not all changes to –webkit- prefixes work in Firefox Nightly yet, but they do. good platform to test what your site will soon look like. I would wait until March before seriously testing the site in Firefox Nightly.

Much more importantly, Microsoft Edge already interprets and displays -webkit- prefixes in a similar way. This means that any WebKit styles on your site are already displayed in a browser that was completely unexpected. If you have not yet worked with this browser, then install Windows 10 and get access to it to test sites.

Vendor prefixes are gradually disappearing

Fortunately, vendor prefixes are gradually disappearing as development teams find new solutions. The Chrome/Blink team changed their approach a bit:

"Going forward, instead of enabling vendor prefixes by default, we will keep the regular properties behind the 'enable experimental web platform properties' flag in about:flags until those properties are enabled by default."— The Chrome/Blink Team

The Firefox team followed a similar path: “The main direction of work at Mozilla now is moving away from vendor prefixes, by disabling them or transferring them to the state of regular properties if they are already stable. This is at least ours general policy, individual cases deserve exceptions. »— Boris from Mozilla

Microsoft Edge is also targeting the removal of prefix support: “Microsoft is also trying to get rid of vendor prefixes in Edge. This means that developers, when using special HTML5 tags or CSS properties no need to add a special prefix for Edge browser. Instead, developers will write standard code."— Mashable

Graceful degradation using prefixes no longer works

Moving away from vendor prefixes means only one thing – the technique of graceful degradation through prefixes is no longer an option. Isolating specific browsers through vendor prefixes (for example, for Chrome) was not the purpose of these prefixes; Developers have always been encouraged to use all prefixes (–webkit- to –o-). If you are using any functionality that works on properties with vendor prefixes, and have also used the graceful degradation technique in your design for other browsers, then this no longer works.

Conclusion

Times are changing. WebKit's dominance was unintentional and caused commotion and incompatibility on the Internet. Other browsers are looking to extend compatibility by adding –webkit- prefixes. Gradually, with the disappearance of vendor prefixes, the this problem. Developers should check whether the use of prefixes does not cause undesirable consequences in non-WebKit browsers.

I'm confused about what the difference is between Gradual Increase And Graceful Degradations. I think it's the same thing.

could you explain to me the difference between the two and in what situation would I use one over the other?

8 answers

They are almost the same, but they are different in context.

There is a class of browsers called "class A browsers". These are your typical audience members, who (probably) make up the majority of your visitors. You'll start with a base level of these users. Let's call it best modern practices.

If you want increase experience for those who happen to be using FF3.6 or Safari 4 or some other developer whizbang nightly webkit whathaveyou you want to do amazing things like

  • rounded corners via css
  • shaded text (but please God, not too much)
  • drop shadows (see above in parentheses)

This makes your site look kick-ass, but won't break it. This gradual increase. Embracing the future from a perspective best practices.

on the other hand, your niche Nintendo site attracts a fair number of IE5 users. Poor you, but you also want to make sure they keep coming back. You can provide an alternative to your ajax behavior by including an ajax script in an external file, and if their JS is not included, it's possible your links refresh the entire page. So on. From the point of view best modern practices, you will see that some historical markets are served some semblance of a functional website. This graceful degradation.

They are basically identical, but differ in terms of priority for many development teams: PE is quite nice if you have the time, but GD is often necessary

If your site looks equally good in all browsers, but some browsers get, say, dancing ponies because they support dancing ponies, then that's progressive enhancement. It works in all browsers, but some browsers get something extra. Typically the term is applied to certain Javascript features that can enhance usability beyond "raw HTML".

If your site only looks the way you're going to in browsers that fully support, say, CSS3 and IE8 will display the same page without, say, rounded corners, then that's a graceful degradation. The site is indeed designed for modern browsers, but it is still usable in older browsers, just not as fancy.

after all, they are really the same thing, viewed from two different points of view.

direction from the selected one base The concepts are different for everyone.

graceful degradation begins at the ideal user experience level and decreases based on user agent capabilities to a minimum level, serving agents that do not support certain features used by the baseline.

progressive enhancement starts at a broad minimum consumer experience and increases based on the consumer agent's capabilities to a more capable level, catering for agents supporting more advanced functions than the basic ones.

I think both concepts could be used if time/budget allows. If not, graceful degradation is preferable.

Sorry to resurrect something that's over a year old, but felt I could contribute, in some way, my own opinion on the matter.

While I agree with Alex Mcp and deceze in some ways, the terms "graceful degradation" and "progressive improvement" have a slightly different meaning than what I stand for.

graceful degradations, a lot of the time (in my opinion) it seems to be more of a stick to beat an app in presentation after it was built poorly in the first place in my experience. Like someone builds some huge javascript object that gives the user something really cool to play with until a manager comes, checks the thing, and everyone runs screaming, throwing their hands up when it comes to their attention that their application does not work in 35% of browsers. "someone better provide a fallback for this."

Gradual Increase although (and this is such a good term to say too) it would seem more about creating something that just works, on entry level, everywhere, using the most basic methods available, to provide all the functionality the user needs. This can then be added on with neat little unobtrusive helpers, styling, etc. this actually improves the user experience of the app in question rather than just making it barely usable. "that looks cool. Does it work in IE6. Oh yes. It does"

I think maybe giving style as an example of both terms in the top two answers here kind of misses the real underlying usability issue, which is gradual increase often decides by nature where graceful degradations ignores until everything goes wrong.

The tirade is over...

graceful degradation is the practice of designing web functionality so that it will provide a certain level of user experience in more modern browsers, but it will also gracefully degrade to more low level user in older browsers. This bottom level isn't as nice to use for your site visitors, but it still provides them with the core functionality they came to your site to use; things don't break for them.

progressive enhancement is similar, but does the opposite. You start by establishing a base level of user experience that all browsers will be able to provide when rendering your website, but you also create more advanced functionality that will automatically be available to browsers that can use it.

in other words, graceful degradation starts with status quo complexity and tries to fix for less experience, whereas progressive improvement starts with a very basic, working example and allows for constant expansion for future environments. To degrade gracefully means to look back while to increase progressively means to look forward while keeping your feet on solid ground.

Graceful Degradations

graceful degradations the ability of a computer, machine, electronic system, or network to maintain limited functionality even when much of it is destroyed or disabled. The goal of graceful degradation is to prevent catastrophic failure.

Graceful degradation is one solution. It is the practice of creating a website or application so that it provides a good level of user experience in modern browsers. However, it degrades gracefully on older browsers. The system may not be as nice or beautiful, but the basic functionality will work on older systems.

A simple example is using 24-bit Alpha transparent PNGs. These images can be displayed in modern browsers without problems. IE5.5 and IE6 will show the image, but the Transparency Effects will not work (it can be made to work if necessary). Older browsers that do not support PNG will show alt text or white space.

developers who accept graceful degradation often specify their level of browser support, e.g. Tier 1 browsers ( best experience) and level 2 browsers (degraded experience).

Gradual Increase

gradual increase is a web design strategy that emphasizes accessibility, semantic HTML markup and external style sheets and scripting technologies. Progressive enhancement uses web technology in a layered manner that allows anyone to access the basic content and functionality of a web page using any browser or internet connection, while also providing an enhanced version of the page to those with more advanced browser software or higher bandwidth.

progressive enhancement is similar in concept to graceful decline but in reverse. The website or application will install basic level user experience for most browsers. More advanced functionality will be added when the browser supports it.

progressive enhancement doesn't require us to select supported browsers or revert to table-based layouts. We choose the technology level, i.e. the browser must support HTML 4.01 and standard page requests/responses.

Back to our example image, we can decide that our application should work in all graphical browsers. We could use more low quality GIF images are the default, but replace them with 24-bit png images when the browser supports them.

links

Wikipedia: Gradual Increase And

I haven’t written for a long time, I had to move to a place without the Internet (that’s terrible), as a result of which I couldn’t write in the blog. Today I want to talk about the development (layout) method, which is partially used in the design of my blog.

The latest versions of innovative browsers (such as FF 3.5, Opera 10) have introduced some decorative effects from the proposed CSS 3 specification. Transparency, shadows and the zebra (striping) effect are now available without the use of JavaScript or additional markup. But some older browsers that are still in use don't have these features, and it would be sad to think that you won't have the chance to use these wonderful effects for a few more years.

In this article, I'll talk about how to make nice (incremental) improvements in browsers that support CSS3 features and still provide a satisfying layout for other users.

What is progressive enhancement?

To understand the concept of "gradual improvement", you need to understand the principle of "graceful degradation", which is well described by the following quote:

Mild degradation means that your site continues to work even if viewed in a less than optimal browser in which advanced effects do not work.
Fluid Thinking, by Peter-Paul Koch

"Incremental improvement" uses the same method only from the opposite side, instead of worrying about the site not falling apart in an old browser, you need to think about the content first and simply add features of modern programs to the design to improve the user experience, while the base state layout still works on older machines. This is currently the best way to use the new features of CSS 3.

Example

As an example, let's make a simple navigation menu that will look a little prettier depending on the CSS support in your browser.

I would like to note that in this example I do not use graphics, hacks or browser-specific prefixes - all improvements are due to the declared capabilities. With that in mind, some of the things below are purely for illustrative purposes and may not be best choice in creating real websites.

Marking

Let's make a simple menu using an unordered list (ul):

Basic style

As a base, I will use a style that uses only simple layering selectors. It creates a border for each element and changes the background when hovering the mouse (onmouseover). This should work in any browser made in the last 7-8 years (and possibly more).

The CSS is very simple:

Ul(
background-color: blue;
border-bottom: 1px dotted #999;
list-style: none;
margin: 15px;
width: 150px;
}

li (
background-color: #fff;
border: 1px dotted #999;
border-bottom-width: 0;
font: 1.2em/1.333 Verdana, Arial, sans-serif;
}

li a (
color: black;
display: block;
height: 100%;
padding: 0.25em 0;
text-align: center;
text-decoration: none;
}

li a:hover ( background-color: #efefef; )

The only strange thing here is the blue background

    ; I'll explain this later. With this style, we will have the following basic view, it will display in IE6 like this:

    Basic layout, this is what it will look like in IE6 and other older browsers.

    Applying improvements

    IE7 was the first in the IE series of browsers to support all the attribute selectors from CSS 2.1, which is also common in almost all other browsers. We can use one of them - the child selector - to start improving. Since IE6 doesn't support child selectors, it will ignore the following rules:

    Body > ul ( border-width: 0; )

    ul > li (
    border: 1px solid #fff;
    border-width: 1px 0 0 0;
    }

    li > a (
    background-color: #666;
    color: white;
    font-weight: bold;
    }

    li:first--child a ( color: yellow; )

    li > a:hover ( background-color: #999; )

    With these CSS rules, the list looks like this:

    The menu now has a colored background and bold text, and also the first link is highlighted in a different color.

    This is how IE7, Firefox, Safari and Opera will display the list.

    Let's put more emphasis

    The next step is to increase the emphasis using a property that IE does not recognize: Transparency. We don't need to use special selectors for this, because IE will simply skip the property it doesn't support:

    Li (opacity: 0.9; )

    li:hover ( opacity: 1; )

    The following picture shows how this property works in Opera, you can see that the list items have acquired a slight blue tint from the background

      . On mouseover, each element becomes completely opaque:

      You can of course use IE's own filter property for the same effect in IE. As well as browser-specific prefixes (-moz-, -webkit-) for the properties below. But for educational purposes I'll stick to the CSS standard, since filter is not standard property, then it is not valid.

      Firefox 2 supports transparency, but in later browsers we can go even further. In Safari and Opera, we can decorate text using the text-shadow property:

      Li a:hover ( text-shadow: 2px 2px 4px #333; )

      As the following image shows, the element has a slight shadow on hover and appears to protrude slightly from the page:

      Finally, you can take care of full support from Opera new CSS 3 selectors and add another layer of improvements: background color variables using the nth-child selector:

      Li:nth-child(2n+1) a ( background-color: #333; )

      li:nth-child(n) a:hover (
      background-color: #aaa;
      color: #000;
      }

      li:first--child > a:hover ( color: yellow; )

      We will see a striped menu in Opera:

      Summary and conclusions

      The picture below shows how the initial markup looks in IE6, IE7, Firefox, Safari and Opera, after applying CSS rules described in this article. As you can see, as browser support for CSS becomes more sophisticated, menus become more stylish and complex, and using incremental enhancement techniques, menus remain functional even in very old browsers.

      Of course, many browsers have a string of other properties that I haven't covered here but that can be used, such as RGBA colors and SVG as background colors.

      Certainly, Internet Explorer contains a large number of errors in different versions, but with the help of conditional comments you can fight them, achieving their elimination. But what nothing can fix is ​​that IE is hopelessly outdated. While other browsers include more and more CSS3 properties and support various newfangled technologies, IE is marking time. The release of IE9 will not solve the problem, previous versions this will not evaporate overnight. In such a situation the best solution There will be graceful degradation - the principle of maintaining performance when some functionality is lost.

      Let's look at this technique with a small example, in which text is displayed in a block and a button. The block and button have rounded corners, and a small shadow is also added to the block. So far, browsers for CSS3 mainly use specific properties with their own prefixes:

      • Firefox - properties starting with -moz-;
      • Safari and Chrome - properties starting with -webkit-;
      • Opera - properties starting with -o-.

      Different versions of these browsers can understand some properties both with and without a prefix, so for universality they add several properties at once. So, to create rounded corners we need the following style.

      Moz-border-radius: 10px; /* For Firefox */ -webkit-border-radius: 10px; /* For Safari and Chrome */ border-radius: 10px; /* For Opera and IE9 */

      Although using these properties will result in invalid CSS code, in this case work is more important V Firefox browsers 1.0, Safari 3.1, Chrome 2.0, Opera 10.50, IE9, as well as their older versions. Example 1 shows how to use CSS3 properties to create shadows and rounded corners.

      Example 1. Block with shadow

      XHTML 1.0 CSS 2.1 CSS3 IE 8 IE 9+ Cr Op Sa Fx

      Block

      You need to go through 20 questions that are randomly selected from the database. To pass the test, it is enough to correctly answer at least 75% of the proposed questions (15 or more questions).



      The result of the example is shown in Fig. 1.

      Rice. 1. Block view in Safari

      The same example in the IE8 browser and below is shown in Fig. 2.

      Rice. 2. Block view in IE8

      Although the appearance of the elements differs in detail, the functionality of the page as a whole remains the same. The button can be clicked, the text remains the same, including its color and background, and there are no display errors. In fact, the difference is only in the little things that perform decorative rather than practical functions. All principles of graceful degradation are fulfilled.

      What does this approach give in practice?

      • Allows you to actively use decorative properties of CSS3 without regard to the browser.
      • Motivates to use various CSS3 effects.
      • It makes the developer’s life significantly easier, since he no longer has to look for solutions for outdated browsers.
      • Speeds up work productivity.

      Of course, graceful degradation is not always applicable. If the layout requirements indicate support for older versions, then you will have to look for alternative solutions, for example, use images for rounded corners. But for the most part, requirements for layout are set without taking into account the general situation. And if we compare all the advantages of graceful degradation with the disadvantage, which manifests itself only in the fact that outdated browsers, in particular IE8, do not display the page “beautifully” enough, then sympathies will be on the side of progress.

      The web design industry is constantly changing, partly because web browsers and devices are constantly changing. Since the work we do as web designers and developers is viewed through a web browser, our work will always have a symbiotic relationship with that software.

      Changes in web browsers

      One of the challenges that website designers and developers have always faced is not only the changes in web browsers, but also the range of different web browsers that will be used to access their websites. It would be great if all website visitors used the latest and greatest software, but this has never been the case (and probably never will be).

      Some visitors to your sites will view web pages with very outdated browsers and missing features from more modern browsers. For example, older browser versions Microsoft Internet Explorer has long been a problem for many web professionals. Even though the company has dropped support for some of its oldest browsers, there are still people who will use them - people you might want to do business with and communicate with.

      Definition of "graceful degradation"

      The reality is that people who use these outdated web browsers often don't even know that they have outdated software or that their online experience may be compromised due to their software choices. To them, this outdated browser is simply what they have been using for a long time to access websites. From a web developer's perspective, we want to make sure we can provide these customers with a rewarding experience while also building websites that work great in the more modern, feature-rich browsers and devices available today.

      "Graceful Degradation" is a web page design treatment strategy for different browsers, both old and new.

      Starting with modern browsers

      Designed to degrade over time, the website is designed with modern browsers in mind. This site is designed to take advantage of the capabilities of these modern web browsers, many of which "automatically update" to ensure that people always use latest version. However, websites that degrade gracefully also work effectively on older browsers. When these older, less functional browsers view the site, it should degrade while it is still functional, but perhaps with fewer features or other visual display elements. Although this concept of providing a less functional or not very attractive website may seem strange to you, the truth is that people won't even know that they are missing. They won't compare the site they see to the "better version", so as long as the site does what they need and doesn't appear to be broken either functionally or visually, you'll be in good shape.

      Progressive Improvement

      The concept of gradual degradation is similar in many ways to another web design concept you may have heard of - progressive enhancement. The main difference between a progressive deterioration strategy and a progressive improvement strategy is where you start your design. If you start with the lowest common denominator and then add features for more modern browsers to your web pages, you are using progressive enhancement. If you start with the most modern, cutting-edge features and then scale down, you will be exploiting gradual degradation. In the end, the resulting website will likely provide the same experience whether you use progressive enhancement or gradual degradation. Realistically, the point of either approach is to create a site that works great for modern browsers, while still providing a seamless experience for older web browsers and the clients that continue to use them.

      Graceful degradation doesn't mean you're telling your readers, "Download the latest browser"

      One of the reasons many modern designers don't like the graceful degradation approach is that it often devolves into requiring readers to download the most up-to-date browser for the page to work. This is not graceful degradation. If you want to write “download browser X for this feature to work,” you're leaving the realm of incremental deterioration and moving into browser-centric design. Yes, it's certainly useful to help a website visitor upgrade to a better browser, but it's a frequently asked question (remember, many people don't understand how to download new browsers, and asking them to do so can be downright intimidating). them away). If you really want their business to tell them that they are leaving your site to download better software, it probably won't be possible. Unless your site has key functionality that requires a specific browser version or higher, forcing downloads often breaks the user experience and should be avoided.

      A good rule of thumb is to follow the same rules for gradual deterioration as for progressive improvement:

      • Write valid, standards-compliant HTML
      • Use external style sheets for your design and layout
      • Use externally linked scripts for interactivity
      • Ensure content is accessible even to low-end browsers without CSS or JavaScript

      With this process in mind, you can go out and create the most modern design you can! Just make sure it works in less feature-rich browsers while still working.

      How far back do you need to go?

      One question that many web developers have is how far back you should support browser versions. There is no precise and dry answer to this question. It depends on the site itself. If you look at a site's traffic analytics, you will see what browsers are being used to visit that site. If you see a significant percentage of people using a certain more old browser, then you probably want to support this browser or risk losing this business. If you look at your analytics and see that no one is using more old version browser, you can probably decide not to bother fully supporting and testing this legacy browser. So the real answer to the question of how far back your site needs support is "no matter how far back your analysts tell you what your customers are using."

      Edited by Jeremy Girard.



Share with friends:
Related publications