Style sheets from three different origins can affect a Web page:

User agent style sheets (see Figure 3-1) are those present by default in the user agent (the device the user is using to access our code, typically the web browser). Even though when we open an HTML file with no CSS files linked to it, it appears to be unstyled; in fact, it is styled by the user agent style sheet. This is the style sheet that adds the typical blue to unvisited links, purple to visited links, different font sizes for different types of headings, and so on.

Figure 3-1. The homepage of bbc.co.uk with only the user agent style sheet applied (that of Firefox, in this instance).

User style sheets (see Figure 3-2) can be, for example, style sheets applied to a page based on the user's browser preferences, such as a larger font or a specific font family, for easier reading.

Figure 3-2. The front page of Wikipedia with a user style sheet applied: in this case, the user style sheet ensures that the text on any website is never smaller than 18px.

User style sheets can also be CSS files created by the user that the browser will read in order to change the design or details of a specific site. In this case, the external files are usually stored on the user's machine and referenced by the browser.

By default, author style sheets override user style sheets, which in turn override user agent style sheets. There is a way, however, to make user style sheets have more weight and override author declarations. This can be achieved using the !important declaration, which ensures that, no matter what, the user will always have the final say on how the pages will be displayed.

The !important declaration is used on a property-by-property basis, and it can be applied to inline, embedded, or external style sheets:

p {
   color: black !important;
}
p {
   color: red;
}

In the preceding example, because we are using the !important declaration, the first rule will be the one applied to the p element, even though the second rule comes later and has the same specificity (see the next section for more details on how to calculate a selector's specificity).^[14]

!important should be used with care in author style sheets and avoided if possible since it will interfere with the specificity of the rules and make way for overly specific and complicated CSS.

Let's look at the following example, where the user hides an advertisement bar on a website:

#myfavoritesite .advertbanner {
   display: none !important;
}

User style sheets with the !important declaration will always override style sheets from any other origin, so in this case the user can be sure that the advertisement bar won't be displayed.

In order to make it easier for users to inject their own CSS rules into specific websites, some developers add an ID to the body element of their pages, or even go further than that by adding both site-wide IDs and page-by-page classes, so that users can easily point to specific pages if needed.

Author style sheets are those created by CSS authors, provided in the actual page returned by the server. They can be inline within the markup (using the HTML style attribute), embedded on the page (using the HTML style tag), or linked externally (using the HTML link tag or @import rules).

After adding !important to the mix, we are left with the following different types of declarations, from most to least important:

The W3C definition of inheritance states that "Inheritance is a way of propagating property values from parent elements to their children" (www.w3.org/TR/css3-cascade/).

This means that some CSS properties are by default (or can be forced to be) inheritable by child elements.

Let's take a look at a typical scenario:

body {
   color: #111111;
   padding: 20px;
}

In the preceding example, the color property will be inherited by the elements that are children of the body element, so headings, paragraphs, lists, and other pieces of text will be dark grey ("#111111"). The padding property, however, will not be inherited; if we place a div or a paragraph inside the body element, they will not inherit a padding of 20 pixels.

These are examples of how inheritance works. In the first case, color, it makes sense that it affects the parent element's children; besides producing much larger files, it would be tiresome and inefficient to have to declare the color of every single element inside the parent. On the other hand, it would also be tiresome to override the 20 pixels of padding were they inherited by its children.

The W3C has a list of all CSS2.1 properties on its website, www.w3.org/TR/CSS21/propidx.html, which states whether they are inherited by default or not, initial (default) and possible values, and other characteristics.

Inheritance makes sense for the elements that do inherit by default, but it can also be forced for elements that don't by using the "inherit" value.

Let's say you wanted the section elements inside the aside parent to inherit its margin value:

aside {
   margin: 10px;
}
aside section {
   margin: inherit;
}

Using this CSS, every section element inside the aside element will now have 10 pixels of margin.

The way the user agent processes inheritance is explained in the W3C specification:

"The final value of a property is the result of a four-step calculation: the value is determined through specification (the 'specified value'), then resolved into a value that is used for inheritance (the 'computed value'), then converted into an absolute value if necessary (the 'used value'), and finally transformed according to the limitations of the local environment (the 'actual value')" (www.w3.org/TR/CSS2/cascade.html#value-stages).

According to the specification, these are the four values that the cascade looks for, in this order, to determine the final value of a property:

The value used when calculating inheritance is the computed value. This value exists even if the property hasn't been declared in the CSS, making it possible to force inheritance even if the parent element doesn't specify the property.

Let's take a look at the following example:

HTML:

<body>
   <p>To find what you are looking for visit <a href="http://google.com">Google</a>.</p>
</body>

CSS:

body {
   font-family: Arial, sans-serif;
   font-size: 12px;
}
a:link {
   color: inherit;
}

If we hadn't specified a color for our link element ("a"), we would have been presented with the default blue from the browser (user agent) style sheet. Although we haven't specified a text color for the body element, when using the "inherit" value for the color property of the unvisited link selector ("a:link"), it will use the parent's computed value. In this case that is the initial value, which for the color property depends on the user agent (as stated in the W3C's property specification), but tends to be #000000 (black).

The "inherit" value is not commonly used, but it can be helpful in situations like the example above, when the child's properties are dependent on the parent's in such a way that it is easier to create a dependency than explicitly stating a value.

One of the reasons that the "inherit" value is so rarely used in practice is that it is not supported by versions of IE prior to version 8, except for the "direction" and "visibility" properties. It should be employed when the advantages of using it (for example, when it adds greater flexibility, making updates to the CSS quicker to do and less prone to mistakes) supersede any rendering differences that may occur in using it.

The opposite of the "inherit" keyword is the "initial" keyword, introduced in CSS3. This value allows you to cancel inheritance by specifying the initial value of that property (as stated in the property's specification) instead of the inherited one. This property is only supported, however, by Firefox (using the -moz-initial keyword) and WebKit.

The universal selector ("*") matches any single element in the document tree (notice the use of the word single here, as it will not match a combination of two or more elements, or zero elements). When used imprudently, it can break inheritance and easily transform a style sheet into an inheritance and specificity nightmare.

Take the following example:

HTML:

<section>
   <header>
      <hgroup>
         <h1>Main title</h1>
         <h2>Secondary <i>title</i></h2>
      </hgroup>
   </header>
        ...
</section>

CSS:

section header * {
   color: red;
}
section header h2 {
   color: black;
}

The first CSS rule, which includes the universal selector, targets any and every element inside the header element, be it a direct child, grandchild, or deeper. With the second CSS rule, the expected behavior would be that any element inside the h2 should be black. But what happens if we have another element within h2 is that, because the initial rule is targeting any element within header, it will be the same as stating the following:

section header h2 i {
   color: red;
}

Because this selector is more specific than "section header h2", the final result will render the word "Secondary" in black, but "title" in red (see Figure 3-3).

Figure 3-3. Inheritance is broken when using the universal selector

Although, at first, using the CSS universal selector in this scenario might have seemed like the safest option to make sure every element had the desired color, saving precious lines of code, this is not an example of robust CSS. It is instead an example of how breaking inheritance can lead to unnecessarily complicated, unpredictable, and verbose style sheets—exactly what we want to avoid in a high-traffic website where many individuals may be working on many files.

When assigning a weight to a CSS rule, the cascade will first sort them according to their importance and origin (as seen in the previous section). If rules have the same importance and origin, they will then be prioritized by their specificity: a more specific selector will override a less specific selector. Finally, if two selectors have the same origin, importance, and specificity, the one that comes later in the style sheet will take priority over the preceding one. This also applies to single properties, so if in the same rule the same property is declared more than once, the last declaration will override those previous to it.

Because imported style sheets (using the @import declaration) have to be specified before the other rules, when there are other nonimported rules with the same weight in the rest of the CSS file, the imported ones will be overridden (their precedence is lesser because of the order of the selectors).

To calculate specificity, according to the W3C specification (www.w3.org/TR/css3-selectors/#specificity), we use four representations of numbers (a, b, c, and d) of descending importance, where

Non-CSS presentational markup, such as the font attribute, will be attributed a specificity of 0.

Based on this list, the following selector has a specificity of 1,0,0,0 (a=1, b=0, c=0, d=0):

<section style="padding-bottom: 10px;">

Because it is inline CSS, "a" equals 1, and the rest of the numbers equal 0. Bear in mind that even if a rule that was linked to rather than inline had 10 ID selectors within it (thus having a specificity of 0,10,0,0), it would still have less precedence than the selector above—specificity doesn't use a base ten (or decimal) system in its calculations, but rather base infinite: if "a" equals 1, the rule will always take precedence over those where it equals 0.

This more complicated selector will have a specificity of 0,0,1,3 (a=0, b=0, c=1, d=3):

article section h1.title {
   ...
}

Since it's not inline, "a" equals 0, "b" equals 0 because there are no IDs, "c" equals 1 because it has one class selector, and "d" equals 3 because it has three element selectors.

Calculating specificity based on the list provided may seem daunting, but the truth is that, with some experience, it is fairly easy to look at a selector and tell whether it is more or less specific than another one (perhaps it has one or two ID selectors or another obvious hint like that). While writing CSS, you should be careful not to create highly specific selectors where they aren't necessary and whenever a trickier situation arises, tools like Firebug or Safari Web Inspector will be there to help you understand how specificity is being applied by showing you the rules in order of specificity (with the more specific rules at the top) and striking through the properties that have been overridden by more specific rules. You can read more about these in Chapter 10. There are two important things to remember, though: inline CSS has higher priority than embedded or linked CSS, and one ID selector will win out over any number of class, attribute, or element selectors.

Using the !important declaration on shorthand properties is the same as redeclaring each subproperty as important (even if that means they are reverted to their initial (default) value).

For example, suppose that we have the following selector:

h1 {
   font-family: Georgia, serif;
   font-size: 18px;
   font-style: italic;
}

And later in the style sheet we declare the following:

h1 {
   font: 18px Arial, sans-serif !important;
}

The result will be the same as having the following:

h1 {
   font-style: normal !important;
   font-variant: normal !important;
   font-weight: normal !important;
   font-size: 18px !important;

line-height: normal !important;
   font-family: Arial, sans-serif !important;
}

This happens because the properties that are not specifically defined within the !important declaration (in this case, font-style, font-variant, font-weight, and line-height) are reverted to their initial values (indicated in the property's specification), even if they had been declared in a less specific rule (like font-style: italic in this instance).

There are situations where highly specific selectors are necessary. For example, when creating widgets or code snippets that are to be used across a wide range of pages, subsites, minisites, or even third-party sites, it is common practice to namespace that part of the code, which in CSS means basically to isolate it using a specific class, ID, or prefix to class or ID (we covered namespacing in more detail in Chapter 2). It is also common to namespace an entire page in order to style it differently; in this case, we would add an ID or a class to the body element, such as:

<body class="home">

It is important to acknowledge, though, that while this is a common and easy way of creating different styles for different pages or sections on a page, it will influence specificity. When targeting these pages or code snippets within our CSS, we will have to introduce a class or an ID to the rule, increasing its specificity and thus making it harder to be overridden. For example, to make the h2 headings in the page that we had attributed the class "home" bigger than in the rest of the site, we could have the following set of rules:

h2 {
   font-size: 24px;
}
.home h2 {
   font-size: 36px;
}

In the previous example, the rule would be applied even without the class since the rule would have the same specificity but would be declared later. This, however, would be relying on order, which is counterproductive since it will fail if the order of the rules is changed (you can read more about this in Chapter 4).

If for some reason we need to override this setting again, within the homepage, we will need to, for example, add a class to a specific heading and create a more specific rule:

.home h2.highlight {
   font-size: 30px;
}

This can create a snowball of overly specific rules that will invariably lead to unnecessarily complicated CSS. The trick here is to plan carefully for these situations, which happen more frequently as more variations of certain elements and designs are needed throughout the website(s) and can be aggravated when there isn't a design library in place, or there is one but it is not frequently updated (you can read more about design libraries and maintaining design consistency in Chapter 5). You should have an adaptable style sheet in place and a set of guidelines on how specific developers should be for particular cases—constant overriding of highly specific selectors is not conducive to creating flexible CSS, but avoiding classes and IDs when they are the more efficient and robust solution is also not an option for high-traffic websites.

Using tools such as Firebug (see Figure 3-4) or Safari's Web Inspector (see Figure 3-5) makes it easier to understand which properties are taking precedence and overriding others. These tools can also show user agent style sheets and computed values, even if they haven't been declared on the CSS.

Figure 3-4. Using Firefox's Firebug plugin to look deep into a website's markup and CSS

Figure 3-5. Safari's Web Inspector. These tools are helpful to see how the cascade works.

This doesn't mean it is not important to understand how the cascade works, but it makes the process of debugging less painful. You can read more about this in Chapter 10.

There are several ways to make CSS properties and selectors only visible to one (or more) browser(s) and also to hide them from certain browsers.

We will not list these techniques extensively, but we will mention some of the most commonly used ones so you can have an idea of what they look like and what they achieve. There are several resources online, starting with Wikipedia (http://en.wikipedia.org/wiki/CSS_filter), that feature complete catalogs of these hacks since they are now well known and thoroughly documented.

.box {
   width: 600px;
   voice-family: ""}"";
   voice-family: inherit;
   width: 560px;
}

html>body .box {
   width: 560px;
}

#logo {
   background-image: url(logo.png);
   _background-image: url(logo.gif);
}

section {
   width: 860px;
   *width: 960px;
}

section {
   width: 860px; /* all browsers */
   *width: 960px; / IE7 and below */
   _width: 1060px; / IE6 and below */
}

* html h1 { background-image: url(logo.gif); }

div {
 background-color: #dd4814;
}
body> div {
 background-image: url(orange.png) no-repeat;
}

/* IE for Mac doesn't understand this comment is closed */
(anything between the comments won't be read by IE for Mac)
/* IE for Mac will continue reading the CSS file after this comment */

CSS expressions (or dynamic properties) were introduced in IE 5 and are supported up until version 7 (or 8 and 9, when rendering in compatibility mode). By placing JavaScript within an expression, we can return different results depending on environment or other factors.

A simple CSS expression (bear in mind that this is JavaScript, and as such the syntax is not in scope for this book) to concatenate two strings is as follows:

aside {
   width: expression("320"+ "px");
}

This is the same as having the following:

aside {
   width: 320px;
}

In the following example, the expression checks whether the body width is narrower than 1200 pixels; if that's true, the width is set to "1200px", if not, it is set to "auto":

#container{
   width: expression((document.body.clientWidth > 1200) ? "1200px" : "auto");
}

CSS expressions are resource-intensive and can seriously hamper the performance of a website. Yahoo!, on its High Performance Web Sites Rules series, lists rule 7 as "Avoid CSS Expressions," arguing that "Not only are they evaluated when the page is rendered and resized, but also when the page is scrolled and even when the user moves the mouse over the page." (http://developer.yahoo.net/blog/archives/2007/07/high_performanc_6.html).

Some expressions can have a stronger performance hit than others, so performance testing is always recommended (as with all JavaScript), as there may be a case where using one CSS expression is the fastest and most efficient solution for dealing with browser inconsistencies.

Another downside of CSS expressions is the fact that they are reliant on JavaScript to work, which is far from ideal since we are actually dealing with CSS, and the user may have JavaScript disabled. Seeing that we are creating a JavaScript dependency, our advice is to move these to JavaScript, keeping the CSS free from CSS expressions and avoiding the toll on performance that comes with them.

There are few cross-browser cases that actually require JavaScript to resolve, and an event-driven solution like CSS expressions is as subtle a solution as a brick wall on a motorway. Unless you have a really strong case for using them and it is a final resort, we would recommend against it.

Browser-specific CSS doesn't just mean handling deficient IE renderings and working around its quirks. It may also include having vendor-specific properties to create more advanced effects that are in line with the latest CSS developments or not yet part of any specification.

For example, the syntax to create CSS border-radius needs to be written for browsers that have implemented the property in an experimental (and often incomplete) fashion, using its vendor-specific versions along with the official specification:

.box {
   -moz-border-radius:  4px
   -webkit-border-radius: 4px;
   border-radius: 4px;
}

In this example, we are basically stating the same thing three times in order to cater for the widest range of browsers possible. We have included the property as it is mentioned in the specification last, so when all browsers eventually implement it, it will still work, and the correct standards-compliant implementation will override the vendor-specific version.^[16]

This results in a non-valid CSS file, since vendor-specific extensions are still parsed as errors by CSS validators (although some voices have risen to have this behavior changed). Bear in mind, though, that the use of these vendor-specific extensions by browser manufacturers is standard practice, anticipated in the W3C specification, where it is stated that "property names beginning with '-' or '_' are reserved for vendor-specific extensions" and that they are "guaranteed never to be used in a property or keyword by any current or future level of CSS" (www.w3.org/TR/CSS21/syndata.html#vendor-keywords). There should be no conflicts between vendors since it is very unlikely that two of them will choose the same prefix. It is possible (and not unlikely), however, that the implementation of these experimental properties may change while they're still in this "testing" phase—keeping up to date with the latest news from the W3C CSS Working Group is a good idea if you don't want to be caught by surprise.

Here is a list of the most commonly used vendor-specific prefixes:

Notwithstanding that these properties are non-valid, vendor-specific CSS, they can't be qualified as hacks or workarounds, and they work as support for properties that are likely to be part of final specifications. Confining them to their own separate style sheet could prove a misstep in the search for efficiency: when one of the properties needs to be changed, all the others also need updating—the back and forth can be daunting. Also, again, the more individual CSS files there are (and therefore HTTP requests), the greater the performance hit.

Other solutions, such as relegating these vendor-specific properties to a separate section within the main CSS file, making them easier to find (and therefore, easier to delete if the need arises) might be a better labor-saving solution, although it results in duplicated selectors that are less efficient and can be more difficult to manage.

Rather than using hacks or other methods to only serve particular CSS to certain browsers, we are encouraged to use capability detection since this is a future-proof and sane method of targeting that is not dependent on bugs or easily overridden and spoofed properties. Media queries allow the creation of CSS that is dependent on the capabilities or features of the device that is being used to view the website. For example, you can write CSS that is only to be displayed on devices with monochrome screens, or a small viewport, printers, or even a combination of two or more features. Media queries don't target specific browsers, but rather the capabilities of the device that the website is being displayed on.

Media queries can be applied in three different ways:

Here is an example of a media query embedded directly in the style sheet, alongside the rest of the CSS:

@media screen and (max-width: 320px) {
   aside {
      float: none;
   }
}

You can import a different file from the style sheet using the @import rule:

@import url(320.css) screen and (max-width: 320px);

And finally, a media query inserted in the link tag within the head of an HTML document:

<link rel="stylesheet" media="screen and (max-width: 320px)" href="320.css" />

Media queries are often cited when creating mobile versions of websites, but there are other factors apart from pure design that you should consider. Using media queries doesn't necessarily prevent images from being downloaded.^[18] In fact, when using the link tag style sheets will be downloaded regardless of the media attribute, although they may not be applied. While media queries can be applied to create quick mobile versions of a website, when dealing with high-traffic websites, performance and accessibility considerations (a great deal of mobile devices still don't support media queries) will probably (and should) be at the top of the list and may invalidate the use of them for the most part. We talk about media queries in great detail in Chapter 7.

Conditional comments were introduced in IE 5 and are specially formatted HTML comments that allow targeting of specific versions of the Microsoft browser. They can be wrapped around another block of HTML and will effectively hide it from the browsers that are not being targeted.

A conditional comment can be used to target one specific version of IE:

<!--[if IE 8]>
        <link rel="stylesheet" href="ie8.css" />
<![endif]-->

In this case, the ie8.css file will only be requested by IE 8.

It can be used to target versions lower or greater than a particular version number:

<!--[if lt IE 7]>
        <link rel="stylesheet" href="ie6.css" />
<![endif]-->

<!--[if gt IE 7]>
        <link rel="stylesheet" href="ie8.css" />
<![endif]-->

In the first example, we are targeting IE versions from 5 to 6 (lt stands for "less than"). In the second example, we are targeting versions above but not including 7 (at the time of writing, that would include IE 8 and 9), using the gt operator ("greater than").

It can also be used to target versions lower or greater than a particular version, but including the one specified, like so:

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

<!--[if gte IE 7]>
        <link rel="stylesheet" href="ie7.css" />
<![endif]-->

The first example targets IE versions from 5 to 6, using the lte operator ("less than or equal to"). The second targets all versions above and including IE 7 (gte stands for "greater than or equal to").

It is also possible to use the NOT operator ("!", as used in many programming languages) in order to hide the comment from one or more browser versions. The following conditional comment will be ignored by IE 5, but not by other versions of IE:

<!--[if !(IE 5)]>
        <link rel="stylesheet" href="advanced.css" />
<![endif]-->

Although it is not common practice, conditional comments can become somewhat more complicated with the use of expressions, like the AND operator ("&"). Here is an example:

<!--[if (gte IE 5)&(lt IE 8)]>
        <link rel="stylesheet" href="hacks.css" />
<![endif]-->

Here we are targeting IE versions greater than and including IE 5 and lower than IE 8, so versions 5 through 7 inclusive. We can also use the OR operator ("|") in these expressions.

Conditional comments are sometimes listed among other hacks, but, unlike them, they do not rely on a browser bug to work, which makes them safer to use and more future-proof. They provide a cleaner way of separating browser-specific CSS from the base or more advanced style sheets, making it easier to remove these style sheets if and when support for older browsers is dropped.

In order to reduce HTTP requests, the CSS included in files that would be linked within conditional comments can be embedded directly on the head of the HTML document, as such:

<!--[if lte IE 6]>
        <style>
           li {
              display: inline;
                }
        </style>
<![endif]-->

This can be more advantageous than linking to external files for each browser that requires a separate style sheet, especially in situations when only a couple of rules are needed. This practice may hamper the maintainability of this snippet of code, but if the advantages in page performance are greater, it is a solution to consider and one that some high-traffic websites are employing already. Each request has a very real performance implication.

Conditional comments cannot be used within text nodes or attributes. For example, this won't work:

<style>
   li {
      display: block;
   }
        <!--[if IE 6]>
           li {
              display: inline;
                }
        <![endif]-->
</style>

And neither will this:

<div class="<!--[if IE 6]>ie6<![endif]-->">
   ...
</div>

To target browsers other than IE, i.e. hide contents from all IE browsers, it is necessary to use a "downlevel-revealed comment" so that the conditional comment is still read by IE, but does not comment content out in other browsers. This looks like this:

<!--[if !(IE)]><!-->
        <style>
                ...
        </style>
<!--<![endif]-->

This includes complete comments around the entire of the two parts of the conditional comment. Using this methodology allows us to create markup that will still validate.

<!--[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><!--<![endif]-->

#logo {
   background-image: url(logo.png);
}
.ie6 #logo {
   background-image: url(logo.gif);
}

The problem that may come with bugs being fixed in new browser releases doesn't relate to older browsers that are unlikely to see any kind of updates in the future. Browsers such as IE 5.5 or 6 have long lists of documented and well-known bugs. Some of these bugs can be avoided with careful CSS; other bugs will always be there, and yet other bugs are more temperamental and show up in an unpredictable and inconsistent fashion.

Because these older browsers aren't being actively developed any more (you should only expect any updates in the case of a very serious security issue needing to be fixed, and even then, CSS rendering probably will not be affected), using CSS hacks on them tends to be considered safe practice. Our opinion is that even in these cases, hacks have to be used in moderation. It is important to understand the risks involved in using them. Since they work due to inconsistencies or badly implemented CSS parsing and edge cases, it is possible that future browser versions may also be affected by them, although it is unlikely.

As an example of a safe hack to employ, let's take a look at the @import hack, commonly used to hide CSS files from versions 4 of browsers like IE or Netscape. Since these versions don't understand the @import directive, any style sheets referenced therein will not be requested. This hack (or filter) was publicized by Tantek Çelik. It can be used in the head of an HTML file, in conjunction with the style tag:

<style>
        @import "advanced.css";
</style>

It can also be located at the top of the actual CSS document:

@import "advanced.css";

In this particular case, though, be aware that using the @import declaration will result in extra HTTP requests and will affect the performance of the website. It is common practice to use no more than two @import declarations in a CSS file in order to avoid these issues. (We further discuss how the @import declaration can affect downloading speeds in Chapter 8.)

Modern browsers that conform to the latest web standards shouldn't have the need for any type of hack in order to render a CSS layout correctly. This, of course, will not produce a pixel-perfect copy of the original design across every available browser in the market, but that is something that is implied in the medium we are working with. If your company demands exactly identical rendering between every browser, it is worth demonstrating the costs in time versus lost features and even user testing to prove that users just don't notice that level of detail. If this is still unacceptable, you will just have to do the best you can with what you have. Choose your battles wisely.^[19]

When faced with a situation where a hack is needed, the ideal scenario would be to revisit the markup and the CSS and see if there is a clean solution that is valid and not browser-specific, so that we can avoid the problem in the first place.

Another good option is to consider whether the bug is relevant enough to be fixed. For example, if the layout isn't broken, and we are dealing with almost unnoticeable pixel differences between browsers, is there really a need to waste time and man-hours fixing it? Weighing up the cost in time, and the lost potential features and development that could have occurred in that time, the answer is almost always no.

Although the best solution is always to write markup and CSS that avoid the need for hacks, issues are inevitable and employing hacks is necessary. Sometimes it is impossible to have access to the HTML, the existing CSS cannot be edited, or maybe the cost in time that it would take to deal with the problem in this manner is not acceptable.

In these situations, whenever possible, browser-specific hacks should be either relegated to a browser-specific style sheet or to a section in the CSS file where all the hacks are stored, making it easier to remove them when they are no longer necessary. As an alternative, specific comments could be used on the lines of the hacks, making them easy to locate later. The most common example is TODO, which is understood and implemented by many integrated development environments (IDEs) and could be employed like so:

/*
   TODO : Remove this when we drop support for IE6
*/ _float:left;

Labeling comments in this way makes it easy to search for and locate them later in the development process.^[20] You could even use custom comments, with delimiters that are easy to locate and parse, such as the following:

/* HACK_IE7 */ *float:right;
/* HACK_IE6 */ _float:left;

If you are using CSSDOC-type comments, the @todo tag can be used within file and section comments. (CSSDOC is explained in more detail in Chapter 2.)

As with every aspect of CSS authoring within a team or organization, it is important that there is a set of guidelines in place as to which hacks are acceptable and which aren't. A safe approach to this matter is to allow CSS authors to freely apply only hacks from a predefined list of those that are well-known and documented and only for browsers that aren't being actively developed any more. Ideally, the developers would also know in which situations it is necessary that rendering is perfect or almost perfect and which situations browser inconsistencies can be overlooked. For example, the guidelines can mention that for measurements that break the layout of the page, hacks need to be employed for nonconforming browsers; for more decorative measurements, there is no need for hacks.

Older websites were developed relying on the deficient rendering of CSS by older browsers that were either following an unfinished or incomplete specification or simply chose not to implement some aspects of the documentation as stated by the W3C. With new browser releases that were more conformant with the standards, there was the problem of these older websites, developed around bugs and inconsistencies, being broken. In order to keep websites backward compatible (and not "break the Web"), modern browsers can often display pages in quirks mode, which mimics the behavior of older browsers.

A browser will decide which rendering mode to trigger usually based on the document type declaration of the page (this is called doctype switching). A complete doctype will trigger standards mode (without the need for the page to be actually valid), while an incomplete, invalid, or absent doctype will trigger quirks mode. IE 6 will also trigger quirks mode if the doctype is preceded by an XML prolog^[23] while any IE version will trigger quirks mode when the doctype is preceded by a comment.^[24]

Sooner or later, you will be faced with a browser rending difference that you can blame on the page being rendered in quirks mode. If editing the markup so that the correct doctype is applied or to remove any other portion of code that might be triggering quirks mode is not an option, the solution will have to rely on the CSS part of the equation.

When a document is laid out on visual media, CSS will represent each element as a rectangular box. These boxes can be placed after one another or nested. CSS3 defines three types of boxes:

Each box is composed of the actual content area and can optionally have a border, padding, and margins. The W3C defines that the border, padding, and margins should be added to the initial width and height of the element box, so if a div has the following CSS applied to it, according to the W3C specification, the div should have 124 pixels width and height (100px + 2*10px + 2*2px) with a 20-pixel margin on all sides:

div {
   width: 100px;
   height: 100px;
   padding: 10px;
   border: 2px solid #333333;
   margin: 20px;
}

However, IE 5 interprets things in a different way: For this browser, the padding and border of a box are to be subtracted from the specified width and height (in this case, 124px), as you can see in the bottom image in Figure 3-6.

Figure 3-6. The difference between the W3C box model (above) and IE's box model (below)

Despite this interpretation being more logical, it is incorrect, and that is why this behavior was corrected with the release of IE 6. IE 6 and above will, however, render using its incorrect box model if quirks mode (explained previously) is triggered.

This bug can have disastrous implications if you don't plan for it and do the necessary testing since it will influence the dimensions of the boxes in your layouts and will render them with completely different sizes.

Imagine a simple scenario: an outer container that has 940px width and 10px padding with two inner boxes of 470px width, floated side by side. If IE renders in quirks mode, the actual available space inside the outer container will not be 940px but rather 920px (since the padding is subtracted from 940px, and not added, as it should be). This means that the boxes will not be placed side by side, but one above the other, since they don't fit on the same line. This is just a very simple example of how a layout can be broken by the wrong interpretation of the box model, which will lead to unnecessary time and resources spent debugging that could have been avoided.

There are three ways of dealing with this bug:

By specifying only the dimensions on the parent element and then, separately, padding and borders on its child elements, you will be circumventing the problem without having to rely on whether or not the correct document type is being applied. This is one of the oldest tricks that CSS authors use to avoid broken layouts in IE 6. In the case that there is a child element to achieve this, this is a convenient and simple solution. However, if no child element exists, we recommend you use an alternative method to target IE6 specifically, rather than add unnecessary markup solely for one outdated browser.

Another option is to use the CSS3 property box-sizing, which is supported by all the modern browsers, including IE 8 (Firefox requires the -moz-box-sizing vendor-specific property, while Webkit-based browsers require the -webkit- prefix). The box-sizing property accepts one of two values: content-box or border-box. The content-box value will apply to that element the box model as specified by CSS2.1, where the padding and border are added to the given dimensions of the element. The border-box value will make the padding and border be subtracted from the specified width and height of the element, mimicking the IE box model.

One of the downsides of using this property is that it has to be added on an element-by-element basis. It can also be added to every element by using the universal selector (*) or by adding it to the elements that will most likely need it, like sectioning elements.

All in all, the box model issue is one that—although it may produce tragic outcomes when not catered for—can be easily avoided. The ideal solution would be to ensure that IE renders in standards-compliant mode; this solves many of the issues, and is really what we should be working toward as browsers modernize and move forward. We recommend that as part of your defensive CSS strategy (you can read more about this in Chapter 4) you avoid the problem altogether by not specifying dimensions and padding/border on the same element.

No matter which solution your team decides is best, it should be included in the internal CSS style guide.

The hasLayout concept is a Microsoft creation and applies only to IE; it "determines how elements draw and bound their content, interact with and relate to other elements, and react on and transmit application/user events" (www.satzansatz.de/cssd/onhavinglayout.html#def).

An element's hasLayout property can be either true or false. When it is true, the element "has layout." Some elements have layout by default, while you can trigger the property via CSS for others. This is not done via a specific hasLayout property but through other CSS properties.

According to Microsoft, the following elements have layout:

And the following property/value pairs will trigger hasLayout to be true for an element:

Many of IE's rendering bugs can be fixed by giving the concerned element layout. A few of the most exasperating rendering issues triggered by elements that have (or don't have) layout are:

There is a lot to be said about hasLayout that would be outside the scope of this book. Although not the most exciting subject in the world, it is easy to understand how important it is to be aware of it and know how best to handle it when faced with a problem. Problems triggered because of the hasLayout property are frequent and often affect the design of the pages in a way that can't just be ignored. We recommend that you read the comprehensive "On having layout" at www.satzansatz.de/cssd/onhavinglayout.html for more in-depth information.

CSS keeps evolving, the specification changes, and browser vendors experiment. And as with any other experiment, things keep changing as they are being perfected over time. What this means in practice for CSS authors is that, as much as we would like to be able to use properties such as border-radius or box-shadow comfortable in the knowledge that they will behave immutably and cross-browser, in reality browsers interpret them differently. The differences might not be great and will probably lead to its eventual homogenizing, but they exist.

This should not be a discouragement from using experimental CSS; quite the opposite. It is by wide implementation of new properties by CSS authors that browser vendors gather the knowledge of how they should operate in a way that is practical and in tune with the real necessities of developers, which will, in turn, reflect on the drafting of future specifications (since they are based on implementations and examples rather than on idealisms).

When working on high-traffic and high-profile websites, one will need to be more careful and mindful of which properties are safe to use and which not. Following the developments of the CSS working group and being up-to-date with new browser releases is fundamental. Participating in the working group, too, is a great way to keep on top of changes, making your voice heard and being a part of the movement. Although, ideally, every member of the team that has to deal with CSS would be interested in keeping abreast of the latest updates, it might be a good idea to appoint one member of the team to be responsible for following the latest news and keeping the rest of the team informed. Setting up an internal mailing list that could be subscribed to by all interested in the matter with links to relevant articles would benefit the front-end team immensely.