Friday, May 18, 2012

CSS Reference

http://reference.sitepoint.com/css

Saturday, May 5, 2012

Multiple Class / ID and Class Selectors

Can you spot the difference between these two selectors?

#header.callout {  }

#header .callout { }

They look nearly identical, but the top one has no space between "#header" and ".callout" while the bottom one does. This small difference makes a huge difference in what it does. To some of you, that top selector may seem like a mistake, but it's actually a quite useful selector. Let's see the difference, what that top selector means, and exploring more of that style selector.

Here is the "plain English" of "#header .callout":

Select all elements with the class name callout that are decendents of the element with an ID of header.

Here is the "plain English" of "#header.callout":

Select the element which has an ID of header and also a class name of callout.

Maybe this graphic will make that more clear:

Combinations of Classes and IDs

The big point here is that you can target elements that have combinations of classes and IDs by stringing those selectors together without spaces.

ID and Class Selector

As we covered above, you can target elements by a combination of ID and class.

<h1 id="one" class="two">This Should Be Red</h1>

#one.two { color: red; }

Double Class Selector

Target an element that has all of multiple classes. Shown below with two classes, but not limited to two.

<h1 class="three four">Double Class</h1>

.three.four { color: red; }

Multiples

We aren't limited to only two here, we can combine as many classes and IDs into a single selector as we want.

.snippet#header.code.red { color: red; }

Although bear in mind that's getting a little ridiculous =)

Example

So how useful is all this really? Especially with ID's, they are supposed to be unique anyway, so why would you need to combine it with a class? I admit the use cases for the ID versions are slimmer, but there are certainly uses. One of those is overriding styles easily.

#header { color: red; }
#header.override { color: black; }

The second targets the same element, but overrides the color, instead of having to use:

.override { color: black !important }

or perhaps prefacing the selector with something even more specific.
More useful is multiple classes and using them in the "object oriented" css style that is all the rage lately. Let's say you had a bunch of divs on a page, and you used multiple various descriptive class names on them:

<div class="red border box"></div>
<div class="blue border box"></div>
<div class="green border box"></div>
<div class="red box"></div>
<div class="blue box"></div>
<div class="green box"></div>
<div class="border box"></div>

They all share the class "box", which perhaps sets a width or a background texture, something that all of them have in common. Then some of them have color names as classes, this would be for controlling the colors used inside the box. Perhaps green means the box has a greenish background and light green text. A few of them have a class name of "border", presumably these would have a border on them while the rest would not.
So let's set something up:

.box { width: 100px; float: left; margin: 0 10px 10px 0; }
.red { color: red; background: pink; }
.blue { color: blue; background: light-blue; }
.green { color: green; background: light-green; }
.border { border: 5px solid black; }

Cool, we have a good toolbox going here, where we can create new boxes and we have a variety of options, we can pick a color and if it has a border or not just by applying some fairly semantic classes. Having this class name toolbox also allows us to target unique combinations of these classes. For example, maybe that black border isn't working on the red boxes, let's fix that:

.red.border { border-color: #900; }

Border color on red box changed because it had both the red class and border class

Based on this demo page.

Specificity

Also important to note here is that the specificity values of selectors like this will carry the same weight as if they were separate. This is what gives these the overriding power like the example above.

Browser Compatibility

All good current browsers support this as well as IE back to version 7. IE 6 is rather weird. It selects based on the first selector in the list. So ".red.border" will select based on just ".red", which kinda ruins things. But if you are supporting IE 6, you are used to this kind of tomfoolery anyway and can just fix it with conditional styles.

http://css-tricks.com/multiple-class-id-selectors/

Browser Specific CSS hacks LIST ALL

Browser CSS hacks

April 15th, 2009

I don't use CSS hacks anymore. Instead I use IE's conditional comments to apply classes to the body tag.
Nonetheless, I wanted to document every browser-specific css selector and style attribute hack I've seen. Plus there's no way to provide stylesheets to only Safari, I believe.
With these you'll be able to better target IE, Firefox, Chrome, Safari and Opera from within the css.
So here are go:

Comprehensive List of Browser-Specific CSS Hacks

 
/***** Selector Hacks ******/
 
/* IE6 and below */
* html #uno  { color: red }
 
/* IE7 */
*:first-child+html #dos { color: red } 
 
/* IE7, FF, Saf, Opera  */
html>body #tres { color: red }
 
/* IE8, FF, Saf, Opera (Everything but IE 6,7) */
html>/**/body #cuatro { color: red }
 
/* Opera 9.27 and below, safari 2 */
html:first-child #cinco { color: red }
 
/* Safari 2-3 */
html[xmlns*=""] body:last-child #seis { color: red }
 
/* safari 3+, chrome 1+, opera9+, ff 3.5+ */
body:nth-of-type(1) #siete { color: red }
 
/* safari 3+, chrome 1+, opera9+, ff 3.5+ */
body:first-of-type #ocho {  color: red }
 
/* saf3+, chrome1+ */
@media screen and (-webkit-min-device-pixel-ratio:0) {
 #diez  { color: red  }
}
 
/* iPhone / mobile webkit */
@media screen and (max-device-width: 480px) {
 #veintiseis { color: red  }
}
 
 
/* Safari 2 - 3.1 */
html[xmlns*=""]:root #trece  { color: red  }
 
/* Safari 2 - 3.1, Opera 9.25 */
*|html[xmlns*=""] #catorce { color: red  }
 
/* Everything but IE6-8 */
:root *> #quince { color: red  }
 
/* IE7 */
*+html #dieciocho {  color: red }
 
/* Firefox only. 1+ */
#veinticuatro,  x:-moz-any-link  { color: red }
 
/* Firefox 3.0+ */
#veinticinco,  x:-moz-any-link, x:default  { color: red  }
 
/* FF 3.5+ */
body:not(:-moz-handler-blocked) #cuarenta { color: red; }
 
 
/***** Attribute Hacks ******/
 
/* IE6 */
#once { _color: blue }
 
/* IE6, IE7 */
#doce { *color: blue; /* or #color: blue */ }
 
/* Everything but IE6 */
#diecisiete { color/**/: blue }
 
/* IE6, IE7, IE8, but also IE9 in some cases :( */
#diecinueve { color: blue\9; }
 
/* IE7, IE8 */
#veinte { color/*\**/: blue\9; }
 
/* IE6, IE7 -- acts as an !important */
#veintesiete { color: blue !ie; } /* string after ! can be anything */
 
/* IE8, IE9 */
#anotherone  {color: blue\0/;} /* must go at the END of all rules */

If you'd like to take a gander by yourself:

Test page with all these hacks present.
View the test page at browsershots.org
(Thx to Webdevout, Evo tech, and Jeffrey, porneL, and commenters.)
I should point out I'm not including weird hacks like the voice-family ones or anything particularly ugly.

Somewhat related…

Here are the most concise browser sniffs I've seen. (Not that browser sniffing is good or anything…)

Update 2009.06.03 – I added the suggestions left on Ajaxian and in the comments and updated the browser versions to consider Safari 4, IE 8, and Chrome 2. Update 2009.08.03 – I added some new Firefox hacks from @pornelski, which are very unique in that the target selector is not a child like the rest of them. More explanation on his site.
Update 2009.11.10 – Added #prop: value IE<=7 hack. I prefer it much less to *prop.
Update 2010.01.24 - Added prop: value!ie hack. Thx @miketaylr for the tip.
Update 2010.04.07 – Clarification on :nth-of-type(n) from Estelle Weyl
Update 2011.04.11 – the new \0/ hack from here and here. It's invalid and must go at the end of all other rules.. so it's a pretty dangerous hack, but at the same time.. its a happy arms-raised guy, so I guess it balances out. :)
Update 2011.05.18 – updated the \0/ and \9 one to note that it works in IE9 as well. thx Mathias Bynens.
Update 2011.05.19 – added :not(:-moz-handler-blocked) one from lea verou.

Freeform addendum

2011.05.23: Okay some freeform notes from recent research. hopefully i'll clean these up later….

Mathias wrote about safe CSS hacks Read that. Also I should clarify which of the hacks on this page are recommended and which are …. tricky and nasty.. (which is many of them)…
Mathias is also on the hunt for an IE8-only CSS hack. Hope we unearth one!
Siggi, in the comments wrote about the // comment hack to match IE6, 7:

    min-height:300px;
    //height:300px; /* matches only IE6, IE7 */

Then the CSS magician Thierry Koblentz offered up these selector hacks…

selector, x:-IE7 { } /* IE7 only */
selector,{ … } /* lte ie7 */
.suckyie6.someClass { … } /* lte ie6  */

The last one is done via the ie6 .double.class bug — the .suckyie6 class could be anything you're not using.
And the skillful necolas posted more details on IE css hacks:

/* Property prefix hacks */
 
/* IE6 only - any combination of these characters */
_ - £ ¬ ¦
 
/* IE6/7 only - any combination of these characters */
! $ & * ( ) = % + @ , . / ` [ ] # ~ ? : < > |
 
 
/* @media hacks */
 
/* IE6/7 only (via Keith Clarke) */
@media screen\9 { }
 
/* IE6/7/8 (via Keith Clarke) */
@media \0screen\,screen\9 {} 
 
/* IE8 (via Keith Clarke) */
@media \0screen { }
 
/* IE8/9 */
@media screen\0 { }

http://paulirish.com/2009/browser-specific-css-hacks/

Conditional stylesheets vs CSS hacks

From what I've seen a good number of developers these days are split between conditional stylesheets and css hacks.
You're used to seeing this:

  <link rel="stylesheet" type="text/css" media="screen" href="css/style.css" />
  <!--[if IE 7]><link rel="stylesheet" type="text/css" media="screen" href="css/ie7.css"  />< ![endif]-->
  <!--[if IE 6]><link rel="stylesheet" type="text/css" media="screen" href="css/ie6.css"  />< ![endif]-->

But probably also plenty of this:

div.infoBox { float: left; margin-left: 10px; _margin-left: 5px; }

CSS hacks to target specific browsers stay where the rest of your styles are, but they certainly don't validate. For sometime now, the standards community has rallied around conditional stylesheets as a solution to the validation problem.
There are a few problems with it though:

Conditional stylesheets mean 1 or 2 additional HTTP requests to download
As they are in the the <head>, the rendering of the page waits until they're totally loaded.
Also – Yahoo's internal coding best practices do not recommend conditional stylesheets
It can separate a single CSS rule into multiple files. I've spent a lot of time wondering "Where the eff is that rule coming from!?" when it turned out to be tucked away in a conditional stylesheet.

Here's my proposed solution:

<!--[if lt IE 7]>      <html class="ie6"> <![endif]-->
<!--[if IE 7]>         <html class="ie7"> <![endif]-->
<!--[if IE 8]>         <html class="ie8"> <![endif]-->
<!--[if gt IE 8]><!--> <html>         <!--<![endif]-->

Using the same conditional comments, we're just conditionally adding an extra class onto the html tag. This allows us to keep our browser-specific css in the same file:

 div.foo { color: inherit;}
.ie6 div.foo { color: #ff8000; }

Plus it totally validates and works in all browsers.
(Hat tip to Paul Hammond and Adam McIntyre for being s-m-r-t.)

2010.05.07: Patrick O'Neill put this technique on some steroids. I rather like it. See below:

<!--[if lt IE 7]>  <html class="ie ie6 lte9 lte8 lte7"> <![endif]-->
<!--[if IE 7]>     <html class="ie ie7 lte9 lte8 lte7"> <![endif]-->
<!--[if IE 8]>     <html class="ie ie8 lte9 lte8"> <![endif]-->
<!--[if IE 9]>     <html class="ie ie9 lte9"> <![endif]-->
<!--[if gt IE 9]>  <html> <![endif]-->
<!--[if !IE]><!--> <html>             <!--<![endif]-->

Doug Avery of Viget points out he prefers to use this technique on the HTML tag, freeing the body tag for dynamic classes. That works just fine. I later changed all my sites to use it on HTML instead of body, actually… Also it combo's really well with the Avoiding the FOUC v3.0 technique as well as Modernizr.
You fancy something different?

2010.05.07: Oh sheesh ya'll. Mat Marquis pointed out the code would leave a page <body>-less in IE10, etc. (Well not really because IE would auto-construct a body tag, but anyway…) Some gt later and we're good. 2010.05.20: Turns out IE conditionals around css files for IE6 can slow down your page load time in IE8! Crazy, right? The solution here avoids that, as does forcing IE to edge rendering.
2010.06.08: And then… Rob Larsen points out that when these conditional classes are applied to the HTML element, it doesn't block. No empty comment necessary. I think that's a new winner.
2010.09.07: Update follows!

Throw it on the html tag

Here is the new recommendation, and the one that's in use in the HTML5 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]-->

Why?

This fixes a file blocking issue discovered by Stoyan Stefanov and Markus Leptien.
It avoids an empty comment that also fixes the above issue.
CMSes like WordPress and Drupal use the body class more heavily. This makes integrating there a touch simpler
It doesn't validate in html4 but is fine in html5. Deal with it.
It plays nicely with a technique to kick off your page-specific javascript based on your markup.
It uses the same element as Modernizr (and Dojo). That feels nice.

I left an empty class in there because you'll probably be putting a no-js in there or something else. If not, delete.
Also if the extra comments around that last tag look weird to you, blame Dreamweaver, which chokes on normal !IE conditional comments.

2010.10.24: A sharp reminder and critique from Louis Lazaris follows. I asked him to summarize his viewpoint that he shared in his post Don’t Use Conditional Comments to Create Classes for IE7+, because I think it's a very wise point…

This solution tends to encourage developers to largely ignore IE during development, and just hack it into submission at the end. That’s actually the worst thing you can do when writing your CSS, because it will force you to use hacks or workarounds that aren’t necessary. Many hacks and workarounds can be avoided by just coding things to work in IE from the start.
If you test IE early in development, you should do your best to use good, standards-compliant code that is optimized for performance and future maintenance. Style forking creates code that's less optimized in both those areas. Although IE can often be difficult to work with, it is possible to get it to work in most circumstances using good code — it just takes some forethought.

It's very smart.
In reply to his post I said..

When you are addressing IE’s inconsistencies, attempt to first fix them without singling out IE in particular. In many cases, this is a matter of adding a width or height.. or some overflow:hidden. In general, being more explicit about how the element should appear helps IE6 and IE7 greatly.

Something to keep in mind. :)

2011.03.18: Rachel Moore left a really nice comment exploring the pros and cons of this technique 2011.04.11: The HTML5 Boilerplate community dug into this and figured out a lot more details around the syntax. Hopefully I'll get a chance to update this post with those learning, but until then.. click through!
2011.05.18: Updated the main snippet to match the syntax tricks we used in h5bp. See above link for more crazy details.

2011.09.02: Starting a list of languages this technique has been ported to

Conditional classes, ported

In Thesis (php) sorta, uses UA sniffing. :/
in Slim (rails) by helloluis
in Jade (node) by kmiyashiro & monokrome
in HAML (rails) by gf3
thematic by scott nix

2011.11: Leif Halvard Silli, an awesome web standards hacker from Norway wrote in to say…

An earlier presentation of the idea that this page builds on, can be found at Big John’s classic IE hacking web site positioniseverything.net, in a guest article from February 2007 by Hiroki Chalfant entitled “#IEroot — Targeting IE Using Conditional Comments and Just One Stylesheet”.

2012.01.17: Here is the current iteration that we have in the HTML5 Boilerplate. We actually tried to reduce it down to just a single .oldIE class for IE ≤8 (to use with safe css hacks), but that didn't fly. Anyway, our current version..

<!--[if lt IE 7]> <html class="lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]>    <html class="lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]>    <html class="lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <html class=""> <!--<![endif]-->

http://paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/

CSS Font-Size: em vs. px vs. pt vs. percent

One of the most confusing aspects of CSS styling is the application of the font-size attribute for text scaling. In CSS, you’re given four different units by which you can measure the size of text as it’s displayed in the web browser. Which of these four units is best suited for the web? It’s a question that’s spawned a diverse variety of debate and criticism. Finding a definitive answer can be difficult, most likely because the question, itself, is so difficult to answer.

Meet the Units

“Ems” (em): The “em” is a scalable unit that is used in web document media. An em is equal to the current font-size, for instance, if the font-size of the document is 12pt, 1em is equal to 12pt. Ems are scalable in nature, so 2em would equal 24pt, .5em would equal 6pt, etc. Ems are becoming increasingly popular in web documents due to scalability and their mobile-device-friendly nature.
Pixels (px): Pixels are fixed-size units that are used in screen media (i.e. to be read on the computer screen). One pixel is equal to one dot on the computer screen (the smallest division of your screen’s resolution). Many web designers use pixel units in web documents in order to produce a pixel-perfect representation of their site as it is rendered in the browser. One problem with the pixel unit is that it does not scale upward for visually-impaired readers or downward to fit mobile devices.
Points (pt): Points are traditionally used in print media (anything that is to be printed on paper, etc.). One point is equal to 1/72 of an inch. Points are much like pixels, in that they are fixed-size units and cannot scale in size.
Percent (%): The percent unit is much like the “em” unit, save for a few fundamental differences. First and foremost, the current font-size is equal to 100% (i.e. 12pt = 100%). While using the percent unit, your text remains fully scalable for mobile devices and for accessibility.

So, What’s the Difference?

It’s easy to understand the difference between font-size units when you see them in action. Generally, 1em = 12pt = 16px = 100%. When using these font-sizes, let’s see what happens when you increase the base font size (using the body CSS selector) from 100% to 120%.
Font-sizes as they increase from 100% to 120%.

Font-sizes as they increase from 100% to 120%.

As you can see, both the em and percent units get larger as the base font-size increases, but pixels and points do not. It can be easy to set an absolute size for your text, but it’s much easier on your visitors to use scalable text that can display on any device or any machine. For this reason, the em and percent units are preferred for web document text.

Em vs. Percent

We’ve decided that point and pixel units are not necessarily best suited for web documents, which leaves us with the em and percent units. In theory, both the em and the percent units are identical, but in application, they actually have a few minor differences that are important to consider.
In the example above, we used the percent unit as our base font-size (on the body tag). If you change your base font-size from percent to ems (i.e. body { font-size: 1em; }), you probably won’t notice a difference. Let’s see what happens when “1em” is our body font-size, and when the client alters the “Text Size” setting of their browser (this is available in some browsers, such as Internet Explorer).
Font-size as the client changes the text size in their browser.

Font-size as the client changes the text size in their browser.

When the client’s browser text size is set to “medium,” there is no difference between ems and percent. When the setting is altered, however, the difference is quite large. On the “Smallest” setting, ems are much smaller than percent, and when on the “Largest” setting, it’s quite the opposite, with ems displaying much larger than percent. While some could argue that the em units are scaling as they are truly intended, in practical application, the em text scales too abruptly, with the smallest text becoming hardly legible on some client machines.

The Verdict

In theory, the em unit is the new and upcoming standard for font sizes on the web, but in practice, the percent unit seems to provide a more consistent and accessible display for users. When client settings have changed, percent text scales at a reasonable rate, allowing designers to preserve readability, accessibility, and visual design.
The winner: percent (%).

Addendum (January 2011)

It’s been a couple years since I wrote this post, and I’d like to sum up the discussion and debate that has happened in that time. Generally, when I create a new design, I will use percent on the body element (body { font-size: 62.5%; }), and then use the em unit to size it from there. As long as the body is set using the percent unit, you may choose to use either percent or ems on any other CSS rules and selectors and still retain the benefits of using percent as your base font size. Over the past couple of years, this has really become the standard in design.
Pixels are now considered acceptable font size units (users can use the browser’s “zoom” feature to read smaller text), although they are starting to cause some issues as a result of mobile devices with very high density screens (some Android and iPhone devices have upwards of 200 to 300 pixels per inch, making your 11- and 12-pixel fonts very difficult to see!). As a result, I will continue to use percent as my base font size in web documents. As always, discussion and debate is encouraged and welcome; thanks for all the great comments over the course of the past two years!

http://kyleschaeffer.com/best-practices/css-font-size-em-vs-px-vs-pt-vs/

IE CSS Hacks

If you are trying to do pixel-perfect cross-browser CSS layout, then you have probably ran into problems with IE . I am going to highlight the top 7 CSS hacks that we often use to have pixel perfect design.

1)Box Model Hack

The box model hack is used to fix a rendering problem in pre-IE 6 browsers, where the border and padding are included in the width of an element, as opposed to added on

 padding: 4em; border: 1em solid red; width: 30em; width/**/:/**/ 25em;

2) Conditional Comments

These conditional comments are for IE-only and they’re not supported by any other browser. For other browsers they are just an ordinary comments and therefor, they are safe to use.
The typical usage is as follows:

<!--[if IE]>    Some CssCode<![endif]-->

The above code applies to all versions of Internet Explorer, i.e. 5.01, 5.5 and 6.0, but now we want to apply it to versions of Internet Explorer, i.e. 5.01, 5.5 and 6.0, so we will apply the following condition:

<!--[if lte IE 6]>    Some Css Code<![endif]-->

After we finish testing, we remove all hacks to separate file(s), so the main CSS is clean and tidy. This separate file is then called in the header section of a file within conditional comments.

<!--[if lte IE 6]>    <link rel="stylesheet" type="text/css" href="ie_hacks.css" /><![endif]-->

Condition is one of the following:

IE (Any version of IE)
lt IE version (Versions less than version)
lte IE version(Versions less than or equal to version)
IE version (Only version)
gte IE version (Versions greater than or equal to version)
gt IE version (Versions greater than version)

Version is the version of Internet Explorer, typically 5, 5.5, 6, or 7, you can read more info about this at Quirksmode.

3) Min-width and Max-width of an element

IE doesn’t understand this command, so we’ll need a new way of making this work in this browser. Let’s take a quick example, we need to apply this to a div with id="wrapper":

<wrapper><div id="nav">

Next we create our CSS commands, so as to create a minimum width of 750px:

 #wrapper{min-width: 750px;width:expression(document.body.clientWidth < 750? "750px": "auto" );}

You might also want to combine this minimum width of 750px with a maximum width 1220px:

#wrapper{min-width: 750px;max-width: 1220px;width:expression(document.body.clientWidth < 750? "750px" : document.body.clientWidth > 1220? "1220px" : "auto");}

Another Alternative for for min-height without javascript is to use Dustin Diaz’ nice hack: :

#id{ min-height: 100px; height:auto !important; height:100px; }

4) Easy Selectors

Most in-CSS hacks deal with selector bugs. Below is a list of different IE versions and the beginnings of selectors that are known to select elements in them. All of these selectors use valid CSS.

IE 6 and below
```
* html {}
```
IE 7 and below
```
*:first-child+html {} * html {}
```
IE 7 only
```
*:first-child+html {}
```
IE 7 and modern browsers only
```
 html>body {}
```
Modern browsers only (not IE 7)
```
 html>/**/body {}
```
Recent Opera versions 9 and below
```
html:first-child {} 
```

5)Whatever: hover

The :hover selector enables you to have cool effect for html elements like and in tables.Most browsers have no problem with this, except IE which look at the stylesheets and each individual rule with javascript.
If :hover rules can be tracked, and .htc can be used to change an elements behavior, then it should be possible to create a behavior that enables :hover for any element.
You can read more about this here

6)Transparent PNGs

IE dosn’t handle transparent PNG too well. You’ll get an ugly grayish type background wherever it’s supposed to be transparent. And we cann’t just use GIFs because aren’t good for higher resolution images. So we need a CSS hack to fix this. Follow the following steps and you will be set:

A HTC script and a transparent GIF will be used to solve this issue. You can download both files here
Now just upload these 2 files to wherever you store your IE.css file.
Add one simple line of CSS code to your ie.css file:
```
 img.pngfix {  behavior: url(pngHack.htc); }
```

Another solution can be found at Komodomedia

7) Stylegala- No More CSS Hacks

Stylegala’s method is to detect browser version and serve different CSS rules to different user agents, without using hacks or conditional comments. At the same time the end user or validator will never see the CSS rules specified for other browsers than the one they are using. He used some simple PHP code to detect browser type exactly as any CSS hack.

Firefox CSS Hacks

http://perishablepress.com/css-hacks-for-different-versions-of-firefox/

CSS Hacks for Different Versions of Firefox

In a perfect world, I don’t use CSS hacks, and certainly don’t recommend them. In the unpredictable, chaos of the real world, however, there are many situations where applying styles to particular browsers is indeed the optimal solution. Most of the time, I am targeting or filtering Internet Explorer (because it is so incredibly awesome), but occasionally I need to tweak something in a modern browser like Firefox, Safari, or Opera. In this article, we’ll look at CSS hacks targeting different versions of Firefox.
Some of these CSS hacks don’t validate, others are proprietary, and some are completely valid (depending on CSS specification). I have tested these hacks to the best of my ability, but don’t let that stop you from checking things out on your own (in fact, I absolutely recommend doing so). These Firefox hacks are organized according to version number and presented with ease of copying and pasting in mind. That said, here are some notes that apply to all of the hacks in this article:

For each hack, change only #selector, .selector, and of course the declaration blocks.
Hacks that do not validate as CSS are designated with [!] in the associated comment.
If you discover any inconsistencies, incompatibilities, or inoperabilities, please leave a comment.
This post is a work in progress. Please share any Firefox hacks that are not on the list.

Also keep in mind that, in general, there are two types of CSS hacks: those that target and those that filter. By targeting, we are referring to the application of CSS styles to a particular, targeted browser (or set of browsers) at the exclusion of all others. Conversely, by filtering, we are referring to the application of CSS styles to every browser except a particular browser (or set of browsers). In essence, this hack dichotomy represents two sides of the same coin. How you classify these various hacks all depends on perspective.

CSS Hacks targeting all Firefox

These hacks target all versions of Firefox:

/* Target all Firefox */
#selector[id=selector] { color: red; }

/* Target all Firefox */ 
@-moz-document url-prefix() { .selector { color: red; } } 

/* Target all Gecko (includes Firefox) */
*>.selector { color: red; }

CSS Hacks targeting Firefox 1.5 and newer

This hack targets Firefox versions 1.5 and newer:

/* Target Firefox 1.5 and newer [!] */
.selector, x:-moz-any-link, x:only-child { color: red; }

CSS Hacks targeting Firefox 2 and older

These hacks target Firefox 2 and older:

/* Target Firefox 2 and older [!] */
body:empty .selector { color: red; }

/* Target Firefox 2 and older */
#selector[id=SELECTOR] { color: red; }

/* Target FireFox 2 and older [!] */
html>/**/body .selector, x:-moz-any-link { color: red; }

CSS Hacks targeting Firefox 3

This hack targets Firefox 3 (and possibly newer):

/* Target FireFox 3 [!] */
html>/**/body .selector, x:-moz-any-link, x:default { color: red; }