About debugging CSS cross-browser style bugs

The first thing to do is to pick a good browser. My choice is Chrome because of its powerful debugging tools. When I'm done debugging in Chrome, I'll move on to debugging in Safari or Firefox.

If you don't get the expected results on these "good" browsers, it's likely that the code itself violates CSS rules. Rather than trying to hack around problems that occur on these "good" browsers, you should try to identify the cause of the problem. I usually check the following possible BUG sources:

• HTML Code Explained – Did you forget to close a tag? Do you wrap a block element with an inline element? Code that violates standards may be interpreted and rendered differently by different browsers.
• Use the CSS lint tool to check your CSS code. Pay attention to the errors that are detected. In most cases, Errors are more likely to cause cross-browser differences than Warnings.
• Forget about resetting your stylesheets and rely instead on the (different) browser's default CSS styles.
• Differences in browser support. Are you using advanced CSS3 properties or HTML5 elements? Check the browser support documentation to make sure all your audience's browsers are covered. You need to design "feature fallbacks" to support older browsers. For example, downgrade a shadow border to a border, or downgrade rounded corners to a square.
• Adding spaces where there shouldn't be spaces can cause margins to appear strange.
• 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 position: static. However, if you try to change its top, right, bottom or left values, the element will immediately "jump" to the position relative to its nearest relatively positioned parent.
• Elements of different display modes are combined in an "unusual" way. For example, the W3C standard does not say how a table-cell should be laid out when it is next to a floating element. Therefore, the code written in this way is not wrong, but it may cause bugs that cause different rendering effects across browsers.
• Whether the space affects the layout. You don't want your typography to depend on whitespace.
• Fractional pixel values ​​can cause different effects across browsers.

Next comes the text

The most important thing to remember is that the W3C standard does not define error behavior. Therefore, if you don't follow the specification, it may cause different effects across browsers; if you combine "strange" properties (such as margin and inline element), it may also cause cross-browser bugs.

Display

I think of writing CSS as choosing a journey. You need to make some decisions. For example, you first need to choose the elements to use with different display modes: block, inline, inline-block and table. Once you have made your selection, you can use some specific methods to change its 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 spacing. However, margin, padding, height and width do not apply.

First, tables have vertical and horizontal alignments. Second, if you miss an element in the table, the entire table may appear strange. Finally, margin does not apply to table rows and columns, and padding does not apply to tables or table rows.

Positioning

If you choose to use block-level elements, next you need to choose a positioning method:

• Float – If you use float, the element becomes a block-level element, and the vertical-align and line-height properties previously applied to the element will become invalid.
• Absolute – Offsets are calculated relative to the nearest relatively positioned parent node. Absolutely positioned elements do not cause reflow when their parent and sibling nodes change. This feature is useful for creating animation effects. However, if absolute positioning is used and the content changes dynamically it may cause display problems. A typical example is an absolutely positioned rounded box.
• Static – The default positioning method.
• Fixed – The element’s position is relative to the browser window. Not often used.
• Relative – Usually has no effect on the style of this element. Only its subordinate absolutely positioned child nodes will be offset relative to this node.

I won't list all the display and position combinations here. In summary, there are two things to note:

1. Are other properties (such as margin and line-height) appropriate for the display and position methods I have chosen?
2. Are the positioning methods of sibling nodes consistent?

For example, is it appropriate to combine float, table-cell, and inline elements? How will the browser interpret the rendering? Is there any definition in the W3C standard? If not, then you run the risk of cross-browser bugs. Of course, such a combination is not impossible, but you need to think clearly about why you want to do so and do enough cross-browser testing.

Internet Explorer

Once you have resolved the issues with the "good" browsers, it's time to move on to the IE platform. My advice is to start with the oldest version of IE that you wish to support, as many issues with older versions of IE carry over to newer versions.

Even for IE, you should try to isolate the problem rather than relying on using hacks. Blindly using the * and _ hack is like adding a fixup (see below) to a function that returns an incorrect value, instead of identifying the algorithmic error.

Of course, sometimes it is necessary to use hacks in IE6 and IE7. For IE8, hacks are usually only used where CSS3 compatibility is required. Usually, the places where hacks are needed in IE6/7 are:

• hasLayout problem, use zoom:1
• Relative positioning causes elements to disappear
• 3px floating BUG
• Floating errors of stretched containers are often accidentally masked by overflow:hidden.

There are also some less common situations where hacks are needed, such as when there is a comment code between two floating elements, which will trigger the duplicate content bug. For CSS problems that only occur in IE, my advice is to carefully describe what you see and search Google for the corresponding solution. Don't blindly use hacks to cover up a bug before you find the cause of it. IE's built-in debugging tools are terrible, so you may need to add a background color to the element to make it easier for you to see the actual layout on the page.

Implementing the solution

Once you find the cause of the bug and know how to fix it, you should also know how to modify the code without destroying existing code that works properly. Here are my suggestions:

1. Dependent style cascading

2. Use browser-specific prefixes

3. Use * and _ for IE6/7

4. Don’t use \9 for IE8

5. Know when to abandon IE hacks

6. Do not use any hacks on the latest versions of Firefox, Chrome, Safari

1. Dependent style cascading

First, try to rely on the style cascade whenever possible. Browsers always take the last declared style that they can understand. Therefore, you should start by writing styles for older browsers, so that the browser can read and use the last styles it can understand. For example:

2. Use browser-specific prefixes

Use browser-specific prefixes, especially for properties that are not yet widely adopted. For example:

Note that there are two syntaxes in this code for different versions of WebKit. The order of prefix codes should also be written starting from the old versions of browsers (see the first one).
If there is a syntax defined by a W3C standard, you should put it last (such as the last line in the above code). This way, as browsers begin to support standard syntax for these new features, your code will be robust.

3. Use * and _ for IE6/7

For bugs specific to older versions of IE, use * and _ to fix them. for example:

All IE hacks are targeted at a certain version and all previous browsers, such as:

_ For IE6 and earlier

* For IE7 and earlier

\9 for IE8 and earlier (note that IE9 is also sensitive to this hack on some CSS properties)

Therefore, the order of hack code should also start from writing for old versions of browsers (refer to the first item).

4. Don’t use \9 for IE8

I would never use \9 to work around styling bugs in IE8. I would only use \9 as a "fallback" to compensate for browser support. For example, I used box-shadow (which works fine on more advanced browsers), but it looked ugly in IE8, so I used \9 to add a new border. This situation cannot be handled by the style cascade (see the first item) because this is adding a new style, not modifying an existing style.

5. Know when to abandon IE hacks

Don't try to get the exact same effect in IE. Are you willing to waste extra HTTP requests and complex HTML/JS/CSS code snippets just to achieve the same rounded corner box effect in IE6-8? For me personally, my answer is "no".

You should know when to abandon a hack for a feature. For example, don’t use filters to simulate gradient effects in CSS3, as that can cause performance issues and typographical bugs. The simplest approach is to not expect your pages to behave exactly the same in all browsers. For users of IE 6-8, the best approach is to give them a simplified user experience (note, simplified, not incomplete).

The following bad code uses filters to simulate CSS3 gradients:

6. Do not use any hacks on the latest versions of Firefox, Chrome, Safari

For style bugs on Firefox, Chrome, and Safari, the best thing to do is to check carefully. It is very likely that this is because your code violates the rules of CSS.