One of the greatest problems with CSS, or Cascading Style Sheets, is the issue of cross browser compatibility. What may look great in Mozilla browsers looks terrible in Internet Explorer, and may totally break in Netscape. The biggest mistake a web designer or developer using CSS can make is to design for only one browser, or to assume that since the largest group of viewers use IE, to disregard its flaws that are apparent in other browsers.
This article and the next in this series will cover a few of the cross browser issues in CSS, why the code acts the way it does, and how you can either fix it, or avoid it altogether. But before we jump right into the CSS hacks and fixes, I want to explore a cornerstone in the foundation of good CSS programming: understanding browser compatibility.
The World Wide Web Consortium, or the W3C, has published two main CSS recommendations of style sheets – CSS 1.0 and CSS 2.1. CSS 1.0 became a recommendation in 1996, and CSS 2.1 became a recommendation in 1998. In this article, I am only going to refer to issues created by CSS 2.1, and the browsers that support it. CSS 3.0 is currently under development.
Knowing your Arena
A good CSS developer tries to keep all browser formats in mind when trying out new ideas in CSS. The first step to be able to do this is to become familiar with the individual browsers, and know why they do what they do, and what CSS versions and levels of compliancy they support. It’s not critical to you that you know all the ins and outs of every browser or the bugs of each one, but it is important to understand the vast majority of differences among them.
There are certain principles surrounding each browser that are important to understand before tackling a cross-browser issue in CSS. The browsers I will be covering are Mozilla and Firefox, Netscape 6+, Safari, Opera, and Internet Explorer 5+ for Windows and Mac. The reason I am not going to talk about older browsers is the sheer fact that they’ve been covered so thoroughly all over the Internet, and I really didn’t want to beat a dead horse, so to speak.
Note:
there are so many other browsers, such as Mozilla’s browser project Camino for Mac, Maxthon, Konqueror, and many more that do support CSS 2.1. Honestly, there are simply just too many to list and analyze, when in actuality most of them are based on the technologies of the major players I mentioned; for example, Maxthon is based on IE; and if it works on Firefox, it’s very likely going to work on Mozilla and Camino. Browsers that generally do not support CSS 2.1 will not be covered here, like text-based Lynx and older browsers.
Mozilla and Firefox
The Mozilla Group makes the open-source Gecko browser engine, used by the Mozilla browser suite and by a diverse range of products. Gecko is highly standards-compliant and is available on many platforms. Firefox is a Mozilla browser. Mozilla based browsers like Firefox were the earliest browsers to support CSS fairly well.
Safari for Mac
Safari is an OS X browser using a variant of Konqueror’s KHTML browser engine. Apple reportedly chose to base Safari on KHTML instead of Gecko for three reasons:
KHTML was faster, KHTML’s source code is smaller and cleaner, and Apple doesn’t need Gecko’s multi-platform support. Overall this browser behaves the same as Mozilla. Some minor tweaks might be needed to be made to a style sheet to accommodate proper rendering, but overall this browser will handle content like Mozilla with regard to your style sheet.
Opera
Opera Software makes the Opera browser for many operating systems, including embedded systems. Opera is renowned as a browser that is small, fast, standards-compliant, and available on many platforms. Opera fully supports CSS 2.1. So when validating your CSS code, you can be sure that your validated CSS will render properly in Opera, either with the strict doctype or in quirks mode.
Netscape 6 and up
It has been said that Netscape 6 has the best CSS support on the web, and only Mozilla browsers (initially derived from Netscape Navigator 4) have fewer CSS bugs. While I’m not sure I’m qualified to agree or disagree with this statement, what I do know is there is a big difference in the ways that Netscape renders CSS than it did when CSS first became standardized. Now Netscape is essentially synonymous with Mozilla browsers. The ironic part is that Netscape initially tried to introduce a different type of style sheet in JavaScript in order to avoid CSS compliancy altogether.
Internet Explorer 5 and up
There was such a huge improvement in CSS support for Internet Explorer when Microsoft updated IE3 to IE4 that to date, it is still the largest browser upgrade for IE. Still, newer versions of IE have several issues, many of which were solved in version 6 for Windows and 5.5 for Mac. But because IE 5 is still one of the most popular versions of a web browser available, much consideration must be made for it with regards to CSS 2.1, even if it can behave oddly regarding your CSS.
However, even IE6 for Windows is buggy when it comes to margins of floated elements: it doubles them. There are other bugs like duplicate text in multiple floats, oversized content boxes, and several others. While there is no way we could cover every possible bug or fix in these two articles, we’ll look a an explanation as to what makes browsers different with regards to CSS compatibility, and a few fixes out there.
Why are they so different?
The answer to this question goes back to CSS not having standards adopted by all the browser vendors. If you know anything about CSS, you probably know a little of the history concerning it. What’s important to understand that Internet Explorer is used by almost 70% of people, the number of people using non-Microsoft browsers is only about 30%, even though that number is rising. It seems that Internet Explorer is the one with the most problems in the newer of the browsers with regards to compatibility. Being able to have your site look the same across all the browsers takes a bit of practice and skill.
The biggest problem with IE is that it tries to assume what to do, instead of following your CSS instructions step by step, as well as not supporting many of the CSS 2.1 standards that Netscape and Mozilla browsers do. W3Schools.com has a pretty good chart that shows which browsers support certain CSS commands, and which browsers do not. It will also list which version of CSS that browser supports. However, the chart only lists a few browsers, like IE, Firefox, and Netscape, but this is based upon the assumption that all other browsers are derived in some form or another from these browsers.
How to Handle the Differences
One thing you can do to help Internet Explorer truly do what you want it to do instead of “figuring it out for you” is to put your web page for IE into quirks mode. Quirks mode is a rendering mode where a browser tries to handle sloppy code in the way that they did in the mid- to late 90’s. In essence, in quirks mode the browser “purposefully imitates the lax parsing, rendering, and bugs in earlier browser versions so that they render the old, quirkily coded pages exactly the same as they used to.” On the site, css-discuss.incutio.com, you can find a good list of the quirks that are reproduced in which browsers when using quirks rendering mode.
The problem with this is that if you put your page into quirks mode for IE or older browsers, then you’re putting the page into quirks mode for other browsers as well. Therefore, you have to use a trigger that will switch between strict mode and quirks mode depending upon the type of browser that is detected. This is referred to as “doctype switching” which is supported by all modern browsers. According to the standards, any (X)HTML document should have a doctype which informs the browser of the version of (X)HTML the document is using. A doctype looks like this:
The other mode that modern browsers recognize is strict mode. Your page does not have to validate according to the chosen doctype; the mere presence of the doctype is enough to trigger strict mode. There is one exception to this rule: in IE 6, if a doctype that triggers strict mode is preceded by an xml prologue, the page displays in quirks mode. It looks like this:
Another solution to issues of cross-browser compatibility would be to create multiple style sheets for multiple browsers, then using a JavaScript code to return the version and type of browser the web visitor is using. I’ll talk more about this in the next article. Still, even with the support of both strict mode and quirks mode in these browsers, there are going to be design issues. Let’s look at a few workarounds and why they work the way they do, but we’ll really delve more into the hacks in the next article.
The first one I want to look at is the “html>body” selector. This selects any body element that is a child of an HTML element. The problem though is the child selector will be interpreted correctly in compliant browsers only if there is white space on either side of it (html > body or html> body or html >body), except in IE.
This is a manifestation of the underscore hack, which allows you to show CSS only to IE and exclude all other browsers. This comes in very handy when you are needing to give IE a set of separate instructions because something won’t appear correctly if you don’t.
The underscore hack looks like this:
Two things I will point out about this workaround: one, your CSS won’t validate; and two, it doesn’t work in IE 5 for Mac. For this case, we have to add another hack, called the Mac Backslash Hack (try saying it three times really fast). The normal function of this hack is to get IE5/Mac to ignore any CSS rules contained within the hack’s boundaries. This hack works by escaping an end-comment marker using a backslash before the asterisk: \*/. This hides the end-comment marker for IE5/Mac, and tricks IE5/Mac into thinking anything which follows is still part of the comment. Once another unescaped end-comment marker appears, IE5/Mac resumes application of the remaining CSS rules. All other browsers understand the escaped end-comment as the actual end of the comment, and apply the following rules as if nothing ever stopped them from doing so.
Hacks, as you can see from the example above, can get pretty complicated if you don’t understand the bugs that the browsers have to begin with. You can find pretty good list of reported CSS bugs for particular browsers either on the browser’s own site or elsewhere on the Internet. The next article will have many more hacks and workarounds, and hopefully this overview of why CSS sometimes really does behave oddly in certain browsers was helpful to you.
