Let’s take an example. Let’s say that our client, Great Sprockets Inc., wants a design with a few rounded corners and semi-transparent backgrounds sprinkled in. We decide not to use progressive enhancement. Everybody should get these rounded corners and semi-transparent backgrounds.

So, we oblige. We create some 24-bit PNGs for the backgrounds. IE6 doesn’t support PNG24 transparency natively, so we add in a call to a script to fix that. We create a few images for the rounded corners, add a couple of extra element to our markup to position them, and we’re good to go.

Now our other client, Even Greater Sprockets Inc., also wants rounded corners and semi-transparent backgrounds. However, recognizing that neither is important to the actual branding of the site, they agree to practice a bit of progressive enhancement.

So, using two lines of CSS, we give rounded corners to all Firefox and Webkit-based browsers. Again, using CSS, we use RGBa to create semi-transparent backgrounds in the browsers that support them, and let others fall back to a fully opaque background color. And that’s it. No images, no extra Javascript calls, and no extra elements in our markup.

One client has ensured that every visitor to their site with a relatively modern browser, regardless of browser capabilities, gets rounded corners and semi-transparent backgrounds. As a result, they added time to the development of their site, and therefore money to their bill. In addition, they’ve increased the time it takes for their page to load by adding a few extra HTTP requests necessary to load the necessary images and scripts.

The other client has offered these embellishments only to browsers that support them natively. As a result, their development time is lower, and so is their bill and page load time. Their branding is still in tact, and their site still looks good, it’s just without a few added aesthetic touches.

Which option makes more sense to you?

CSSDOC was an idea apparently conceived sometime in 2007, and the Second Public Draft of the spec was just released on November 16th. The intent behind CSSDOC is to provide a standardized way of commenting CSS making use of the very well known DocBlock way of commenting source-code.

DocBlock is a very common form of documenting source code in programming that has proven to be very popular for both PHP and Javascript. The beauty of the method is that it’s so simple to use DocBlock to organize your code and since it’s a standardized format, other developers will be familiar with it and tools can be developed to parse it and auto-generate documentation.

There are a great deal of tags being developed for CSSDOC that can provide a lot of great information. For example, here is a sample header from the CSSDOC draft:

1. /**
2. * Homepage Style
3. *
4. * Standard Layout (all parts) for Big Little Homepage
5. *
6. * This style has been designed by Mina Margin. It reflects
7. * the composition of colors through the years of the
8. * customers project as well as the boldness it implies.
9. *
10. * @project Big Little Homepage
11. * @version 0.2.8
12. * @package xhtml-css
13. * @author Mina Margin
14. * @copyright 2008 by the author
15. * @cssdoc version 1.0-pre
16. * @license GPL v3
17. *
18. * @colordef #fff; white
19. * @colordef #808080; standard grey
20. */

Just by this simple header, we’ve already provided a great deal of information to both future developers and to a documentation parser. In our header we’ve provided the project we’re working on, a version number for the project, copyright and author information, and some definitions of recurring colors used in the project.

You then make use of the @section and @subsection comments to divide your CSS file into manageable sections of related styles. I’d love to see this implemented in editors like CSSEdit’s @group comment. For those of you unfamiliar, the @group comment in CSSEdit is parsed out and made into easy to navigate folders in the sidebar (see the image below).

I won’t go through all the available comments (the draft can give you that and does a great job of explaining), but suffice it to say there’s a lot of extremely useful comments available: @affected comment which describes what browsers are affected by a certain bug/workaround; @tested comments to specify what browsers a certain section has been tested on; @fontdef for font definitions, similar to the @colordef rule in the example above; etc.

I’m very excited by this project and think the team behind the spec has done a fantastic job thus far. The few concerns I had, they’ve either addressed, or are in the process of doing so. It’s very easy to get involved with the project as they have been very transparent in the development of the specification.

In addition, if you want to start playing around with CSSDOC a bit on your own CSS, there are bundles made already for editors like Textmate, EditPlus, and KomodoEdit just to name a few. You can keep up to date on new bundles and snippets at http://cssdoc.net/wiki/EditorIntegration.

There are a few solutions currently being utilized across the web. The simplest, and also probably the worst option of them, is to use background images to display our custom fonts. This is not very ideal at all…every time we want to change the text on the site, we have to edit the appropriate background image. A couple less “needy” options are sIFR and FLIR. In both cases, Javascript is utilized to deliver the text in our desired font. sIFR uses Flash to make this happen and FLIR uses PHP. But we are still relying on Javascript to load the fonts onto the page, and there is some performance loss.

Thankfully, we are close to being able to make use of a CSS rule that makes font use so much simpler. The newest versions of all major browsers now support the @font-face rule, which gives us a lot of power over the fonts we can use in our sites. Unfortunately, some of them don’t play too nicely yet. Firefox 3.1 and Safari both implement the @font-face rule very well, but IE only supports EOT fonts and I’ve found Opera 9.6′s support is a bit unreliable. However, in the name of progressive enhancement, there’s little reason why we can’t start making use of this rule to improve our sites now.

Simply Powerful

The beauty of the @font-face rule is both how simple it is, and yet how powerful it is. The @font-face rule includes the rule and the font description like so:

1. @font-face {
2. }

The font description is made up of the what are called font descriptors. Simply put, they follow the same format of typical CSS style declarations. The most basic font description is composed of a font-family declaration and a src declaration that points to the font we will be using, like so:

1. @font-face {
2. font-family: “Benjamin Franklin”;
3. src: url(BenjaminFranklin.ttf);
4. }

The url can be either remote or on your own site. However, for maximum browser compatibility, your font should reside in the same place as the page using it. Firefox, for instance, does not allow using fonts that don’t have the same origin of the page. Instead of using a url, we can also use a local path ( local(font-path) ) that would point to a font located on the user’s computer. We’ve now set the way for us to make use of the Benjamin Franklin font in our site.

1. h1 {
2. font-family: “Benjamin Franklin”, serif;
3. }

More Than Meets the Eye

Simple and easy. Here’s where the fun stuff comes in though. Remember how those declarations, like the font-family declaration above, are called font descriptors? That’s because they describe the declaration that can be used to trigger that font use. Admittedly, that might not be very clear, so let’s extend our example:

1. @font-face {
2. font-family: “Benjamin Franklin”;
3. src: url(BenjaminFranklin.ttf);
4. font-weight: all;
5. }
6. @font-face {
7. font-family: “Benjamin Franklin”;
8. src: url(Hansa.ttf);
9. font-weight: bold;
10. }
11. h1 {
12. font-family: “Benjamin Franklin”, serif;
13. font-weight: bold;
14. }
15. h2 {
16. font-family: “Benjamin Franklin”, serif;
17. font-weight: normal;
18. }

In the example above, we changed the call to the font being used if the font-weight is bold. If the font-weight is anything but bold, then the Benjamin Franklin font is used. If the font-weight is set to bold, then the Hansa font is used. If you have Safari or the Firefox 3.1 beta you can take a look at the code in action. (NOTE: The only reason I was using two different fonts here is to make it obvious that the font is changed based on the font-weight. A more subtle example would be to use a variation of the base font, like a bold version.)

Descriptors give you significant power over the fonts you utilize. Instead of relying on the browser to fake a bold or italic version of the font, we can provide the more professional looking actual italicized, or bolded, version of the font, greatly improving the appearance of our design.

I highly encourage taking a look at the W3C’s information on the @font-face rule and playing around with it a bit. There’s some great examples of some of the powerful ways you can make use of the @font-face rules including an interesting example of redefining the basic serif font-family. Remember, for full functionality you’ll need to either get ahold of Firefox 3.1 or Safari.

Keep in mind that not all fonts are meant to be used in this way. Some font providers encourage you to make use of their fonts freely, other’s don’t. So make sure you’re allowed to make use of the font before embedding it on your site. Both fonts used in the examples, Hansa and Benjamin Franklin, are designed by Dieter Steffman who graciously allows his fonts to be freely used on the web.

Also, while there is a lot of power and control offered with the @font-face rule, still use it with some level of restraint. There is some time involved in downloading the font, so you should probably stick to using this method for headlines only…not body text.

CSS transitions are definitely a cool idea. Using one simple line of CSS, we can specify how we want a particular style to change. For example, a very common thing to do with CSS is change a link’s color when hovered over. To do so, you just use the :hover pseudo-class like so:



Browsers make the color change immediately when a user hovers over the link. Using WebKit’s transition property, we can tell the browser to instead make a smooth transition. For example, to make the color slowly change from blue to red over the course of two seconds, we could do the following:



We tell the browser (line 3) what style we want to animate (color), for how long (2s) and what kind of transition we want to use (linear). If you have the WebKit nightly build, I set up an example using the CSS above. It works great, and the transition is super smooth. Better yet, the other browsers just disregard it and perform the color change as usual. Simple and cool right?

Mixing Things Up a Bit

The problem I have with it is that it I think it starts to put CSS in our behavior layer, which is not so cool. Remember, one of the major benefits to proper use of web standards is being able to separate our content, presentation and behavior onto their own separate layers. By using CSS to make these changes, we make it difficult to interact with these properties using Javascript. Will we have access to information regarding how far into the animation we are? Will the transition fire some sort of onFinish method? Javascript would be needed to add this level of flexibility…not CSS.

While looking around for more information, I was happy to run across a post from late 2007 by Jonathan Snook that shares my opinion on the matter. One thing Jonathan suggested was that while browser animation is not a bad idea perhaps it should have been an extension to the DOM instead. That would offer more robustness and flexibility, and seems to preserve the separation of concerns a bit better.

Don’t get me wrong…I’m very excited about most of the new features on display in the nightly build. I can also see how the line between behavior and presentation is a bit blurred already. After all, isn’t :hover a bit of a behavioral style? I just think that given the potential interactivity here, I have to agree with Jonathan and say that adding a method to the DOM would make more sense in this case.

The Opacity Property

To change the opacity of an element using the opacity property, you simply give it a value between 0 and 1 to determine the elements’ opacity. For example, if I want a div to be 50% transparent, I would give it the following style:



This works fine in Safari, Opera, and Firefox. Internet Explorer, however, doesn’t yet support the opacity property. Instead, we have to use their proprietary property Alpha Filter. It’s really not any more difficult than the opacity selector. One key thing to note hear though is that the Alpha Filter requires you specify the opacity on a scale of 0 to 100. There’s even a catch to that though…the element is that you are applying the opacity filter to has to have a hasLayout value of true. While there are many ways of making an element have layout, some of the most common are to set a width, or give the element a zoom value of 1. So now our declaration is as follows:



Simple enough…but with one catch that may or may not present a problem, depending on your situation. When you use the opacity property, the opacity is set for that element, and any children of that element. This can cause problems in readability and general appearance. If you do have problems in this situation, you may not have to resort to a PNG just yet.

More Power

CSS3 also allows for an extended version of the RGB color model that includes a fourth value that is used to specify opacity. Again, like the opacity property, the alpha value in the RGBA model accepts a value between 0 and 1. We can use an RGBA value anywhere that colors values are accepted in CSS: borders, background, font colors, etc. This already offers a higher level of control than the opacity selector.

Even better yet, while the opacity property defines the opacity for an element and all of its children, using the RGBA value only applies that transparency to the given property of an element that we specify. For example:



Using the background-color property and assigning an RGBA value to it, we are able to define the transparency for the divs’ background color. The transparency of any text or elements inside of the div is unchanged. In contrast, using the opacity property, the paragraph above would inherit the 50% transparency defined on the div.

Unfortunately, as is often the issue, browser support for RGBA is limited. Both Safari and Firefox 3 offer support for the RGBA color value system, but so far Opera and IE do not. The good news though, is that we can use the RGBA value without worrying about it breaking our design by also defining a fallback color.



In most browsers that do not recognize RGBA values, that declaration is simply ignored, as it should be. In IE though (I know, surprise, suprise), it appears that RGBA values cause IE to not display the background at all. A way to get around this would be to use conditional comments to reset the background to a solid color for IE. So we can just define a solid color for browsers that do not accept RGBA values and leave the transparency for those that can support it…a prime example of progressive enhancement.

I have set up a working comparison of RGBA versus using the opacity property for you to view in each browser. Remember, to see the effects of RGBA, you will have to view the page in Safari or Firefox 3.

Static Pseudo-Classes

Pseudo-classes allow us to apply an invisible, or “phantom”, class to an element in order to style it. For example, let’s look at the element most often styled using pseudo-classes: the anchor tag (). Some anchor tags point to locations a user has already viewed, and some point to locations the user has not yet visited. Looking at the document structure, we can’t tell this. No matter if the link is viewed or not, it looks the same in (X)HTML. However, behind the scenes, a “phantom” class is applied to the link to differentiate between the two. We can access this “phantom” class with pseudo-class selectors, like :link and :visited. (Pseudo-classes are always prefixed by a colon.)

The :link pseudo-class selector refers to any anchor tag that is a link…that is any anchor tag that has a href attribute. The :visited pseudo-class selector does exactly what it sounds like…it refers to any link that has been visited. Using these pseudo-classes allows us to apply different effects to links on the page according to the visited state.



For more information about the new pseudo-class selectors laid down in CSS3, take a look at the CSS3 selectors working draft, or the excellent write-up by Roger Johansson. Currently, very few have decent cross-browser support, but as Johansson says, they can still be used for progressive enhancement…and in such a quickly changing field, when we can stay ahead of the curve, we should take advantage of it.

Media types can be extremely useful. For example, there is very little reason to display a site’s navigation on a print-out. Using the print media type, we can then set up a style that hides our navigation section. Handheld devices which have very small screens and often low-bandwidth, may benefit from not displaying a bunch of images.

CSS 2 offered us 10 media types as a way to designate which styles are applied depending on the device that accesses our site:

1. All – all devices (this is default)
2. Aural – speech synthesizers
3. Braille – Braille tactile feedback devices
4. Embossed – paged Braille printers
5. Handheld – handheld devices (usually small screen, low bandwidth, possibly monochrome)
6. Print – printing or print preview
7. Projection – projected presentations (projectors, printing on transparencies)
8. Screen – computer screen
9. Tty – media using a fixed-pitch character grid (terminals or teletypes)
10. Tv – television devices

If no media type is declared, the default is “all”. Using these media types, we can tell devices to only use certain sets of styles. There are three basic ways of doing this:

Using Inline Syles

Inline style sheets are not a very good solution, as they do not separate content and presentation.

Imported Stylesheets

Imported style sheets are a much better solution, and are fairly widely used. A distinct advantage of imported style sheets is that a styles sheet is only downloaded if that specific media type is being used. For example, if I defined the above styles to be associated with the handheld media type and someone using a regular computer came to my site, they wouldn’t have to download the styles.

Linked Stylesheets

This is the most widely supported. As you may have guessed, a user will download each stylesheet regardless of the media type, and then use the appropriate ones. A bit unfortunate, as it wastes a little bit of time downloading styles we’re not really going to use.

It is important to note that some styles only have meaning within a certain media type, and others are not applicable to certain media types. For example, the aural media type has no use for the font-size style while the page-break-before style is really only useful in the media types like projection, printing, and tv.

Unfortunately, the support for most media types is quite minimal. You can pretty much depend on all, screen, and print. However, at this point, only Opera supports the projection media type, and the handheld media type isn’t widely supported yet on handheld devices. Feel free to use them anyway, as even if the user agent doesn’t recognize the media type named, it will just ignore it.

Media Types on Steroids: Media Queries

Media types will eventually become even more useful. CSS3 will implement media queries, which will allow us to check for certain criteria. For example, with media queries we can do something like the following:

What we are telling the user agent is to only use those styles if the device uses a screen media type AND the device is a color device, not monochromatic. The parentheses are required around the text expression to indicate that it is a query. Media queries will allow us to check for items like, width, height, max-width, max-height, min-width, min-height, color, resolution, etc.

Opera already has some limited support for media queries. You can check for height and width values using the pixel measurement in Opera. Hopefully other browsers won’t be to far behind. Actually, to try and push the concept forward a bit, media queries are one of the criteria being built into the new Acid 3 browser test.

You can check out a more detailed look at media queries by looking at the W3C candidate recommendation on the subject.

Most of the time, stacking order just kind of works behind the scenes and we don’t really pay any attention to it. However, once we use relative or absolute positioning to move an object around the screen, we will end up with several elements occupying the same space. Which element is displayed on top is determined by the elements stacking order. We can adjust an elements stacking order by using the z-index property.

The z-index is so named because it affects an elements position along the z-axis. The z-axis is the axis that goes from front to back from the user. If we think of the x-axis and y-axis as height and width, then z-axis would be the depth. The higher the z-index of an element, the closer it becomes to the user, and the lower the z-index, the further back on the screen it appears.

If we do not specify any z-index values, the default stacking order from closest to the user to furthest back is as follows:

1. Positioned elements, in order of appearance in source code
2. Inline elements
3. Non-positioned floating elements, in order of appearance in source code
4. All non-positioned, non-floating, block elements in order of source code
5. Root element backgrounds and borders

Based on the default stacking order above, you can see that any element that has been positioned, whether relative or absolute, will be placed above any element that is not positioned. Both positioned and non-positioned elements are of course, above the background of our root element.

Mixing Things Up A Bit

Now let’s say we want to move some of our elements around in the stacking order so different elements appear on top. We can use the z-index property on any positioned elements to adjust there stacking order. The z-index property can accept an integer, the auto value, or an inherit value. When using integers, the higher the positive number, the further up in the stacking order it will appear. You can use negative z-index values to move the element further down in the stacking order. If we do not use a z-index value on an element, it will render at the rendering layer of 0 and will not be moved. The stacking order now looks like this:

1. Positioned elements with z-index of greater than 0, first in order of z-index from lowest to highest, then in order of appearance in source code
2. Positioned elements, in order of appearance in source code
3. Inline elements
4. Non-positioned floating elements, in order of appearance in source code
5. All non-positioned, non-floating, block elements in order of source code
6. Positioned elements with z-index of less than 0, first in order of z-index from highest to lowest, then in order of appearance in source code.
7. Root element backgrounds and borders

Stacking Context

An interesting thing happens though when we set a z-index value to 0 or auto…we establish a new stacking context. Let’s say we set #front to have a z-index of 5. Now, we have just established a new stacking context for any element descending from (contained in) #front. If #middle is contained within #front, and I set its z-index to 2, it should still appear above #front. Why? Because since we set a z-index value to #front, every descendant of #front is now being stacked in relation to #front. It may be helpful to look at this as a multiple number system (as demonstrated by Eric Meyer in CSS: The Definitive Guide):



Since #front is the ancestor that sets the stacking context, it’s relative stacking level can be thought of as 0. Now when we set the z-index for middle, we are merely setting it’s local stacking value. Of course 2 is higher than 0, and therefore even though in our CSS it looks like #middle should be displayed behind #front, we can see that actually it should be displayed on top.

For an example, consider the following code:



Now, using CSS we position these elements so that there is some overlap:



The result is that #two shows up below #three, even though the z-index value we gave it (line 11) is higher than the z-index value we gave #three (line 17). This is because #two is a descendant of #one, which established a new stacking context. Which means if we use our numbering system, we would get the following stacking order:



Firefox Gets It Wrong

Ok…that felt weird to say. We are all used to Firefox getting most CSS things right, but this is one area it gets wrong. According to CSS 2.1, no element can be stacked below the background of the stacking context (the root element for that particular context). What this means is if we adjust the CSS above to give our #two element a negative z-index, the content of #one should overlap over the content of #two, but the background color should not. The way IE renders this is correct. Both results are shown below:

You can see that in IE, while the content of #one is still set above the content of #two, the background color remains behind it, as specified in CSS 2.1. Firefox on the other hand, shoves the entire #two element, background color and all, behind #one. Until this is fixed, be careful about using negative numbers for the z-index of an element.

Go Forth and Experiment

Definetely take this and play around with it. This is a topic that is best understood by setting up some positioned and non-positioned elements and experimenting with different z-index values. If you are feeling bold, check out the W3C’s really detailed breakdown of the stacking order of not just elements, but their background colors, background images, and borders. As with most topics in CSS, there is more here to understand than we first realize.

Every rule in CSS has a specificity value that is calculated by the user agent (the web browser for most web development purposes), and assigned to the declaration. The user agent uses this value to determine which styles should be assigned to an element when there are more than one rule for that particular element.

This is a basic concept most of us have at least a general understanding of. For example, most developers can tell you that the second declaration below carries more weight than the first:

If both styles are defined in the same stylesheet, any h1 with an id of ‘title’ will of course be red. But just how is this determined?

Calculating Specificity

Specificity in CSS is determined by using four number parts. Each type of value in the style declaration receives some sort of specificity rate:

• Each id attribute value is assigned a specificity of 0,1,0,0.
• Each class, attribute, or pseudo-class value is assigned a specificity of 0,0,1,0.
• Each element or pseudo-element is assigned a specificity of 0,0,0,1.
• Universal selectors are assigned a specificity of 0,0,0,0 and therefore add nothing to the specificity value of a rule.
• Combinator selectors have no specificity. You will see how this differs from having a zero specificity later.

So going back to our previous example, the first rule has one element value, so its specificity is 0,0,0,1. The second rule has one element value and an id attribute, so its specificity is 0,1,0,1. Looking at their respective specificity values, it becomes quite clear why the second rule carries more weight.

Just so we are clear on how specificity is calculated, here are some more examples, listed in order of increasing specificity:

You should also note that the numbers go from left to right in order of importance. So a specificity of 0,0,1,0 wins over a specificity of 0,0,0,13.

At this point, you may be wondering where the fourth value comes into play. Actually, prior to CSS 2.1, there was no fourth value. However, now the value furthest to the left is reserved for inline styles, which carry a specificity of 1,0,0,0. So, obviously, inline styles carry more weight than styles defined elsewhere.

It’s Important

This can be changed, however, by the !important declaration. Important declarations always win out over standard declarations. In fact, they are considered separately from your standard declarations. To use the !important declaration, you simply insert !important directly in front of the semicolon. For example:

Now any h1 with a class of ‘title’ will be purple, regardless of what any inline styles may say.

No Specificity

As promised, I said I would explain the difference between no specificity and zero specificity. To see the difference, you need a basic understanding of inheritance in CSS. CSS allows us to define styles on an element, and have that style be picked up by the element’s descendants. For example:

The em element above is a descendant of the h1 element, so it inherits the purple font color. Inherited values have no specificity, not even a zero specificity. That means that a zero specificity would overrule an inherited property:

The em element inherits the purple font color as it is a descendant of h1. But remember, inherited values have no specificity. So even though our universal declaration has a specificity of 0,0,0,0, it will still overrule the inherited property. The result is the text inside of the em element is gray, and the rest of the text is purple.

Hopefully this introduction to specificity will help make your development process go smoother. It is not a new concept, or a terribly difficult one to learn, but understanding it can be very helpful.

Know the common bugs

Different browsers will handle CSS differently. This is something every CSS developer learns early on, sometimes painfully. Make sure when you come across a bug you force yourself to take a few minutes to look into it and gain an understanding of what is causing the problem. You will be surprised by how few fancy CSS hacks you will have to resort to if you know how to dodge the problems in the first place.

Check your work often

After every couple rules you put into your stylesheet, you should be checking each browser you have access to so you can see what effect the rule had on the layout. The worst thing you can do, in my opinion, is to create your CSS entirely and then check it in each browser. Now you have to wade through all your CSS and try to find where the problem is coming from. However, if you are checking your work after every couple rules, you will have a pretty good idea where the problem lies, and you will be able to fix it that much more quickly.

Know your resources

This may be the most important tip here. Like I said, with so many selectors, properties, bugs, etc. to try and memorize, you will undoubtedly have to turn for help on many occasions. It becomes important for you to know where you can find a solution, and where the solution will be explained in detail enough for you to understand it and be able to avoid it in the future. For example, when I run across a bug that I am not familiar with, the first place I turn to is Position Is Everything. They have wonderful write-ups on various bugs you will find in different browsers. If I just need to lookup a CSS property that I don’t use very often, then I turn to “CSS: The Definitive Guide”, by Eric Meyer. You need to know the places like this that you can turn to for answers.

Know how to troubleshoot

Knowing how to find the problem is half the battle. There’s plenty of ways to go about doing this, so you just have to find the techniques that work for you. While I can say that I haven’t ever used diagnostic styling quite to the extent that Eric Meyer posted in his 24ways article, I am a huge fan of using bright colored borders on my block elements to help me locate problem areas. Commenting out blocks of code at a time can also help a lot when trying to find out what elements have the troublesome styles applied to them. And I cannot recommend the Web Developer Toolbar extension for Firefox highly enough. I am so attached to that thing and its many useful troubleshooting features now that it pains me to work on a computer without it.

Show patience and have a sense of humor

Don’t worry if it seems like it is taking forever to get to the point where you don’t have to look up every little bug. Patience, young Padawan. There are a lot of bugs out there, and it can take awhile before you get to a point where you can recognize one right away.

No matter how much you know, how many books you’ve read, or how many designs you’ve developed, there will still come times where a problem comes up that stumps you for awhile. There is just too much information to digest for you to expect to never run into problems. That’s when you just need to grin and bear it. Keep plugging away and be willing to laugh at simple mistakes you may make along the way. If CSS wasn’t challenging at times, wouldn’t that take some of the fun out of it?