When we need to apply CSS for other browsers, we either create new CSS files and enclose it with conditional comments. This actually causes blocking issue, which slow downs the site’s loading speed for a few seconds. We might also use browser specific hacks which will create issues while getting W3C validation.
What happens with Conditional Stylesheets?
Below I am using a typical example of using conditional stylesheets to work with various versions of Internet Explorer.
<link rel=”stylesheet” type=”text/css” media=”screen” href=”css/style.css”/>
<!–[if IE 7]><link rel=”stylesheet” media=”screen” href=”css/ie7.css”/>
< ![endif]–>
<!–[if IE 6]><link rel=”stylesheet” media=”screen” href=”css/ie6.css”/>
< ![endif]–>
- Conditional style-sheets will mean additional HTTP requests to download.
- As the statement is included in the tag, rendering of the page is affected. This happens because the page has to wait until the style-sheets are loaded.
- This can separate a single CSS rule into multiple files which should be avoided.
What happens when we use CSS Hacks?
Example:
.ClassName{ margin-right: 15px; _margin-right: 5px; float:right;}
- CSS hacks are targeted at specific browsers but it certainly does not validate the code.
- Use of hacks are not necessary as many time hacks and workarounds can be avoided by just coding things to work in IE from the beginning.
Solution
We can make use of “Rob Larsen’s” technique which is used in Paul Irish’s boilerplate.
<!–[if lt IE 7 ]> <html class=”ie6″> <![endif]–>
<!–[if IE 7 ]> <html class=”ie7″> <![endif]–>
<!–[if IE 8 ]> <html class=”ie8″> <![endif]–>
<!–[if IE 9 ]> <html class=”ie9″> <![endif]–>
<!–[if (gt IE 9)|!(IE)]><!–><html class=””><!–<![endif]–>
- This will fix the file blocking issue and we do not need to write any empty comment which also fixes the issue.
- CMS platforms like WordPress and Drupal use the body class more heavily. This makes integrating there a touch simpler.
- This technique when used will not be validated in HTML 4 but it works fine with HTML 5.
So CSS experts out there, do you find this article useful? Do drop in your views and any other alternate solutions through your comments.
5 Comments
Hacks are nothing but the fixes which browser should have supported in its default behavior. So when we say ‘I fixed it using so and so hack’ we are modifying that particular browsers default behavior.
We should use less hacks and the reason why we should avoid using hacks is, what if the browser fixes the so called bug which it was not used to support earlier…..our hack in turn may produce another serious bug….!! So we have to be careful, what say…?
Absolutely correct,and one more reason is that, you have to remember something extra i.e. hack, which is unnecessary or unwanted also affects validation.
Pros : We save a single HTTP request.
Cons : By doing this your CSS file size increase since you write all fix in a single file.
If it increases by 10 to 15 lines not a big deal.
We include separate stylesheet for IE6, IE7 and sometimes IE8 so 3 additional HTTP request, but we hardly write 10 to 15 lines for IE6, few lines for IE7 and nothing for IE8.