4 solutions to CSS browser compatibility issues

Front-end is a tough job, not only because technology updates quickly, but also because there are so many things you need to know. What’s even more troublesome is that you have to face various adaptation and compatibility issues.

Why are there browser compatibility issues?

Isn’t it because there are too many browser manufacturers!

Chrome, Frirefox, Safari, Edge, IE6, IE7, IE8, IE9... 360 Safe Browser, QQ Browser, The World, TT, Sogou, Opera, Maxthon...

The key is that different manufacturers, or even different versions of the same manufacturer, have inconsistent parsing effects on the same CSS section, which leads to inconsistent page display effects and also brings compatibility issues.

How I wish Chrome could dominate the world~~

Current market share of each browser

There are so many browsers, and we can't possibly be compatible with every one of them. For products with average user base, it's already very good if we can adapt to mainstream browsers.

According to the data provided by Baidu Traffic Research Institute from August 2018 to February 2019, Chrome accounts for 46.28%, and IE still accounts for a large proportion. There is still a long way to go.

Solutions and solutions to CSS browser compatibility issues

Today, I don’t want to focus on too many details, such as which CSS styles we need to be compatible with, but I want to discuss the big solution, which mainly includes four aspects: browser CSS style initialization, browser private properties, CSS hack syntax and automation plug-ins.

1. Browser CSS style initialization

Since the default CSS styles of each browser are different, the simplest and most effective way is to initialize them. I believe many friends have written such code. Before all CSS starts, set marin and padding to 0 to prevent different display effects in different browsers.

*{ 
 margin: 0; 
 padding: 0; 
}

Regarding browser CSS style initialization, if you are not experienced, you may not know what to initialize. Here I recommend a library, Normalize.css, which has nearly 34,000 stars on GitHub. I will show you a few style settings, as follows

html { 
 line-height: 1.15; /* Correct the line height in all browsers */ 
 -webkit-text-size-adjust: 100%; /* Prevent adjustments of font size after orientation changes in iOS. */ 
} 
 
body { 
 margin: 0; 
} 
 
a { 
 background-color: transparent; /* Remove the gray background on active links in IE 10. */ 
} 
 
img { 
 border-style: none; /* Remove the border on images inside links in IE 10. */ 
}

I believe that many common compatibility issues can be solved through CSS style initialization. Next, let’s take a look at the private properties of the browser.

2. Browser private properties

We often add some prefixes before a CSS property, such as -webkit-, -moz-, -ms-. These are private properties of the browser.

Why do private attributes appear? This is because the W3C, the organization that develops HTML and CSS standards, moves very slowly.

Usually, a member of the W3C organization proposes a new attribute, such as border-radius, and everyone thinks it is a good idea. However, W3C has to go through a very complicated process, including review, to formulate the standard. Browser vendors have a tight time frame for marketing, so if a feature is mature enough, they will add support for it in the browser.

However, to avoid changes when W3C publishes the standard in the future, a private prefix will be added, such as -webkit-border-radius, to support new properties in advance. After W3C publishes the standard and the standard writing of border-radius is established, the new version of the browser will support this writing method of border-radius. Common prefixes are:

• -moz represents the private properties of the Firefox browser
• -ms represents the private attributes of IE browser
• -webkit represents Chrome and Safari private attributes
• -o represents opera private attributes

Pay attention to the order of private attributes, put the standard method at the end and the compatible method at the beginning

-webkit-transform:rotate(-3deg); /*For Chrome/Safari*/ 
 -moz-transform:rotate(-3deg); /*For Firefox*/ 
 -ms-transform:rotate(-3deg); /*for IE*/ 
 -o-transform:rotate(-3deg); /*For Opera*/ 
 transform:rotate(-3deg);

Writing so many compatibility codes for each CSS property is undoubtedly the biggest waste of life. Later we will talk about how to handle this through automatic plug-ins.

3. CSS hack

Sometimes we need to write specific CSS styles for different browsers or different versions. This process of writing corresponding CSS code for different browsers/different versions is called CSS hack!

There are three ways to write CSS hacks: conditional hacks, attribute-level hacks, and selector-level hacks.

Conditional hack

Conditional hack mainly makes some special settings for IE browser

grammar:

<!--[if <keywords>? IE <version>?]> 
 Code block, can be html, css, js 
<![endif]-->

Value

keywords

The condition following if includes 6 selection methods: whether, greater than, greater than or equal to, less than, less than or equal to, non-specified version

Whether: Specifies whether it is IE or a certain version of IE. Keyword: empty

Greater than: Select IE versions greater than the specified version. Keyword: gt (greater than)

Greater than or equal to: Select IE versions that are greater than or equal to the specified version. Keyword: gte (greater than or equal)

Less than: Select IE versions that are less than the specified version. Keyword: lt (less than)

Less than or equal to: Select IE versions that are less than or equal to the specified version. Keyword: lte (less than or equal)

Non-specified versions: Select all IE versions except the specified version. Keywords: !

version

IE browser version, such as 6, 7, 8

The conditional comment feature has been removed in IE10 and above, so please be careful when using it.

Example

<!--[if IE]> 
 <p>You won't see me in non-IE</p> 
<![endif]--> 
 
<!--[if IE]> 
<style> 
 .test{color:red;} 
</style> 
<![endif]--> 
 
<!--[if lt IE 9]> 
 <script src="//cdn.bootcss.com/html5shiv/3.7.2/html5shiv.min.js"></script> 
 <script src="//cdn.bootcss.com/respond.js/1.4.2/respond.min.js"></script> 
<![endif]-->

Attribute level hack

Attribute hack is to add some hack prefixes that only specific browsers can recognize before the CSS style attribute name.

grammar:

selector{<hack>?property:value<hack>?;}

Value:

: Select IE6 and below. A hyphen (-) can also be used, but to avoid confusion with some properties that have a hyphen, it is more appropriate to use an underscore ().

: Select IE7 and below. Both (+) and (#) can be used, but () is more popular in the industry

9. Choose IE6+

：Select browsers below IE8+ and Opera15

Example

If you want to set different colors in different IE browsers, pay attention to the order: put the compatibility of the lower version at the end

.test {
 color: #0909; /* For IE8+ */
 *color: #f00; /* For IE7 and earlier */
 _color: #ff0; /* For IE6 and earlier */
}

Select the rune level hack

Selector-level hacks are used to hack CSS selectors by adding prefixes that only certain browsers can recognize, targeting browsers that have inconsistent page performance or require special treatment.

grammar:

<hack> selector{ sRules }

Value: Common selector-level hacks include

The *html* prefix is ​​only valid for IE6
*+html *+ prefix is ​​only effective for IE7
@media screen\9{...} is only effective for IE6/7
@media \0screen {body { background: red; }} is only valid for IE8
@media \0screen\,screen\9{body { background: blue; }} is only valid for IE6/7/8
@media screen\0 {body { background: green; }} is only valid for IE8/9/10
@media screen and (min-width:0\0) {body { background: gray; }} is only valid for IE9/10
@media screen and (-ms-high-contrast: active), (-ms-high-contrast: none) {body { background: orange; }} is only valid for IE10

Example:

* html .test { color: #090; } /* For IE6 and earlier */ 
* + html .test { color: #ff0; } /* For IE7 */

Seeing this, I have to be proud of the front-end staff. This is too difficult~~

However, spending a lot of effort to solve these compatibility issues will not bring us any major improvements in technology. It is nothing more than filling holes for various browser manufacturers. As time goes by, the value of these technologies will become smaller and smaller. The key is how to spend the least effort to solve CSS compatibility issues and leave more time for a better life. Fortunately, there are some automated plug-ins that can help us get rid of the heavy compatibility processing.

4. Automation plugin

Autoprefixer is a plug-in that automatically manages browser prefixes. It can parse CSS files and add browser prefixes to CSS content, using data from Can I Use (caniuse website) to determine which prefixes are needed.

After adding Autoprefixer to your asset building tool (such as Grunt), you can completely forget about CSS prefixes and just write CSS normally according to the latest W3C specifications. If the project needs to support older browsers, you can modify the browsers parameter settings.

//The code we wrote div { 
 transform: rotate(30deg); 
} 
 
// Code for auto-completion. The specific completion depends on the browser version to be compatible. You can set it yourself. div { 
 -ms-transform:rotate(30deg); 
 -webkit-transform: rotate(30deg); 
 -o-transform: rotate(30deg); 
 -moz-transform:rotate(30deg); 
 transform: rotate(30deg); 
}

Currently, webpack, gulp, and grunt all have corresponding plug-ins. If you haven’t used them yet, apply them to our project as soon as possible. Don’t let CSS compatibility waste your time!

This concludes this article on 4 solutions to CSS browser compatibility issues. For more relevant CSS browser compatibility content, please search 123WORDPRESS.COM’s previous articles or continue to browse the related articles below. I hope everyone will support 123WORDPRESS.COM in the future!