A set of cross-browser CSS3 properties. Crossbrowser CSS3, or how to deal with Internet Explorer Css crossbrowser

Author's Note: People use different browsers to browse the web. Of course, there are the most popular ones, such as Chrome. There are also less used ones (Safari, Internet Explorer), but if you are making a site for people, you should know about cross-browser compatibility - how to make it and what it is all about. Let's see how to achieve the same display of the site in all major browsers.

The main goal of cross-browser compatibility is to prevent significant changes in the design of the site in different web browsers. If the difference is only in the details and this does not affect the overall perception of the site, then we can say that you have coped with the problem of cross-browser compatibility. But still, what real advice can be given about this?

How to achieve cross-browser compatibility

At the moment, there are 5 main most popular browsers for which you need to optimize the site. And if it is usually easy to make friends with the newest versions of web browsers, then the older the version, the more problems there may be.

For example, IE6 is one of the most problematic browsers in terms of supporting new html tags and css properties. And yet, some today still require the normal display of the site in this browser. As for me, this is already too much. IE8 support is sufficient.

However, this is a small digression. Now let's look at the real steps that will help make the site cross-browser compatible.

Make the most of ready-made solutions. If you want to implement new features and teach old browsers to understand them, you need javascript libraries. Without them, in this case, simply nowhere. You must install jQuery.

There is such a wonderful javascript library called Modernizr. Its capabilities allow you to implement an alternative for those properties that are not supported. That is what I recommend you use.

So, first you need to go to the official website. https://modernizr.com/download. Here you need to tick off the technologies that you plan to use on your site. I must say that the list is quite long and without an average knowledge of modern web standards and English, you can hardly figure it out. In any case, there are also intuitive properties. Even if you tick everything, the resulting code will not be too cumbersome.

Rice. 1. The choice of technologies that the library will check.

Checking the Library

After downloading the custom version of the library, you need to check its operation. It will need to be connected using the script tag, specifying the path to the file. If everything is correct, then the html tag should have many new style classes. These classes are named after the technologies you ticked.

>p?Accordingly, if such a class is specified in the html tag, then the technology works in this browser. If something is not supported, then the “no-technology name” class will be registered. I'll give you an example right now:

For example, you need to check the box-shadow property. For reference, it sets the shadow to the element. If the browser supports it, then this style class will appear in the html tag. If web browsers don't recognize the property, the "no-boxshadow" class will appear.

Rice. 2. In the html tag you will see many classes. In this case, we see that the browser supports almost all technologies.

Now the management of cross-browser compatibility is completely in your hands. It is enough to set some alternative properties to the no-boxshadow class, and in all browsers that do not support the box-shadow property, these rules will be applied instead. It is very comfortable.

On habrahabr, I found another example that I would like to give you here. There was an example of how the library can be used to implement alternatives in older browsers.

Multiplebgs selector ( background-image: url("image.png") center 40px no-repeat, url("image2.png"); ) .no-multiplebgs selector ( background-image: url("image.png") center 40px no-repeat lightgray; )

Multiplebgs selector ( background - image : url ("image.png" ) center 40px no - repeat , url ("image2.png" ) ; ) No - multiplebgs selector ( background - image : url("image.png" ) center 40px no - repeat lightgray ; )

Example explanation. We are interested in the technology of multiple backgrounds, which has been supported in CSS3 for a long time. To do this, it is enough to list the addresses of the pictures and their parameters separated by commas. Naturally, older browsers do not support this, so we write our own styles for them using the .no-multiplebgs class. It specifies that the styles apply if the browser does not support multiple backgrounds.

Thus, it can set other styles for this selector and thus get a beautiful display of the site in any web browsers. Of course, in order to fully experience the possibilities of Modernizr, you yourself need to be well versed in web programming and website layout. An experienced person will be able to determine what properties can replace those that are very poorly supported.

Of course, the functionality of the library is much wider. You can test support for various technologies and chain events to the result at the end. Example.

Cross-browser compatibility is usually understood as the ability of a site to look the same (or equally good) in all browsers.

In order for the site to look as similar as possible in all browsers (modern + support for some outdated ones), you need to know the various tricks and features of browsers. We will now study them.

Block . Modern browsers

The following browsers are currently popular: Internet Explorer (abbreviated as IE, a browser from Microsoft, built into Windows), Opera (Norwegian browser), Mozilla (aka Firefox), Google Chrome (browser from Google), Safari (browser from Apple). Browsers in mobile devices: Android, IOS.

Block . Browser engines

In addition to browsers, there is such a thing as engine browser. The engine is the core of the browser that converts HTML and CSS into a visible image on the screen. There are far fewer engines than browsers and, as a result, many browsers have the same engines and therefore the same features and bugs (problems).

Types of engines: Gecko (Mozilla/Firefox). Webkit (Safari, Google Chrome, Opera 14+, Android, IOS). Presto (Opera up to version 14). Trident (Internet Explorer).

Please note that Opera, starting from version 14, switched to the Webkit engine.

Currently, Webkit has split into two Blink engines from Google Chrome and Opera 14+ and an engine from Safari. These two engines still support the -webkit prefix, however, their separation can already be seen on some CSS properties, such as hyphens

The Internet Explorer browser officially no longer exists, its latest version is 11th. However, in fact, this browser has changed its name (but not the engine) and is now called Edge.

Block . Vendor prefixes

The current situation among browsers is that before a CSS property appears in the specification, browsers can implement a trial version of that property with a special prefix called vendor prefix(from the word vendors - developers, developer prefix).

How it looks like, let's look at the example of the box-sizing property (changing the box model).

P ( box-sizing: border-box; )

This property has only been supported since Firefox 29, but since Firefox 2 it has been available with the -moz prefix:

P ( -moz-box-sizing: border-box; )

Other browsers have similar prefixes: -moz - Mozilla/Firefox (Gecko engine), -webkit - Webkit engine browsers (Google Chrome, Safari, Opera 14+, Android, IOS), -o - Opera up to version 13 inclusive (Presto engine) ), -ms - IE from version 8+.

Thus, the most cross-browser version of the box-sizing property, using vendor prefixes, will look like this (you don’t need to write it with the -ms prefix, IE immediately switched to support this property):

P ( -webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box; )

In CSS, many properties have a similar implementation, with and without a prefix.

Please also note that Opera switched to Webkit from version 14 and now it will use the -webkit prefix, while the -o prefix will remain only for older versions (up to 14).

There is the following rule: prefixed properties are written before unprefixed properties. This is done so that the main property overwrites properties with prefixes, since the browser can support a property with or without a prefix. And a property with a prefix can work with any problems.

Currently, some browsers have decided to abandon prefixes due to their inconvenience. And now instead of them they use the so-called flags. The properties are now embedded in the browser, but are disabled by default, however, they can be enabled in the browser settings by checking the appropriate box in the settings. Google Chrome and Opera browsers currently support this model for the new properties.

Block . Where to see what prefixes to write

I recommend a special service caniuse.com, where you can see what properties can already be used and whether you need to write prefixes for them or not.

Block . Browser Statistics

In order to know which browser should be currently supported and which one should be abandoned, it is necessary to track statistics on browsers in the region of the site. This can be done using the following service: gs.statcounter.com - all browsers with versions by country (english).

Block . How to test a site in different browsers

After creating the site, it must be tested in all popular browsers. However, doing this is not as easy as it seems - not only do browsers differ from version to version, there are also differences between one version of the browser on Windows and, for example, Linux. It is clear that it is simply impossible to have such a number of browsers.

Special services come to the rescue, which take screenshots of the site in different versions of the site.

Block . Style normalization

In addition to resets, there is a so-called normalization- this is when the values ​​​​of properties (for example, margin and padding) are not reset to zero, but certain convenient values ​​\u200b\u200bare indicated to them (so that in all browsers the default indents are the same and convenient).

Remember to reset styles before connecting your styles, not after!

CSS Reset should be placed in a separate file (usually called reset.css). In this case, you can use it in different projects without making any effort to separate it from other CSS rules.

Feel free to modify reset.css itself. Customize it for you, make it work for you. Change, rearrange, remove and add as needed in your particular case.

It makes sense to add default styles for h1-h6 (like font size), for td (make text-align: center), etc.

What do you do next:

Start solving problems at the following link: tasks for the lesson.

When everything is decided - go to the study of a new topic.

Hello dear readers!

We all want our styles to be correctly displayed in different browsers. But whatever one may say, you will have to add styles so that they work in other browsers. This process is called - bringing the layout of the site to a cross-browser view. Cross-browser compatibility is when css styles are correctly displayed in different browsers and their different versions.

I want to give some tips to the process of bringing your CSS to cross-browser compatibility took less time.

Focus on the most popular browsers. Browser ratings can be found on the web. It is also worth considering the region of the site's audience. For example, if this is a site for an audience from Africa, then not Chrome, but another browser already prevails here. Also, during the layout process, it is worth looking at how the site looks in those browsers that take 2nd and 3rd place.

2. You can search for the most popular css styles, which do not look right in other browsers. Find CSS hacks for them.

3. There are special tools on the net for generating cross-browser styles. I want to highlight the 2 most interesting in my opinion.

Tools for cross-browser CSS.

• Many styles have been described;
• There is an example of use with the result.

• It is difficult to navigate the site at first;
• It is impossible to generate a style with its own parameters (an example of use is given).

CSS3 Generator

• Convenient and intuitive to operate;
• You can generate styles for your parameters;
• You can see the result of the generated style.

• Few styles

When CSS is used not only for text decoration, but also for working with layers in a tableless layout, it must be remembered that modern browsers do not treat such important parameters as margin - the outer margin of the element, padding - the inner margin of the element, as well as the position parameters - position , float - text wrapping and a number of others.

Due to these differences in the interpretation of parameter values, it often happens that sites and web interfaces that look fine in Mozilla Firefox, Opera and Safari browsers suddenly start to move apart in Internet Explorer.

At the heart of these differences in how browsers interpret CSS is the incomplete conformance of Internet Explorer browsers prior to version 7 with the CSS standards adopted by the W3C. Therefore, successful tableless layout for earlier versions of IE than 7 requires the use of a number of special constructs called CSS hacks. It's also important to note that other browsers sometimes need to use a CSS hack.

Consider writing CSS that would only be interpreted by certain kinds of browsers:

Document table of contents

CSS for IE 5, 5.5, 6, 7 Conditional Comments IE browsers have long supported so-called Conditional Comments, which allow you to make content visible only to IE. Conditional comments are simply specially formed HTML comments that only certain versions of Internet Explorer for Windows understand. For example, you can use conditional comments to fix a PNG transparency bug in IE.

To use them you need:

First, create a common style sheet for all browsers, without any hacks, so that later we can continue to work on fixing errors when displaying the page in IE.

The bug-fixed stylesheet is then saved separately and becomes the stylesheet for all versions of IE (for example, all-ie.css).

Save the style sheets with bug fixes separately for each version of IE (eg ie-5.0.css).

The next step is to connect these stylesheets sequentially through the HTML code using conditional comments.

Conditional Comment Syntax The following conditional comment will be understood by IE5, IE5.5, and IE6, as well as IE7 and IE8:

Applying CSS for IE5 If you want to apply a conditional comment for IE5 only, you just need to specify version 5.0 in the IE 5.0 if condition:

Applying CSS for IE5.5 If applied relative to IE5.5, it would look like this:

Apply CSS for IE6 Same for IE6:

Applying CSS for IE5 and IE5.5 Simultaneously or for Multiple Versions If you want to fix a box model bug in IE5 and IE5.5 browsers using conditional comments, you can use the version index part or comparison operators.

The first example will link the stylesheet to any version of Internet Explorer whose first digit is 5:

As an alternative, you can specify that style sheets are included in any browser version less than 6:

Instead of lt (l ess t hen - less), you can also use lte (l ess t hen or e qual to - less or equal), gt (g reater t hen - more), gte (g reater t hen or e qual to - greater than or equal to) the main thing with all this variety of possibilities is to choose the order of specifying conditional comments correctly so as not to get into a situation where, for some browsers, groups of conditional comments intersect, giving an unexpected result.

How to use If you do not want the general style sheets to dominate the tables that are created specifically for IE, then you need to include the general tables first, and only then the tables for IE. For example, it looks like this:

Other Benefits of This Method By using conditional comments, you also get a way to more reliably determine the browser version. Browsers that pretend to be Internet Explorer but aren't really Internet Explorer won't use IE-specific style sheets. With this method, you can compile accurate statistics on what version of IE visitors are using, without errors caused by programs and browsers impersonating IE. Validity Perhaps one of the nicest parts of this technique is that your style sheets and your carefully formatted (X)HTML documents will retain full conformance to the specification. Debugging Conditional Comments There is one caveat worth mentioning.

If you are using multiple versions of Internet Explorer on the same machine, then all of these versions will pretend to be the newest version installed. This means that if you have IE6 installed, but you are viewing the page using IE5, this conditional comment will be executed:

And this conditional comment will not be executed:

For the most accurate tracking of differences in how CSS is handled by different versions of IE, IETester is a well-established free program that supports all versions of IE from 5 to 8. And for quickly changing CSS settings in IE8 by pressing F12, a developer tool is available, reminiscent of FireBug in Mozilla Firefox.

Similar to declaring style sheets, this method can be used to hide HTML code from a specific or all versions of IE. For example, "HTML code" will be displayed in all browsers except IE6 if placed in a conditional comment like this:

HTML code

Tag Keep in mind that conditional comments in IE can be used anywhere on the page, not just to declare style sheets for the corresponding browser version. With conditional comments, you can display some additional information to IE users that is not visible to users of other browsers.

Similar to conditional comments in IE 5--IE 8, the ... tag is supported. This tag allows you to hide information from IE users, thus the code:

This is not Internet Explorer

IE users will be shown as: This is the Internet Explorer browser, and users of other browsers will be shown as This is not the Internet Explorer browser.

The tag is not valid.

IE CSS Hacks To avoid cluttering up your HTML code with multiple stylesheet declarations, or if you want to keep a single CSS file, you can write separate styles that will only work in IE. Moreover, there is an option for both IE6 and IE7.

For IE all versions. If you precede a property with two slashes (//), it will only be read by IE browsers of all versions. Other browsers will ignore this property.

It is possible for IE6 to put a minus (-) or underscore (_) in front of a property without IE7 reacting to it. You can also use the construct:

*html.style(...)

For example:

Style ( background : red; /* for normal browsers */ //background : green; /* for all IEs */ -background : blue; /* for IE6 */ ) * html .style ( background : blue; /* other way for IE6 */ )

In this case, the background will be red in Opera and Firefox browsers, green in IE7, and blue in Internet Explorer 6.

The example changes the background color for different browsers. In practice, this method is used to achieve display identity and cross-browser compatibility. Most often, you have to resort to it when positioning and set different values ​​for properties like left, top, padding, margin, width, and others related to sizes, percentages, and pixels.

For IE7, the CSS hack is:

*: first-child+html .style ( ...)

*+html .style ( ...)

CSS for Firefox There are also special CSS hacks that allow you to show styles only to the Firefox browser.

html: root .style ( ...) /* this one also works for Safari */

Style, x: -moz-any-link ( ...)

To quickly change CSS settings in Firefox by pressing F12, the Firebug developer tool is available (requires pre-installation) - it is the best among analogues.

CSS for Opera CSS hacks for the Opera browser are represented by the following examples:

Cross-browser compatibility is the ability of a site to display correctly in different browsers. The resource must work the same in all browser versions.

This is especially important in the era of responsive web design, when the ability of the front-end to adapt to a wide range of different devices and still provide an optimal viewing experience comes to the fore.

Previously, a designer would create a design layout in Photoshop, which would then be transferred to HTML and CSS. Today, technological changes are forcing to rethink this concept. We can no longer predict which browser, resolution or device will be used to view the site. Gone are the days when most computers used a fixed resolution of 1024 by 768 pixels and it was possible to develop websites with static dimensions.

Modern browsers fully support HTML5 and CSS3. But the same HTML / CSS / JavaScript code is interpreted differently in older browsers, which leads to “cross-browser incompatibility” of the site. This is especially true for older versions of Internet Explorer.

In this article, we will look at current statistics on web page views, provide a list of tools that help solve various compatibility problems.

1. Current situation

Worldwide statistics for 2015 show that the top 14 screen resolutions in use range from 1920 by 1080 to 320 by 480 pixels.

Although Windows 7 (31.20%) still holds a large market share, mobile platforms are beginning to replace traditional desktop platforms.

Looking at the statistics for 2015 on the browsers used, we see that the first place belongs to Chrome (all versions - 44.87% ), the second place is Firefox (all versions - 10.37% ), the third Internet Explorer 11 (6.84 % ).

The accelerated pace of release of new versions of Google Chrome and Firefox allows you to develop projects for these platforms more efficiently. A slightly different picture emerges for the "bad guy" Internet Explorer, because you can still find old versions of it on the Web. And this leads to problems with cross-browser compatibility of the site.

Microsoft ended support for IE6 on April 8, 2014. And from 2016, only the latest version of Internet Explorer will be supported and updated. This effectively means that support for IE7 and IE8 was completely dropped in early 2016, regardless of operating system. IE9 will only be supported on Windows Vista, IE10 on Windows Server 2012 only, IE11 on Windows 7 and Windows 8.1:

As a consequence, development for IE6 and as well as IE7 should be stopped. To justify this strategy, here are a few examples from well-known companies: Google ended support for IE8 in November 2012, and IE9 in October 2013.

Github no longer supports IE 7 and 8. Other than that, part of the Twitter functionality doesn't work in IE8. And finally, the popular framework will not support IE8 starting with version 4.

However, usage statistics may vary by region, with 6.11% of users in China still browsing through IE8 in 2015. If we take into account that there were about 724,400,000 Internet users in China, we can understand that this year, approximately 44,200,000 Chinese people continue to use IE8.

Therefore, regional markets, specific customers and industry requirements may differ significantly. This is especially true for corporate and government agencies.

2. Analyze your audience

The basic principle here is this: the higher the required cross-browser compatibility, the more time it will take to develop, which leads to an increase in the cost of the project. To make an informed, economically sound decision, you need to ask yourself the following questions:

• What is your target audience?
• What geographic region should I target?
• What browsers and devices are your visitors using?
• Are there technical factors within the company or industry that force you to support specific versions of older browsers?
• From an e-commerce perspective, what are the conversion and ROI rates for different user groups across browser versions?

By answering these questions with the help of statistical data, for example, from Google Analytics, you can get an objective picture.

3. Problems in legacy browsers and different development approaches

Responsive web design relies heavily on media queries that change CSS for different screen resolutions. In addition, modern websites are characterized by the use of HTML5 semantic elements (for example, , , , , ) to group design components. CSS3 selectors are used to select specific elements and further style them (eg , :checked , :nth-child(n) , :not(selector) , :last-child)) . Finally, responsive typography is often specified using REM (root em ) units.

This brings us to the following technical challenges when implementing CSS cross-browser:

• CSS3 media queries
• HTML5 Semantic Elements : Not supported in IE6 , 7 and 8 ;
• CSS3 selectors : not supported in IE6 . Only partially supported in IE7 and 8 ;
• REM Units : Not supported in IE6 , 7 and 8 . Only partially supported in IE9 and 10 ;
• CSS rule limit: IE9 and below only support 4095 CSS selectors. Rules after the 4095th selector are not applied.

The above mistakes will have the greatest impact on the strategy used when implementing responsive design.

There are two main development strategies: gradual simplification and progressive improvement.

Progressive Improvement - Based on the principle of starting development with a common denominator, with minimum technical requirements and the level of user experience offered by the site. Visitors accessing the site on the latest browsers and devices will be served a progressively enhanced version of the site with all the latest features.

On the other hand, users of older browsers and slow Internet connections will be offered a graphically truncated, but still functional version of the site.

A similar approach when implementing cross-browser compatibility involves starting development with a simple version, to which more complex elements are then added. Older browsers will be able to display the site with a basic level of user experience. And new HTML/CSS/JavaScript features will be available in browsers that can actually use them.

In contrast, gradual simplification provides a fully functional level of UX in modern browsers. And then gradually reduces its complexity for older browsers at the expense of graphics, but without touching the functionality. The idea is to start development with the latest web standards and then try to minimize the problems associated with older browsers.

Which approach you choose depends on personal preferences and project conditions:

• Progressive enhancement provides more stability as you can gradually add new features for modern browsers. But it requires more careful planning;
• Some developers argue that it makes no sense to support legacy browsers and the latest technologies should be used. Support for modern browsers gives a much better user experience;
• There is an opinion that progressive enhancement is dead because many JavaScript applications do not work properly with this approach;
• Web accessibility for public institutions may be determined by the legal requirements of specific territorial entities, and this may require a special approach.

With the advent of feature detection tools like Modernizr , I'm personally leaning towards using gradual simplification and browser blacklisting when developing compatible sites.

4. Testing, testing, testing…

To detect potential cross-browser JavaScript issues as soon as possible, you need to test your site in various browsers and resolutions during the development process. There are various software emulators that can help us:

• Browserstack is a commercial service that provides access to a test environment where you can test your project on more than 700 desktop browsers and mobile devices using a virtual machine in the cloud;
• Microsoft Virtual Machines - If you're on Linux, you won't have access to Internet Explorer. The solution might be to download IE6 VM images in IE11, which can then be used in conjunction with Oracle VM Virtualbox or Vagrant for local testing;
• Different screen resolutions for a particular browser can be quickly tested using the Screenfly online service. Using browser plugins such as Window Resizer for Google Chrome, or directly from the developer tools section of Chrome and Firefox.

5. Normalize.css and CSS Autoprefixer

I usually start new projects by resetting CSS with Normalize.css , which provides better cross-browser compatibility with HTML element styles up to and including Internet Explorer 8. Normalize.css preserves the desired styles of elements, normalizes their appearance and fixes a number of errors and inconsistencies in various browsers.

In addition, many legacy browsers cannot interpret unknown HTML elements and CSS properties. When the browser encounters a piece of HTML or CSS that it doesn't understand, it ignores it and continues the rendering process. Many applications use vendor prefixes to add new, experimental, or non-standard CSS features before they are implemented in the specification:

// Webkit browsers such as Chrome and Safari -webkit- // Firefox -moz- // Internet Explorer -ms- // Opera -o-

The problem is that prefixes are awkward to use and have a lot of bugs associated with them. So I use the CSS Autoprefixer plugin in combination with Grunt .

Regular CSS rules will be parsed by the plugin and prefixed based on the "Can I Use" database. It is recommended that you specify in the configuration the versions of browsers that you want to support, for example:

options: ( browsers: ["last 2 versions", "ie >= 8", "Firefox >= 12", "iOS >= 7", "Android >= 4"] )

As an example, consider the following CSS class:

Example ( background-image: linear-gradient(top left, #4676dd, #00345b); display: flex; transition: 1s all; )

With the help of CSS Autoprefixer it is converted to:

Example ( background-image: -webkit-linear-gradient(top left, #4676dd, #00345b); background-image: -moz-linear-gradient(top left, #4676dd, #00345b); background-image: linear- gradient(top left, #4676dd, #00345b); display: -webkit-box; display: -webkit-flex; display: -moz-box; display: -ms-flexbox; display: flex; -webkit-transition: 1s all; -moz-transition: 1s all; transition: 1s all; )

6. Conditional comments

If you need to create fallback CSS or enable crossbrowser JavaScript for earlier versions of Internet Explorer, you can use conditional comments. They are supported in Internet Explorer 5-9 and use HTML comment syntax combined with booleans. Depending on the boolean value (true or false ), the code inside the comment tags will be displayed or hidden in the respective browser versions:

CODE TO BE EXECUTED // if Internet Explorer // if NOT Internet Explorer // if Internet Explorer 7 // if NOT Internet Explorer 7 // if Internet Explorer 9 or LOWER // if Internet Explorer 7 or HIGHER // if Internet Explorer 6 OR 7 // if ABOVE Internet Explorer 6 BUT BELOW 9

The code is automatically hidden in all browsers that do not support conditional comments. A prime example of how conditional comments can be effectively used in practice is the HTML5 Boilerplate, which adds specific CSS classes for legacy versions of Internet Explorer:

7. Polyfills

Technical inconsistencies in legacy browsers for responsive web design can be fixed with a polyfill. It is a piece of JavaScript code that "fills in" a specific functional gap between a legacy browser and a feature. There are a number of polyfills that can be used to provide browser support for HTML5 features.

Below are a few polyfills designed to fix the site's cross-browser compatibility issues mentioned in point 3:

• respond.js - implements CSS3 media queries for Internet Explorer 6 - 8;
• html5shiv allows the use of HTML5 semantic elements in Internet Explorer 6 - 8;
• selectivzr - emulates CSS3 selectors and pseudo-classes in Internet Explorer 6 - 8. Full support requires either Mootools 1.3 or NWMatcher 1.2.3 . Partial support is available with jQuery 1.3/1.4 ;
• REM-unit-polyfill - Determines if the browser supports rem units and provides a fallback. Works with IE8 and below.

To use these polyfills, they must be added from the CDN or as a file in the correct format inside the conditional comments in the section (don't forget to include one of the required JavaScript libraries for Selectivizr ):

For each project, you need to evaluate whether these additional scripts are really needed, as they can lead to performance issues. Most polyfills are compact, but each additional script that is loaded is an additional HTTP request. This can slow down page loading.

8. Defining Functions with Modernizr

The Modernizr library, written in JavaScript, will help you check the site's cross-browser compatibility: whether a particular HTML5 or CSS3 function is supported in different browsers. If the feature is not available, alternative CSS or JavaScript code can be loaded.

The idea is to directly detect the functionality of the browser, rather than trying to install a specific version of it. And on the basis of this, derive its functionality, which is a less efficient and reliable way.

It's worth noting that Modernizr doesn't add the missing features to the browser. Therefore, you will need to provide code from a fallback CSS or polyfill.

First you need to download a fully functional assembly. Later, when you're ready to develop, you can create a custom build with the specific features you're testing. All you have to do is add the .no-js class to your site's HTML tag and include the Modernizr script in the head section after any CSS file:

Modernizr Demo Modernizr Demo

This is a Modernizr exercise.

The .no-js class is used to check if JavaScript is enabled in the user's browser. If enabled, Modernizr will replace .no-js with the .js class. The Modernizr testing feature analyzes whether a particular feature is supported in the browser and generates a set of classes that are added to the HTML element. Google Chrome 47.0.2526.111 for example will return the following object classes.

Modernizr is currently available as a global object that can be called in conjunction with a function name to check if it exists. It returns a boolean value (true or false ).

Let's look at two simple CSS and JavaScript examples.

Crossbrowser CSS Problem Solving Example: Checking for SVG Support and Providing PNG as a Fallback

The current trend is to use SVG (Scalable Vector Graphics) more and more, but these graphics are not supported in IE8 and below. If SVG is supported in the browser, Modernizr generates the .svg CSS class. If SVG is not available, the tool adds the .no-svg class to the HTML. With the CSS below, SVG-enabled browsers will use the normal .logo class, while non-SVG-enabled browsers will use the .no-svg rules:

Logo ( background-image: url("logo.svg"); width: 164px; height: 49px; ) .no-svg .logo ( background-image: url("/logo.png"); width: 164px; height :49px; )

JavaScript Example: Defining border-radius and Adding Appropriate CSS Classes

Rounding frame corners is not supported in IE8 and below. We can create different CSS classes that are applied depending on the presence of the border-radius function:

// Class for browser with border-radius function .round-borders ( border-radius: 5px; ) // Class for browser without border-radius function .black-borders ( border: 3px solid #000000; )

Now we can use JavaScript to store the target id as a variable and then add the CSS classes via a conditional:

var element = document.getElementById("TestID"); if (Modernizr.borderradius) ( element.className = "round-borders"; ) else ( element.className = "black-borders"; )

Conclusion

When it comes to responsive web design in legacy browsers, there is no one-size-fits-all solution. It is important to analyze the audience of the resource in order to get an idea of ​​the actual number of browser users. Then you need to thoroughly test the site to identify potential cross-browser issues.