5 Good Reasons Why Designers Should Code

I’m shocked that in 2010 I’m still coming across ‘web designers’ who can’t code their own designs.

His comment created a great little debate on Twitter.

Personally, I agree with Elliot. I think it’s odd that some Web Designers can’t code their own designs, but only three years ago I was one of those designers. I had been a Graphic Designer for ten years before I ever typed a line of code. Finally learning HTML and CSS in order to code my own designs was the best decision I ever made. Here are five good reasons why I think designers should code.

Reason 1
The combination of a designing in Photoshop (or whatever software you use) along with HTML & CSS is greater than the sum of their parts. Many people view code as a restriction to a designer but when I learned to code I found it liberating. Far from being a restriction, it opened up a whole new realm of creative possibilities. Basically, learning code made me a much better Web Designer.

Reason 2
Your designs will be executed in exactly the way you want them too. If you completely split the duties of designing and coding there inevitably comes a point in a project where the coder ends up doing bits of design, at which point the design can start to degrade. This isn’t the fault of the coder; it’s just real life. It’s just not practical to go back to the designer for a Photoshop mock-up every time a new section of the site needs to be designed/added.

Reason 3
The bridge between designing in Photoshop and code is relatively small. It’s even arguable that HTML & CSS is more a designer’s tool than developer’s. I know some people will say thing like “but you don’t see architects building their designs” etc etc, but in their case it’s far more obvious why.
For example, an architect who wished to build their house after designing it would then have to learn how to drive a JCB, lay bricks, be a carpenter etc. Comparing an Architect and a Web Designer just doesn’t make any sense in this context.

However, when I design a website, after designing the homepage in photoshop I’ll often carry on designing in HTML & CSS. It’s at this point where designing and building almost become one and the same. This is something quite unique to Web and Graphic Design. It just can’t happen when your designing products, cars or buildings.

So, if you’re a designer who doesn’t code it might seem like a daunting task to learn, I know, I’ve been there… but it’s not that hard. Learn it, you won’t regret it.

Reason 4
It’s massively time saving to be able to both design and code. Like I said in my last point, once you reach the point in a project where you feel comfortable designing in the browser you instantly cut out all those Photoshop mock-ups you would have handed over to a coder, only to re-do in code what you’ve already done in Photoshop.

Reason 5
If you’re a designer who can’t code, learning code opens up a whole new world of job opportunities, whether you’re looking for freelance gigs or permanent  employment. One of the main reasons I learnt to code was because I was so frustrated by the lack of opportunities for designers who can’t code.

In Conclusion

Obviously there are times when it’s just not practical or the best use of a designer’s time to be forever updating a website, especially with larger projects but on the whole if you care about how the content on your site is presented I think you get the best results with a designer that knows how to code.

from Carsonified.com

Pros And Cons Of 3 Popular CSS Meta Frameworks

A lot of perennial attention is given to the use and evangelism of CSS frameworks. By “CSS framework,” we don’t mean Blueprint or 960, but rather SASS, xCSS, and Less. These are also referred to as CSS “metaframeworks,” but the distinction between them and Blueprint lies in the distinction between form and function. Frameworks like 960 and Blueprint focus on how things look and where they are placed on a page. Frameworks like SASS and Less focus on the logical representation of styles and the augmentation of the CSS language.

The most common objection to any CSS framework is that designers usually don’t need it. Opponents of both form and function frameworks propose that the inherent mechanisms of CSS, such as cascading styles and selectors, are sufficient for any desired effect. The extension of that argument is that CSS3 will make most form frameworks simply unnecessary due to its broad scope and modern improvements. Function frameworks will also be affected by CSS3 developments, especially CSS variables.

What, then, is the use of CSS frameworks? Do they encourage less code? Clearer code? Are they useful in very specific cases or general situations? Is their implementation and deployment smooth and can the training cost of them be justified? To answer all of the above, We’re going to look at the big three metaframeworks that exist right now: xCSS, SASS, and Less.

frameworks

xCSS
xCSS is newer than the other two frameworks and takes a somewhat different approach in implementation. To use xCSS, one must have a PHP-enabled server (most of us do) and there are some hoops to jump through when installing. One has to insert a SCRIPT tag into their source, then insert a LINK tag, and then comment out the SCRIPT tag. Something about this process feels more laborious than it should.

The actual syntax of xCSS is interesting. Inspired in part by SASS and Object Oriented CSS, xCSS tries to be very DRY (Don’t Repeat Yourself) when it comes to specifying CSS rules. One of the major features is inheritance:

.photo {
self {margin:5px}
a {color:red}
}

The above is the xCSS version of this code:

.photo {margin:5px}
.photo a {color:red}

Another xCSS feature is variables and math operations:

$vars {
$myvar = 1;
}
.photo {width:[$myvar * 2];}

Right away we can see uses for these features. Inheritance can be used to efficiently specify complex style rules and variables can be used for things like color themes and readability modes. But how useful are these developments really?

The best thing about xCSS’s inheritance is that it reduces the amount of code written for large stylesheets. Things like .class1 .class2 .class3 div followed by .class1 .class2 .class3 span would no longer be necessary. Faster loading times and an easier-to-read stylesheet are both benefits of this feature. Where the feature doesn’t offer much is in stylesheets that don’t use deep cascades or don’t repeat an identifier more than once. Using inheritance there would lead to more bloated code that adds extraneous specifications (and some processing overhead).

Variables and math operations make CSS an almost-Turing-complete language. How many times have you thought to yourself “I really wish I could avoid hardcoding the width/margin/padding/color of this element and make it depend on something else?” With a bit of elbow grease, one could define a couple of color variables and have all the shades of the colors computed instantly. No more messing with color pickers! On the other hand, using variables and math operations forces the designer who maintains the project to constantly look up values. There’s no introspection in xCSS, no way to quickly output what a particular element’s computed style is without either loading the page in a browser or searching through the computed CSS. This disadvantage makes variables and math operations useful tools in rapid prototyping, but not so useful (and perhaps counter-productive) in larger sites.

The final verdict on xCSS? Use it for RAD and sites with lots of repetitive stylesheets, but avoid it for too complex or too simple stylesheets. The setup alone is quirky enough to dissuade a non-technical designer, so a more user-friendly version would be huge improvement.

SASS
SASS (or Sass) is a Ruby-powered CSS compiler. What that means is that a designer has to write the SASS code first, run a compile command like sass style.sass style.css and then link to the resulting CSS file. Bothersome? You bet, but there’s a distinct advantage here over xCSS: the compilation step is done by the developer and the resulting code is plain-jane CSS that doesn’t need PHP or JS to function properly.

SASS separates itself from other frameworks by dispensing with curly braces and semicolons altogether. Each rule gets its own line and has to be indented properly. Python users might approve of this, but the inability to write one-liners seriously hinders the readability of code. SASS includes a lot of the features of xCSS, like inheritance and variables, and these look so similar to each other that it’s not worth the comparison, but one aspect of SASS is particularly powerful.

Mixins are the big selling point of SASS. Mixins allow the designer to use up very little space when defining repetitive styles. Here’s an example:

=mixin-sample
color:#fff
display:block
#abc
+mixin-sample
#xyz
+mixin-sample

The above translates to the somewhat repetitious plain CSS:

#abc {color:#fff; display:block}
#xyz {color:#fff; display:block}

Just like inheritance in xCSS, this feature is killer in large sites with lots of repetitive rules. It’s a bit much on smaller projects or projects that don’t repeat rules a great deal. SASS developers go a bit crazy with the mixins, though, and promote the use of arguments with mixins, which frankly looks like a little too much abstraction for readability’s sake.

The final verdict on SASS is that it’s powerful and easy to use, but a bit draconian when it comes to the syntax (although semicolons and braces may be used if one wishes). The extra step of compilation from Ruby makes the use of SASS a bit top-heavy, what with the setup and familiarization of oneself with the Ruby runtime. However, the speed of development in SASS makes it a very compelling choice.

Less
Less is a newer CSS framework that tries an approach similar in spirit, but not in implementation, to SASS. Less integrates practically all of the features used by xCSS and SASS such as variables, mixins, inheritance, and mathematical operations. The difference is that Less tries to be very visibly user-friendly. Variables are prefixed with @ instead of ! or $ to match present CSS conventions. Variables are also defined outside of a variable block, unlike xCSS, making code easier to read. Unfortunately, Less requires Ruby and an extra compilation step, just like SASS.

As far as frameworks go, Less has hit the sweet spot. It’s full-featured, people use it, and it tries to be as transparent and easy to learn as possible. The syntax is immediately obvious and it seems that care was taken to ensure that designers cautious about adopting a framework would feel immediately at ease. If your project is large, complex, and needs to be optimized you need a framework that doesn’t need complicated explanation and Less is it.

Conclusion
The number of CSS frameworks today is large, but the differences between the frameworks are small. It’s important, then, that you, the designer, pick a framework that you most feel comfortable with. xCSS makes sense for those who don’t feel like recompiling their CSS, SASS makes sense for those averse to standard CSS syntax, and Less makes sense because it’s easy to integrate and doesn’t lack any features. However, one must only use a framework if a framework is really necessary. In most cases, proper understanding of the cascade model, inheritance, and selectors is all a designer needs to write efficient CSS.

from Pxleyes.com

We’re Ready for CSS3, but are we Ready for CSS3?

We’re all smitten with CSS3. It’s reinvigorated that sense of newness that CSS and Web Standards brought our way just a few years ago. We’re able to more easily replicate the set of design standards that has become nearly universal much faster than before with just a few CSS declarations. There are a number of CSS3 rules I’d be writing for every project, but I’m just not sure it’s as ready for prime time as many designers are making it out to be.

I’m having an honest-to-goodness back and forth with myself on this issue because I sympathize with two opposing sides to the same issue. I’ve thought about it so much that I’m not sure it’s as much of an issue I’m making it out to be, but would definitely love to have a targeted conversation about it.

I’d like to review the four rules I’d more than love to use without a second thought on every project I work on for the rest of my life, and explain the issues I’ve come up with (so far) regarding each.

Before (and after) I get to the list, however, I’d like to make my stance on CSS3 clear. I love the fact that it directly helps us as designers make a project go that much more smoothly. It helps us reduce the time we take to engineer the front end, allowing us to spend more time designing. I understand that if people are not able to, or choose not to upgrade their browser, it’s something they’ll have to deal with as the Web continues to mature and grow. It makes perfect sense that the faster we all adopt these “bleeding edge” technologies, it puts that much more pressure on the browser makers to implement things properly.

There’s an element of realism, however, that I feel sometimes takes a back seat to the wonderful things CSS3 (and HTML5) are currently offering us.

Border radius
By far the most popular design treatment you’ll find on the Web is rounded corners. I’d be willing to bet that there are more (completely different) ways to achieve rounded corners on the Web than any other design treatment, if such a statistic existed. The creativeness that has gone into the dozens of ways to best round the corners of a div blows my mind. The point here, though, is that it shouldn’t be such a pain to accomplish. With such a popular and generally accepted design treatment, there should be an easier way. Many designers have taken comfort (and a sigh of relief) through border-radius.

As a quick review, border-radius will automatically provide rounded corners on the referenced element. You have independent control over each corner, giving you a wide range of possibilities when adjusting your borders.

Being able to round the corners of a design element using a quick CSS3 rule is inspirational as it stands on it’s own. Combine that with my arguably favorite ability for border-radius to easily round the corners of images as well as elements with background-images and I’m head over heels.

Taking a step back and examining it, I don’t see a tremendously huge problem with using border-radius today on a production website. I’m not able to take advantage of it on client work, however, because no matter how hard I try to convince a client that visitors with less capable browsers won’t know any different, they’re still going to see a less elegant design. And that’s something I completely agree with.

I am not yet comfortable with putting a client site out there that degrades to the point, although completely accessible and usable, it looks unfinished and utilitarian.

Text shadow
The rise of OS X Leopard brought us the wildly popular text inlay effect achieved through a clever drop-shadow treatment to text. Tons of tutorials cropped up rather quickly with instructions to replicate the effect, and it’s something we see fairly consistently in new designs from both big names and small. We can all understand why, it’s a nice looking, elegant treatment that can improve things both aesthetically as well as improve readability when used properly.

Moreover, text-shadow can help on many levels when it comes to readability, and that’s one of the major reasons I’d like to start using it consistently today. It’s something that can be implemented on a very subtle level, and at the same time return some really excellent results without many people noticing.

Truth be told, unless the absence of text-shadow will morph type into something more difficult to read, I think using it is just fine on a client production site.

Multiple background images
If there are any two opportunities CSS3 brings that I would most like to use, it’s border-radius and multiple background images. I can’t begin to fathom the number of divs I could have saved over the past year alone.

CSS3 gives us the ability to layer multiple background images on a single element which can build upon any existing background properties. It’s useful on so many levels, I can’t begin to explain how excited I’ll be when it becomes standard practice to use.

Unfortunately, this is a property I only use on a select few personal projects simply because the degraded result produced is far too different to deem acceptable in my opinion. That is of course unless you’re simply adding just another layer of very subtle refinement. While some intentional results can be put in place with a clever combination of cascading background properties, in my opinion (at this stage) your time is better spent accomplishing your goal the “old fashioned” way.

Pseudo selectors
Pseudo selectors rock. It’s great that they’re so old, many have been implemented in modern browsers, but you can’t become too comfortable with them quite yet. Of anything CSS3 has to offer, pseudo selectors are something I use on nearly every project.

When it comes to pseudo-selectors, I still think of them as a method of progressive enhancement. The way I use them, the selectors provide that extra level of detail to a design that brings it to the next level. Using that approach, I think using pseudo-selectors is absolutely acceptable, and I’d even go so far as to fully recommend that they be used to tighten up the front end on any project. The changes they provide will definitely not be missed by viewers with non-supporting browsers unless you’re so aggressive with implementation, the render is drastically altered by their absence.

While I do tend to use pseudo-selectors, I find myself only relying on a few for the fine details I’m looking to apply.

When it comes to clients
Again, just to reiterate my stance here; these observations should be taken with a grain of salt. I’m only looking at the big picture, not taking into account the nearly endless variables and circumstances that come with every project that graces our monitors.

The biggest hill to climb by far, in my opinion, is getting the blessing of your client to go ahead with this more aggressive approach. After all, we were hired to produce a certain caliber of work. Unless your client is extremely Web savvy, and is somehow opinionated on the topic of how limited we are when it comes to CSS, their main concern will be that the investment they’re making with you will reach the widest audience possible.

The latest argument to skirt this issue is to simply present your comps after you’ve already began front end development. That is to say, some designers feel that presentation of a static comp is no longer applicable directly as a result of wanting to use progressive features such as CSS3. The idea behind it is this: if your client is using a substandard browser, the production site will look exactly like the approved comps simply because they’re using the same underpowered browser the whole time. Meanwhile, visitors with modern browsers will be graced with the much more pleasant version. As the client upgrades their browser, they’ll be elated that this new browser made their website look that much better! Although I’ve never tried that approach, I can’t quite stand behind it.

In my experience, clients are extremely detail oriented. They’re going to ask for more should they see the design in IE6, even if you took the time to beautifully degrade. At that point you have two choices; you can revert to the old school, or you can trek down the path of explaining CSS3 and why they need to trust you on this one. All the while eating those hours.

As I mentioned, this is something I’ve been going back and forth with for some time now, and I think having a conversation on the subject using realistic circumstances and case studies would be superb. What’s your stance on the issue, specifically when dealing with clients and not your personal projects? Do you think CSS3 is simply ready for prime time given the many repercussions involved? At what point will it be acceptable to implement CSS3 and not have to focus on fallbacks and graceful degradation?

from Monday by Noon

Create Resizing Thumbnails Using Overflow Property

Sometimes we don't have enough space to spare to fit in large thumbnails and yet we would like to avoid small and barely recognizable images. Using this trick we limit the default dimensions of the thumb, and show it in full size when user mouse-overs it.

Overview
What we have here is not actual image resizing. It is a resizing of the thumb's visible area on mouse over. How do we do that? Using overflow property!

The overflow property defines the appearance of the content when it overflows the container area. If the container has limited size, for one reason or another, then we use overflow to define what happens. Possible values of overflow property are visible, hidden, scroll and auto. It's the combination of these values that we will use here and make this trick work. Basically, we will hide a part of the thumbnail when in default state, and show it entirely on mouse over.

The Concept
The idea behind this is, to place an image into a certain container. Since we're talking about thumbnails that container would be a link tag. We set the size (width and height) of the container to desired values and we set the position property of the container to relative. Image inside has an absolute position. We use negative top and left values to offset the image. Container has overflow set to hidden so only a part of the image that is placed inside the container's actual area will be visible. The rest of it will be hidden. On a:hover we set the container's overflow to visible, and reveal entire image.

The Code
For markup we use standard link and image tags.

Definition of the default state for thumbnails would be something like this:

ul#thumbs a{
display:block;
float:left;
width:100px;
height:100px;
line-height:100px;
overflow:hidden;
position:relative;
z-index:1;
}
ul#thumbs a img{
float:left;
position:absolute;
top:-20px;
left:-50px;
}

the link tag has defined width and height to whatever fits into our site's design. Also, overflow is set to hidden. We then play with negative top and left values to "crop" the image to a perfect fit. If you want to take this further, you can define cropping area for every single image you have in thumb list and target the area you would like to show.


ul#thumbs a img{
float:left;
position:absolute;
top:-20px;
left:-50px;
}
ul#thumbs li#image1 a img{
top:-28px;
left:-55px;
}
ul#thumbs li#image2 a img{
top:-18px;
left:-48px;
}
ul#thumbs li#image3 a img{
top:-21px;
left:-30px;
}
.
.
.

Now, when user mouse-overs it we set the overflow to visible:

ul#thumbs a:hover{
overflow:visible;
z-index:1000;
border:none;
}

Note the z-index for both default and hovered container. This is very important because we want to place the hovered above it's siblings. Otherwise it would be placed below and the trick wouldn't be complete.

from CSS Globe

CSS3 Pseudo-Class Selectors Emulation in Internet Explorer

Keith Clark, an independent web developer from the UK, has developed a JavaScript solution to IE’s CSS3 shortcomings in relation to CSS3 selectors. CSS3 selectors became the first W3C module to reach proposed recommendation status back in December 2009.

His ie-css3.js project (currently in beta) allows Internet Explorer, versions 5 through 8, to identify CSS3 pseudo-class selectors and render any style rules defined with them. All this is achieved by simply including the script, along with Robert Nyman’s DomAssistant, within the head element of your web pages.

Supported Pseudo-Classes
* :nth-child
* :nth-last-child
* :nth-of-type
* :nth-last-of-type
* :first-child
* :last-child
* :only-child
* :first-of-type
* :only-of-type
* :empty

Limitations of the project
* Style sheets MUST be added to the page using atag. Page level stylesheets or inline styles won’t work. You can still use @import in your style sheets.
* Style sheets MUST be hosted on the domain as the page.
* Style sheets using file:// protocol will not work due to browser security restrictions.
* The :not() pseudo-class is not supported.
* The emulation is not dynamic. Once the styles are applied they are fixed so changes to the DOM won’t be reflected.

How does it work?
ie-css3.js downloads each style sheet on the page and parses it for CSS3 pseudo-class selectors. If a selector is found it’s replaced by a CSS class of a similar name. For example: div:nth-child(2) will become div._iecss-nth-child-2. Next, Robert Nyman’s DOMAssistant is used to find the DOM nodes matching the original CSS3 selector and the same CSS class is applied them.

Finally, the original stylesheet is replaced with the new version and any elements targeted with CSS3 selectors will be styled.
Bypassing IE’s CSS parser

In accordance with the W3C specs, a web browser should discard style rules it doesn’t understand. This presents a problem — we need access to the CSS3 selectors in the style sheet but IE throws them away.

To avoid this issue each style sheet is downloaded using a XMLHttpRequest. This allows the script to bypass the browsers internal CSS parser and gain access to the raw CSS file.

Find out more and Download
ie-css3.js is released under the MIT License and can be downloaded from the project page on Keith Clark’s website.

You’ll also need to download Robert Nyman’s DOMAssistant.

from CSS3.info

How To Support Internet Explorer and Still Be Cutting Edge

Everyone has been going on about how we should use CSS3 more and all of the possibilities and flexibility that come with it, but that we should still consider IE6 and other troubling browsers.

But how do we actually do that? How do we create websites that are up to date with the latest coding techniques but that are also usable for people experiencing the Web on Internet Explorer?

In this article, we’ll see what measures we can take to provide a good experience for IE users but keep moving on. We will mainly focus on the CSS part but will also provide some handy tips on dealing with overall markup.

The Content Is What Matters
Jeffrey Zeldman once said, “content precedes design. Design in the absence of content is not design; it’s decoration.” In fact, the most important thing on your website is the content. This is what everyone should be able to get, no matter which browser they’re using.

Using CSS3 doesn’t mean we should forget about older browsers and lock visitors out of our websites. We should check our websites on browsers as old as maybe IE5 or 5.5 and make sure the content is accessible for every user.

This doesn’t mean we should quit the fight to eradicate IE6 either. We can still follow the example of websites such as Twitter and YouTube and add visible but not dead-end warnings to upgrade.

And remember: each profession has the duty to educate those who are not familiar with their trade. We must explain how stuff works to our clients without being patronizing. It’s not their job to know this after all.

Basics First: The Three Layers (HTML, CSS and JavaScript)
When we create a new website, we do it in steps. First, the HTML. We will mark up our content in the most semantic way possible: titles should be marked up as headings, lists as lists, etc. The bottom line is that our content should be perfectly readable and its hierarchy understandable with only this part of the coding done. The content has to make sense, and we must never forget that this layer is the foundation on which we will develop all the rest.

Secondly, we add the style, the CSS. In this step, we add the visual elements to our design; we give the website its personality. We also make sure that the content is accessible without the third layer.

And finally, the third layer, the JavaScript, the behavior. Here we add the interactive elements to our website. We make the experience richer using things such as tabs, sliders, lightboxes, etc.

With this path in mind, our content will always be accessible in any browser. We make sure that older browsers get only the basic content and disregard more complex layers that could hamper their users’ access to it.
Adding Basic Style For Old Browsers

So our semantic markup is done, and we know that some browsers cannot render CSS properly or at all, such as browsers before Netscape 4.0 or Internet Explorer 4.0. For those browsers, displaying the bare content—the naked version—is the safest choice.

Some people say that, today, there is no need to do this. But if you’d like to make sure that these people on these browsers don’t run into any problems, just link to a basic version of your CSS with the link tag and then to the more advanced file with the @import declaration.

Embracing The Differences
Now let’s deal with the black sheep of commonly used browsers: Internet Explorer 6.

You’ve got two options:

1. If only a negligible percentage of your audience is browsing the Web with it and you don’t want to throw your client’s money down the drain, you could create a basic style sheet for IE6.
2. Acknowledge that your design will not look the same in IE6, and make decisions on what to leave out: which IE6 quirks will you fix and which will you leave be.

If you choose to feed IE6 a basic style sheet, the best course is to use the Universal IE6 CSS. Your website will have virtually no design, but this style sheet makes sure that the body has a readable width, that heading sizes are reasonable and that the content has some nice white space surrounding it.

In your HTML, you will have to add some conditional comments to link to the style sheet and to hide the other sheets from IE6.

In the first conditional comment, we link our main style sheet to all browsers that are not IE6 (hence the “!”). And in the second comment, we link directly to the Universal IE6 style sheet on Google’s repository (and save some bandwidth at that!).

If you prefer the second route, you must be prepared to embrace the differences between browser renderings. Know that some details of your design will not be visible or render as nicely in IE6, or even IE7 and 8. And don’t be upset about it.
Resets

As you know, all browsers have different default styles for the various HTML elements. This is why using a reset style sheet is wise, so that we can start with a clean slate.

Plenty of style sheets are around on the Internet for anyone’s benefit. The one that is usually considered the standard and most often implemented is Eric Meyer’s reset, or some variation of it.

With the advent of HTML5, including the new HTML elements in your CSS reset is also a good idea. html5doctor provides a good update to Eric Meyer’s reset that you can use for free in your projects.

You can use a CSS reset either by embedding it at the top of your own CSS file, or, if you like to keep things tidy, by importing it from your style sheet.

CSS Differences That Could Break Your Layout

If you decide to use the Universal IE6 CSS, you’ve just saved yourself many a headache. But don’t let the shiny logos of IE7 and 8 fool you: if you intend to use the latest CSS techniques, you still have to do a lot to cater to them.

IE6 and PNG support
We all know that PNG images with alpha-channel transparency (i.e. the good-looking ones) don’t play nice on IE6. We’ve all seen that annoying light-blue background on our carefully crafted logos.

You can choose from among a few workarounds to this problem so that IE6 can display PNGs. Each is fairly quick to implement and does make a difference in the overall design.

Here are a few of the best scripts and techniques for dealing with this issue:

* DD_belatedPNG
* Supersleight jQuery Plugin
* PNG 8-bit technique (Fireworks)
* Clever PNG Optimization Techniques
* PNG Optimization Guide: More Clever Techniques

That said, we should mention that more and more Web designers nowadays opt not to fix the PNG issue on IE6:

Advanced Selectors
These selectors are almost the definition of smooth CSS development by themselves, because they hold the true power of CSS and can make our lives as developers so much easier (and our budgets so much lower!).

The decision of whether to make them work on Internet Explorer or not depends largely on what you are using them for.

For example, if you are using them to add extra detail to your designs, such as small icons to represent different file types, it won’t make a lot of difference if the icons don’t display on some browsers. Visitors to your website won’t know what they are missing, and the links will still be perfectly usable.

These selectors are also widely used to enhance typographic detail, and lack of support for them won’t be a big issue for your designs.

Which browsers don’t support this? Internet Explorer 6 will not see styles applied with virtually any advanced selector. It only really understands simple descendant combinators and classes and ID selectors. It even struggles with multiple classes applied to the same element! It’s not to be trusted.

IE7 ignores the :lang selector and pseudo-elements, such as :first-line, :first-letter, :before and :after. But it does understand all attribute selectors.

Also, none of the Internet Explorer releases to date supports the :target pseudo-class, UI element states pseudo-classes (:enabled, :disabled, etc.), structural pseudo-classes (like :nth-child, :nth-of-type or :first-child) or the negation pseudo-element.

Box-Sizing
Box-sizing allows you to tell the browser how you want it to calculate the width and height of an element.

For example, if you set the box-sizing property to border-box, then the paddings and borders will be subtracted from the specified width and height of that element, instead of added to them (as stated in the W3C’s specifications for the standard box model).

This can make it easier to control the size of elements and to make sizes behave the same across different browsers.

If you believe that your website renders in IE in quirks mode (and therefore renders with the non-standard box model), you may want to use this property in your style sheets to make all browsers uniform.

Make sure to add the standard property and the vendor-specific ones:

1 div {
2 -moz-box-sizing: border-box;
3 -webkit-box-sizing: border-box;
4 box-sizing: border-box;
5 }

Which browsers don’t support this? If the website is rendered in quirks mode, IE6 will render using the non-standard box model, so it will already be rendering as if it had the “border-box” property on. You can force IE6 to render in quirks mode. There are a few ways of doing this; one way is by adding an HTML comment before the doctype declaration of your HTML pages.

Media Queries
Media queries aren’t fully supported by most browsers, and Internet Explorer doesn’t support them at all.

However, because they are mostly used to call variations of style sheets for handheld devices, such as the iPhone, this fact is almost irrelevant in that case.

If you use media queries mainly to cater to the iPhone, the fact that they are not supported by other browsers makes no difference anyway, and their use is highly encouraged.

If you are using them to create a more flexible website design that adapts to changes in, say, window size, then know that only Safari, Firefox and Opera support them (partially).

Which browsers don’t support this? Internet Explorer and, in some instances, Safari and Firefox.

CSS Differences That Are Mainly Decorative

These are the issues that are best left alone for non-supporting browsers, because the lack of support won’t be a problem for users who want to access your content (i.e. your pages won’t break).

This has to do mainly with some of the new CSS3 properties, such as border-radius, text-shadow and border-image.

Border-radius
This is the first CSS3 property that designers learned to live without on Internet Explorer, because of its clearly decorative nature. With border-radius, you are better off not trying to replicate it on IE at all. Just let it be.

Which browsers don’t support this? All Internet Explorer browsers. Opera, too.

Font-face
Font-face can be used with IE, but you may need to use Microsoft’s Web Embedding Fonts tool to convert your fonts to EOT.

If you are including both font formats in your website, your CSS will probably follow this structure:

1 @font-face {
2 font-family: "Delicious";
3 src: url("Delicious-Roman.eot");
4 src: local("Delicious"), url("Delicious-Roman.otf") format("opentype");
5 }

Usually, a browser not being able to render the first font in a font stack shouldn’t break the website or hamper in any way the user’s access to the content. So, the recommendation here is to carefully ponder which fonts you want the visitor to see if their browser doesn’t support font-face and has to rely on the fonts you have declared in the style sheet.

Which browsers don’t support this? If you use the EOT version for IE, even IE users will see the correct fonts.

Multiple Columns
Rather than create multiple floating DIVs to organize your text into columns, you can create columns automatically by using the multiple column properties in CSS3. But this means that some browsers won’t see them.

Multiple columns are better used for text, not layout. If you use them on your website, the worst thing that will happen is that visitors see a wider line of text.

If you’re dealing only with short text, than why not go ahead and use it and finish the job in two minutes? But if it would seriously impair the readability of your content, then your best option is to stick to the regular DIVs to create columns.

Which browsers don’t support this? Internet Explorer and Opera.

RGBa and Opacity
RGBa colors are bliss. Rather than use hard-to-update PNG files for backgrounds, you can create the same transparency effect with CSS. But IE doesn’t get it. IE6 doesn’t even understand the PNGs to begin with.

It’s safe to assume that these transparencies won’t usually be applied to elements that cover important content; in which case, the content shouldn’t be behind another element in the first place.

So, when using RGBa colors, make sure to include a normal color before the RBGa one, so that browsers that don’t understand it will still have a fallback color:

1 div {
2 background-color: #FFFFFF;
3 background-color: rgba(255,255,255,.5);
4 }

Opacity can be applied to IE using the opacity filter, but IE filters work only on elements that have layout:

1 div {
2 filter: alpha(opacity = 50);
3 }

Also, remember that opacity works differently than RGBa colors: all of the elements enclosed in this DIV will be rendered transparent.

Which browsers don’t support this? Every browser sees opacity, provided that filters are applied. IE doesn’t see RGBa colors.

Text-shadow
This is an easy call: ignore it. Assuming that the text is still readable, trying to recreate text-shadow any other way than with CSS is a Herculean task. So, unless missing text-shadow would seriously reduce the clarity of a large amount of text, or a small amount (in which case you could use image replacement), you’re better off without it.

Which browsers don’t support this? Internet Explorer.

Border-image
The border-image property gives us an easy way to add beautiful borders to our elements that would otherwise be a nightmare to implement (and that in most instances we would probably choose not to implement).

Because the property is almost always decorative, the best option would be to include a fallback for browsers that don’t support it using the normal border property, and adding the enhanced CSS after it for other browsers.

Which browsers don’t support this? Answering the opposite question is easier: for now, only Safari and Firefox support this feature.

Multiple Backgrounds
This feature depends on the design of your website, but in a lot of cases, the lack of a second or even third background will not affect the readability of the page.

Multiple backgrounds in CSS saves us a lot of the development headaches that were caused by having to use different HTML hooks and nested elements to achieve the same effect. So, if you opt to use multiple backgrounds, you are already choosing which browsers to display the results to.

If all users seeing all of the backgrounds is important to you, then do it the old way and apply different backgrounds to different elements.

If not, your best bet is to give a fallback to browsers that don’t support it: pick the background that you feel is most important or that best fits the overall design and add that property before the multiple backgrounds one. Browsers that don’t support it will ignore the second property.

Which browsers don’t support this? Internet Explorer, Opera and Firefox up until version 3.5 (version 3.6 is currently in beta, but it supports multiple backgrounds!).

Tools

Modernizr
Modernizr is a little JavaScript that is quite useful if you are using advanced CSS properties. It adds some classes to the html tag in your pages, to see whether a browser supports certain CSS features, such as:

* @font-face
* rgba()
* hsla()
* border-image
* border-radius
* box-shadow
* Multiple backgrounds
* opacity
* CSS animations
* CSS columns
* CSS gradients
* CSS reflections
* CSS 2-D transforms
* CSS 3-D transforms
* CSS transitions

Take border-image. When a page loads in a browser that supports the property, it output borderimage. If the browser doesn’t support it, it outputs no-borderimage.

Modernizr doesn’t enable these features in browsers that don’t support them, but rather gives you important information (in the form of classes) that you can use in your style sheets to apply distinct selectors and properties to elements.

IE-7.js
IE-7.js makes IE5+ behave like IE8, supporting more advanced selectors and fixing some rendering bugs. Here’s an excerpt from the creator’s website:

* Added support for advanced selectors: >, + and ~; attribute selectors; :hover, :active, :focus for all elements; :first-child, :last-child, :only-child, :nth-child, :nth-last-child; :checked, :disabled, :enabled; :empty, :not; :before, :after, :content; :lang.
* It uses the standard box model in standards and quirks mode.
* Supports min- and max-width and -height.
* Supports PNG alpha transparency (but doesn’t solve the PNG problem for repeated or positioned backgrounds).

The disadvantage of this technique is that JavaScript has to be enabled for it to work, which is unfortunate. So, you will have to be careful to give users who have disabled JavaScript an acceptable version of your website, especially if some behaviors will not work or, worse, if the lack of JavaScript will break your layout.

Conclusion
Remember that the purpose of this post is not to teach you how to hack IE or deal with its quirks or even how to achieve effects by resorting to JavaScript. Rather, it is to explain how we can design and build websites knowing that differences will arise between browsers.

You won’t see people rioting over the lack of rounded corners on Twitter or WordPress; they aren’t even upset by it, because those differences don’t fundamentally break the websites. People can still use the websites and have a good experience. In most cases, they won’t even notice it!

All we have to do now is explain this politely but seriously to our clients, so that we can all contribute to the ever-evolving Web.

from Smashing Magazine