How to debug a CSS cross-browser style bug

Original http://www.stubbornella.org/content/2012/05/02/cross-browser-debugging-css/

The author is a Yahoo front-end engineer.

The first thing to do is to pick a good browser. My choice is chrome because it has powerful debugging tools. When I'm done debugging on Chrome, I'll go ahead and debug it on Safari or Firefox.

If the desired effect is not achieved on these "good" browsers, it is likely that the code itself violates the CSS rules. Instead of trying to use the hack method to solve the problems that occur on these "good" browsers, you should look for the cause of the problem. Usually I check the following possible sources of bugs:

• HTML code Explanation-Did you forget to close a tag? Do you wrap a block element with an inline element? Code that violates the standard may be interpreted differently on different browsers.
• Use the CSS Lint tool to check the CSS code. Pay attention to the errors that are checked out. In most cases, errors is more likely to cause cross-browser differences than warnings.
• Forget to use the reset style sheet, but instead rely on the (different) default CSS style of the browser.
• Differences in browser support. Do you use advanced CSS3 attributes or HTML5 elements? Check your browser's supporting documentation to make sure all your audiences ' browsers are covered. You need to design "feature downgrade" to support old-fashioned browsers. For example, demote a shaded border to a border, or downgrade a fillet to a block.
• In places where there should be no spaces, margin may appear bizarre.
• Absolute positioning is used, but no vertical and horizontal offsets are set. In this case, the absolutely positioned element will be rendered in the same position as the position:static. However, if you try to change its top,right,bottom or left value, the element will immediately "jump" to the position of the parent element referring to its nearest relative position.
• Elements of different display modes are combined in an "unusual" way. For example, the standard does not say what layout should be when a table-cell is adjacent to a floating element. Therefore, the code written in this way is not wrong, but it may cause a bug to render different effects across browsers.
• Whether the space affects layout. You should not want the layout style to depend on spaces.
• A decimal point pixel value can result in different effects across browsers.

And then the text comes.

The most important thing to remember is that the standard does not define the wrong behavior. Therefore, if you do not write according to the specification, it may result in different effects across browsers, and if you combine "strange" attributes (such as margin and inline element), it can also cause a cross-browser effect bug.

Display

I think writing CSS is like choosing a journey. You need to make some decisions. For example, you would first choose elements that use different display modes: Block,inline,inline-block and table. When you choose to do so, you can use some concrete methods to change the actual display.

Block elements should use margin,padding,height and width. However Line-height does not apply.

Inline elements should use line-height,vertical align and whitespace. However margin,padding,height and width do not apply.

First, the table has a vertical and horizontal arrangement. Second, if you omit an element from the table, the entire table may appear strangely. Finally, margin does not apply to rows and columns of the table, and padding does not apply to tables and tables.

Positioning

If you choose to use block-level elements, then you need to choose the position way:

• Float-If you use float, then this element becomes a block-level element, and the Vertical-align and Line-height properties that previously applied to the element will be invalidated.
• Absolute-Calculates the offset relative to the closest relative position of the parent node. When the parent and sibling nodes change, absolutely positioned elements do not cause reflow. This feature is useful for animating the effect. However, if you use absolute positioning and changing content dynamically will likely cause display problems, a typical example is an absolutely positioned rounded box.
• static– the default position mode.
• Fixed-element position relative to the browser window. Infrequently used in a way.
• Relative– usually does not affect the style of the element. Only the child nodes whose subordinates are absolutely positioned will calculate the offset relative to the node.

I'm not going to list all the display and position combinations here. In short, there are two things to note:

1. Are the other properties (such as margin,line-height) suitable for the display and position I choose?
2. is the position method of the sibling node fit?

For example, is it appropriate to combine float,table-cell and inline elements together? How will the browser interpret the rendering? Is there a definition in the standard? If not, there may be a risk of cross-browser bugs. Of course, such a combination is not not possible, but you need to figure out why to do so, and do enough cross-browser testing.

Internet Explorer

Once you have solved the problem on the "good" browser, you should now start the IE platform. My advice starts with the oldest version of IE that you want to support, because many older versions of IE have problems that continue to appear in the new version.

Even for IE, you should try to find the problem instead of relying on the hack method. The hack method of blindly using * and _ is like adding a modifier (as follows) to a function that returns an error value, rather than finding an algorithmic error in it.

return result + 4;

Of course, sometimes it is necessary to use hack in IE6 and IE7. For IE8, hack is usually used only where compatible CSS3 are required. In general, where the use of hack is required in IE6/7:

• Haslayout problem, use Zoom:1
• Relative positioning causes elements to disappear
• 3PX floating Bug
• The floating error of a large container is often disguised by Overflow:hidden.

There are also less common situations where you need to use hack, such as when there are comment codes in the middle of two floating elements that trigger duplicate content bugs. For CSS problems that only appear in IE, my advice is to carefully describe what you see and search for the appropriate solution in Google. Before you find the cause of the bug, don't blindly use hack to disguise it. IE comes with a bad debugging tool, so you might want to add a background color to the elements to make it easier for you to see the real typography on the page.

Implementing Solutions

When you find the cause of the bug and know the solution, you should also know how to modify the code without breaking the existing normal effect code. Here are my suggestions:

1. Dependency style Cascade
2. Use a prefix for a specific browser
3. Use the * and _ for IE6/7
4. Do not use \9 for IE8
5. Know when to abandon the hack for IE
6. Do not use any hack for the latest version of Firefox,chrome,safari

1. Dependency style Cascade

First, try to rely on style cascading whenever possible. Browsers always take the style of the last statement they can read. So, you should start writing for the old version of the browser, so that the browser can read and use the last style it can read. For example:

. Foo{background-color: #ccc;/* Older browsers would use this */background-color:rgba (0,0,0,0.2);/* browsers that Underst And RGBA would use this */}

2. Use a prefix for a specific browser

Use a prefix for a specific browser, especially for properties that are not yet widely used. For example:

. Foo{background: #1e5799;/* Old browsers */background:-moz-linear-gradient (Top, #1e5799 0, #2989d8 50%, #207cca 51%, #7 Db9e8 100%); /* ff3.6+ */background:-webkit-gradient (linear, left top, left bottom, Color-stop (0%, #1e5799), Color-stop (50%, #2989d8) , Color-stop (51%, #207cca), Color-stop (100%, #7db9e8)); /* chrome,safari4+ */background:-webkit-linear-gradient (Top, #1e5799 0, #2989d8 50%, #207cca 51%, #7db9e8 100%);/* chrome10+,safari5.1+ */background:-o-linear-gradient (Top, #1e5799 0, #2989d8 50%, #207cca 51%, #7db9e8 100%);/* Opera 11.10+ */background:-ms-linear-gradient (Top, #1e5799 0, #2989d8 50%, #207cca 51%, #7db9e8 100%);/* ie10+ */background:li Near-gradient (Top, #1e5799 0, #2989d8 50%, #207cca 51%, #7db9e8 100%); */* *

Note that there are two syntax for different versions of WebKit in this set of code. The order of the prefix codes should also be written from the old version of the browser (refer to the first article).
If you have a standard-definition syntax, you should put it at the end (for example, the last line of code above). This allows your code to behave robustly as browsers begin to support the standard syntax for these new features.

3. Use the * and _ for IE6/7

For older versions of IE specific bugs, use * and _ to compensate. Like what:

. clearfix {Overflow:hidden;/* New formatting context in better browsers */*overflow:visible;/* Protect IE7 and older F Rom the overflow property */*zoom:1; /* Give IE haslayout, a new formatting context equivalent */}

All IE hack are aimed at a version and all of its previous browsers, such as:

_ for IE6 and earlier versions
* For IE7 and earlier versions
\9 for IE8 and earlier (note that IE9 is also sensitive to this hack on some CSS properties)

Therefore, the order of the hack code should also be written from the old version of the browser (refer to the first article).

4. Do not use \9 for IE8

I never use \9 to solve the style bugs that appear in IE8. I will only use \9 to make up the browser support for "downgrade" processing. For example, I used Box-shadow (normal on a more advanced browser), but it was hard to see under IE8, so I used \9 to add a new border. This situation cannot be handled by the style cascade (refer to the first article) because it adds a new style instead of modifying an existing style.

5. Know when to abandon the hack for IE

Don't try to get the exact same effect in IE. Are you willing to waste additional HTTP requests, HTML/JS/CSS code snippets in order to see the same rounded box effect in ie6-8? For me personally, my answer is "no".

You should know when to give up the hack for a feature. For example, do not use filter to simulate a gradient in CSS3, which can lead to performance problems and typographical bugs. The simplest way to do this is not to hope that your Web page will behave exactly the same in all browsers. For IE 6-8 users, the best way is to give them a simplistic user experience (note that it is simplistic rather than incomplete).

The bad code below is to use filter to simulate the gradient in CSS3:

. foo {filter:progid:DXImageTransform.Microsoft.gradient (startcolorstr= ' #1e5799 ', endcolorstr= ' #7db9e8 ', gradienttype=0); /* ie6-9 */}

6. Do not use any hack for the latest version of Firefox,chrome,safari

For a style bug on Firefox,chrome,safari, the best way to do this is to check carefully, most likely because your code violates the rules of CSS.

How to debug a CSS cross-browser style bug