Tuesday, June 29, 2010

Stop Forking with CSS3

It seems like virtually every day there’s a fantastic new example of something amazing you can do with CSS3. Whether it’s as complex as full-blown animations or as (relatively) simple as RGBa colors, drop shadows, or rounded corners, I marvel at how far we’ve come since the lowly days of CSS1 or (shudder) the @font element.

The current state of CSS3 reminds me of a typical cinematic device: The scene opens with us, this happy-go-lucky family of developers out for a picnic by the lake on a beautiful summer afternoon. And as we laugh, play, and scamper about entertaining ourselves, the camera pans around, bringing us over to the lake where, beneath the surface, something stirs. Something ominous and foreboding.

Okay, perhaps that was a bit over-dramatic, but what I’m trying to say is that we’re ignoring the beasts within our code, hiding just out of view: forks.
What?

If you’ve been working on the web for more than a decade (I’m probably dating myself), you may remember that bleak time in web design history when JavaScript was a dark art. It earned that reputation because in order to do anything with even the teensiest bit of cross-browser consistency, you had to fork your code.

It was standard practice to have one set of JavaScript functions for Netscape and another set for Internet Explorer. Or, if you were a real masochist, you kept the code combined and created a fork inside the function:

function doSomething(){
if (document.getElementById)
{
// web standards FTW!
}
else if (document.all)
{
// do something in IE
}
else if (document.layers)
{
// do something in Netscape 4.x
}
}

In many cases, especially where animation or event handlers were concerned, the code got really gnarly, easily topping even the most atrocious spaghetti code in HTML. The thing about forking your code is that, when you least expect it, it will find a way to fork you right back.

Now, thanks to Web Standards Project browser-standards advocacy and diligent JavaScript library authors, the world of JavaScript is a much nicer place to work and play. Our code is now relatively fork-free, with fewer nooks and crannies in which bugs can hide. Unfortunately, in our rush to use some of the features available in CSS3, we’ve fallen off the wagon.

I think @border-radius was the proverbial “candy” that the forks used to lead us back into their clutches. We all wanted them; hell, we’d come up with myriad ways to fake rounded corners to realize our design dreams. So when Firefox and Safari dangled them in front of our drooling faces, asking only that we add two small forks to our code for the privilege, we jumped at the opportunity.

.this-is-awesome {
border-radius: 5px;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
}

They were only two small forks, after all, how bad could they be?

Well, once we had symmetrical rounded corners, we wanted asymmetrical rounded corners. After all, we need to be able to express ourselves and there comes a time when every man, woman, and child must stand up and set the radius of each corner independently! Unfortunately, Webkit doesn’t like the @border-radius shorthand, but that just means we need to be a little more verbose:

.this-is-slightly-less-awesome {
border-radius: 10px 5px;
-moz-border-radius: 10px 5px;
-webkit-border-top-left-radius: 10px;
-webkit-border-top-right-radius: 5px;
-webkit-border-bottom-right-radius: 10px;
-webkit-border-bottom-left-radius: 5px;
}

Oh, and we probably want to make sure Opera and Konquerer can get the rounded corners too (assuming Opera’s supporting them this week).

.this-is-absurd {
border-radius: 10px 5px;
-moz-border-radius: 10px 5px;
-webkit-border-top-left-radius: 10px;
-webkit-border-top-right-radius: 5px;
-webkit-border-bottom-right-radius: 10px;
-webkit-border-bottom-left-radius: 5px;
-o-border-radius: 10px 5px;
-khtml-border-top-left-radius: 10px;
-khtml-border-top-right-radius: 5px;
-khtml-border-bottom-right-radius: 10px;
-khtml-border-bottom-left-radius: 5px;
}

Now, are you seeing a problem here? Does it remind you of anything we used to do in our CSS?

.can-you-hear-me-now {
padding: 10px;
width: 200px;
w\idth: 180px;
height: 200px;
heigh\t: 180px;
}

Or perhaps you were more fond of something in a nice Tan.

.hooray-for-repetition {
padding: 10px;
width: 200px;
height: 200px;
}
* html .hooray-for-repetition {
width: 180px;
height: 180px;
}

Call it forking, call it hacking, call it what you will; we shouldn’t be doing it.
Another way

As you can probably tell, forks get me a little riled up. Rather than just getting angry about it, however, I decided to build a JavaScript library that supports clean living (or at least clean CSS): eCSStender. (Actually, the original impetus behind the library was a little different, but we’ll get to that in a bit.)

Boiled down to its essence, eCSStender (pronounced “extender”) is a JavaScript library (akin to jQuery or Prototype) specifically built for working with CSS. On its own, eCSStender doesn’t do anything but analyze your stylesheets. When powering “extensions,” however, eCSStender allows you to use properties such as @border-radius and selectors like @.seven:nth-child(even) without having to resort to forks or hacks.

If you’re developmentally inclined, you’ll be interested to know that eCSStender not only gives you introspection into the style rules contained in your CSS file(s) and provides a framework for testing a browser’s support (or lack thereof) for things like selectors or properties, it also provides a mechanism for you to patch browser support for CSS.

If, however, you’re more inclined toward the design side of things, you’ll be happy to know that using eCSStender and a handful of extensions allows you to write advanced CSS simply. It Just Works™.

.this-is-so-much-better {
border-radius: 5px;
}

Using eCSStender

Using eCSStender is pretty straightforward. You simply include the eCSStender library and whichever extensions you want to run against your CSS.

Or, you can pick and choose the pieces you want from the currently available extension bundles and create your own custom extension library.

So where do you get these extensions? Well, I have developed a number of extensions that offer CSS3 functionality and have bundled them such that they correspond to the various modules of CSS3, such as borders and backgrounds, selectors, and color. I am also aware of several other JavaScript wizards who are working on other pieces of the CSS3 puzzle, including a multi-column layout and more. A complete list of known extensions is being maintained on the eCSStender website and, if you’re interested, the website also has extensive documentation on how to roll your own.

Once you have included the JavaScript files, you simply go about using the properties as the spec defines them, and the extensions work their magic to translate what you wrote into something browsers understand. The beauty of this setup is that your stylesheets remain clean and fork-free; the extensions do all the dirty work for you.

Extensions are built to be smart, too. Using the eCSStender API, they can test to see whether or not the property or selector you want is supported in the current browser. If the property is supported, the extension doesn’t run, but if it isn’t supported, the extension is activated. So in the case of border-radius, Safari 5 implements the standard property and the border-radius extension is not run, but in Safari 4, which only understands -webkit-border-radius, the extension needs to run and makes the necessary translations. Once the majority of browsers accessing your site are savvy enough to grasp standards without the hand-holding, you simply delete the extension just as you would a conditionally-commented stylesheet for a version of IE you no longer need to support. Easy-peasy.

You’d probably like an example, right? Well, the eCSStender site is certainly one, but I’ve thrown together another one on the off chance you’d like to see a combination of CSS3 goodies in action. It makes use of:

* @border-radius,
* @box-shadow,
* RGBa backgrounds,
* @transform: rotate(), and
* @transition (assuming your browser supports it in some form).

Make sure you hover the box.
Yeah, but “extend”-er?

As I mentioned earlier, eCSStender was not originally designed to act as browser spackle; in fact, the original intent for the library, when I began writing it nearly three years ago, was to make it easy for each of us to get involved in crafting future versions of CSS. Through eCSStender, we can play with new ideas and see our concepts realized in an actual browser. It provides an easy way for us to experiment with syntax and see what works and what doesn’t without having to wait for native browser support.

If you’ll indulge me for a moment, I’ll give you an example. Say, for instance, I thought it might be interesting to imbue elements with physical characteristics and I wanted to use CSS to do it. I might create a new property (with a vendor-specific extension of “easy,” to indicate my company) called @-easy-physics-fill that would take one of several substances, such as “lead,” or “helium,” as its value. With eCSStender I can easily build an extension to look for that new property and apply the requisite physical properties. It’s a contrived example, but I think you get the point.

Used in this way, eCSStender empowers us to show the W3C what we want to see next in CSS. And it can help the CSS Working Group evaluate syntax and experiment with new ideas without having to wait for a browser vendor to implement them. This could streamline the process, as ideas that don’t work well in practical application can be jettisoned before the underlying codebase of any browser has been modified. And who knows, maybe the W3C would even consider an extension to be a valid implementation used as part of the standards-development process.
Pitching the forks

As a library, eCSStender has a few modest goals. First and foremost, it aims to offer robust tools for designers and developers to make working with CSS better.

On one hand, it seeks to equalize support for CSS across all browsers by offering a simple set of developer tools that makes crafting extensions easy and implementing them a breeze. On the other, it provides those same tools to designers and developers who are interested in conceiving and then building real implementations of the properties, selectors, and mechanisms they want to see in future versions of CSS.

Perhaps my dream of a world with equalized CSS support across browsers is pie-in-the-sky thinking, but I like pie. Even if it is best eaten with a fork.

from A List Apart

Thursday, June 17, 2010

8 Signs of a Great Client

Client work can be fun and rewarding, or it can be frustrating and discouraging. Freelancers deal with clients on an every day basis, so there are bound to be some good and bad experiences in the mix. Recognizing and appreciating a good client can sometimes lead to more of the same as you may be able to find ways to work with the client on an on-going basis, or you may be able to encourage referrals who will have some of the same characteristics.

From my experience, good clients have a number of common characteristics besides simply paying on time. In this article we’ll take a look at some signs of a good client, and why they are important.

1. They Have Realistic Expectations

All clients are unique and they all have different needs. Unfortunately, it’s very common for a client to have unrealistic expectations about how you can help to meet those needs. I’m sure we’ve all received emails or calls from potential clients that want a large, dynamic website with great design for a bargain basement price.

Pricing isn’t the only potential area for this situation. You may have a potential client that approaches you today and tells you that their site needs to be live in 2 weeks, when you know that their requirements will take far longer.

Dealing with unrealistic expectations and doing your best to communicate why they are unrealistic is often part of the job. When you are working with a client that has realistic expectations in terms of pricing, the time frame of the process, the amount of work that is involved, and the need for their participation in the process, that’s a good sign that they will be a pleasant client to work with.

2. They Know that a Good Website Costs Money

With such a huge number of freelancers and design studios in the marketplace, there is a very wide variety in terms of pricing. Typically, the cost of the service will generally correspond to the quality of work and the end result. Unfortunately, many clients don’t understand that they will usually get what they pay for, and if they want a quality website that meets their needs, they will have to spend some money.

Personally, I think it’s great that there are designers who are working at all kinds of different levels of pricing, and starting low is an effective way to gain some experience and learn while picking up some clients. However, clients often see a big gap in price difference and get hung up on that fact and fail to realize the potential variance in quality of work that they’ll receive.

When working with a client who understands that getting results with a website will require some investment can be a great thing for the designer/developer because the emphasis is then on creating the best website, not on getting it done quickly to keep the price down. This is the ideal situation for everyone involved.

3. They Can Give You a Description of What They Want from Their Website

Most designers like to have some creative freedom in their projects, rather than working on something that is completely dictated by the client. However, having a client that provides very little or no direction is not ideal either. The client knows their business much better than any designer would, and they should be able to have an idea of what they need to get from their website in order for it to be a valuable asset to the business. Likewise, they are more aware of their business’s identity and how it should be portrayed to visitors of the website.

While working with complete freedom may be nice for designers, it usually won’t produce results that are most effective for the business. The ideal situation is a client who knows specifically what they need from their website and is willing to work with a designer to get this accomplished. The best design process involves the client and the designer coming together to combine their expertise to create something special.

4. They Provide Constructive, Descriptive Feedback

Most clients don’t have a problem with providing feedback, but it may not always be the most helpful. I’m sure we’ve all had situations where a client says they don’t like the way you have something on the site and asks you to change it. But if they don’t give some descriptive details about what they don’t like or how they would rather have it, you’re taking a shot in the dark that they will like the changes you make. Nothing is more frustrating than changing something multiple times because you can’t get clarity on what they want.

When clients are able to give feedback to your ideas or to your work that is helpful and descriptive, your job will be much easier, and the client is also more likely to be pleased with the end result. Sometimes getting this feedback may be something that the designer can encourage by emphasizing the need to truly understand what the client wants in order to produce the best results.

5. They Respect Your Time and Their Own

While clients will not always understand what is specifically involved in the design and development process and the details of time consuming it can be, they should generally have a respect for your time. Designers, especially freelancers, understand that time management is critical to success, so we are forced to respect our time. Some clients, however, forget that you have other clients and responsibilities that may prevent you from being on call to them at all times.

During the design process there are any number of ways that designers can wind up wasting time because of poor communication. For example, in most cases if the client has an issue with part of the design that needs to be changed, the sooner the designer is made aware of the problem the less time it will waste. Of course, many clients won’t think of issues like this, so it is up to the designer to communicate the need for effective communication in order to prevent lost time. Hopefully the client will understand and take the appropriate measures to help ensure that time is not wasted.

Likewise, I prefer to work with clients who have a great deal of respect for their own time as well. A client who respects their time will be well-prepared, will be willing to pay for services that will save them time, and will be prompt and accurate with communication throughout the process.

6. They Take Their Website and Their Business Seriously

Occasionally you may be working with a client, and at some point in the process you may feel like they just don’t take their website seriously. Maybe they’re not getting involved in the process by helping you to get to know their business. Maybe they underestimate the potential impacts of the website on the business. Or maybe they just want a website to have one, but they don’t really care about the details.

Because the design and development process requires a time investment from the client and the designer, the ideal client will respect the need for a quality website and will be willing to do what is needed to make sure that it is done right.

7. They Take Time to Effectively Plan with You

One of the most difficult parts of the design process with some clients is the planning aspect. You’ll have clients who want to give you a one-paragraph description of their business, and they expect that you’ll be able to create the prefect site for them. Unfortunately, planning is probably the most important part of the design process, but some clients don’t want to dedicate any time to it. Without this, the project is highly unlikely to be very successful.

When you come across a client that appreciates the need to properly plan the website, this is a sign that the client will be good to work with. A client who is interested in planning understands that a designer cannot just magically create a site that works for their business without their input.

8. They are Careful to Choose the Right Person for the Job

The ideal client will realize that not every design is right for the job, and not every job is right for the designer. When the designer and the project are a good match, positive results will follow. When they’re a bad match, poor results will usually follow. However, some clients want to choose a designer very quickly for any number of reasons without really taking the time to find out if they are the best fit.

When I get an inquiry from a potential client that gives specific details about their project and what they need, I’m always more impressed than when I get a one sentence email that says “How much will you charge to design my website?” By giving me some details about what they are looking for, it says to me that they are concerned with finding the right person for the job.

Creating Fancy Checkmark Icons with Pure CSS3

I was recently working on a personal project where I wanted to implement some cool “checkmark” icons like you see at left to spice up my unordered lists. I could’ve done it quite easily with the list-style-image property, but I was trying to keep my images and http requests to a minimum, so I wanted to figure out another way to do it (plus, the challenge sounded kind of fun).

I had just seen Nicolas Gallagher’s awesome pure css social media icons, though, and I thought, “If he can do that, than I could certainly create a simple check icon with just css3″. I did figure it out with some experimenting and testing, and today I’m going to show you how to achieve the same effect.

The #1 Rule of CSS3 Coding

Before we start on any project, we have to remember the number one rule of CSS3 coding. Well, actually it’s two rules:

  • It must be cross-browser acceptable. I’m not talking identical, but a CSS3 technique is not very useful if it destroys the experience for users with older browsers. Use progressive enhancement.
  • No worthless markup! I know CSS3 is fun, and it’s not bad to experiment, but if you have to add a whole bunch of non-semantic junk markup just to save yourself from needing to use an image, you’ve defeated the point.

These are the two principles that I regard to be the unchangeable law for using CSS3. So anyways, enough of my rant – I just feel with all the buzz about CSS3 that it’s very important to use it in a mature and responsible way. Let’s move on with the tutorial :)

The Concept

Before we can start coding, we have to figure out what approach we’re going to take to create these icons. How is it going to be done?

Taking some inspiration from Nicolas Gallagher’s work, I think the best way would be to use the :before and :after pseudoclasses to generate the round circle and the checkmark shape. By using the unicode no-break-space (\00a0) as the content attribute, and the setting the display to block and styling it, we can create a huge variety of empty shapes. A checkmark icon lays well inside the boundaries of possiblity!

Also, in order to implement surefire progressive enhancement we’re going to use the :nth-of-type selector to make sure that only CSS3 capable browsers try to display the icons (older browsers will fall back on simple, default bullet-points). The :nth-of-type is a lifesaver and hugely useful for this, because the support for it lines up exactly with support for the border-radius and transform properties that will be necessary to render the icons.

The Code

OK, now that we’ve got the general concept figured out, we can start coding. We’ll start with the html for a basic, unordered list (copied from html-ipsum.com).

01.<ul>
02. <li>Morbi in sem quis dui placerat ornare. Pellentesque odio nisi, euismod in, pharetra a, ultricies in, diam. Sed arcu. Cras consequat.li>
03. <li>Phasellus ultrices nulla quis nibh. Quisque a lectus. Donec consectetuer ligula vulputate sem tristique cursus. Nam nulla quam, gravida non, commodo a, sodales sit amet, nisi.li>
04. <li>Pellentesque fermentum dolor.li>
05. <li>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.li>
06. <li>Aliquam tincidunt mauris eu risus.li>
07. <li>Praesent dapibus, neque id cursus faucibus, tortor neque egestas augue, eu vulputate magna eros eu erat. Aliquam erat volutpat. Nam dui mi, tincidunt quis, accumsan porttitor, facilisis luctus, metus.li>
08. <li>Vestibulum auctor dapibus neque.li>
09.ul>

We’ll start with a very basic CSS style that will be applied to all browsers:

01.ul{
02. margin: 12px;
03. padding: 0;
04.}
05.ul li{
06. margin: 0 0 12px 0;
07. font-size: .9em;
08. line-height: 1em;
09.}

Now, onto the fun part. First, we’ll style the list items (for CSS3 browsers only) to have additional padding on the left (to make room for the icons), to be positioned relatively so that we can absolutely position the icons, and to hide the default bullets:

1.body:nth-of-type(1) ul li{
2. list-style-type:none;
3. padding: 0 0 0 45px;
4. position:relative;
5.}

Now, using the :before pseudoclass we’ll add a small black circle to the left of each list-item – the first half of the icon. We use before so that it will nest behind the checkmark, which will be generated using :after. Here’s the code:

01.body:nth-of-type(1) ul li:before{
02. /*fill it with a blank space*/
03. content:"\00a0";
04.
05. /*make it a block element*/
06. display: block;
07.
08. /*adding an 8px round border to a 0x0 element creates an 8px circle*/
09. border: solid 9px #000;
10. border-radius: 9px;
11. -moz-border-radius: 9px;
12. -webkit-border-radius: 9px;
13. height: 0;
14. width: 0;
15.
16. /*Now position it on the left of the list item, and center it vertically
17. (so that it will work with multiple line list-items)*/
18. position: absolute;
19. left: 7px;
20. top: 40%;
21. margin-top: -8px;
22.}

All that’s left is to create the checkmark and put it on top of the circle. We can do that very easily by giving the :after element a white border on the bottom and left, and then rotating it 45 degrees:

01.body:nth-of-type(1) ul li:after{
02. /*Add another block-level blank space*/
03. content:"\00a0";
04. display:block;
05.
06. /*Make it a small rectangle so the border will create an L-shape*/
07. width: 3px;
08. height: 6px;
09.
10. /*Add a white border on the bottom and left, creating that 'L' */
11. border: solid #fff;
12. border-width: 0 2px 2px 0;
13.
14. /*Position it on top of the circle*/
15. position:absolute;
16. left: 14px;
17. top: 40%;
18. margin-top: -4px;
19.
20. /*Rotate the L 45 degrees to turn it into a checkmark*/
21. -webkit-transform: rotate(45deg);
22. -moz-transform: rotate(45deg);
23. -o-transform: rotate(45deg);
24.}

We’re finsished! Here’s what the final product looks like:

All that remains now is to integrate it into your design (changing the border colors of the before/after elements if need be)!

Some Thoughts

So that’s it. In closing I have a few thoughts about this technique:

On the downside, relying on the :nth-of-type selector is a bit risky, since a browser that recognized that selector but didn’t support CSS rounded corners and rotation would end up rendering a distorted version of the icon. Some older versions of Opera have this problem. I think that’s a pretty small issue, though, since I’m not aware of any browsers (and certainly not any with more than negligible market share) that fit that description. Also, it could be argued that it’s not worth it just to avoid using one small checkmark image. I don’t think that’s necessarily true, but it is something to consider (for reference, the css code that created the icons is .57kb when compressed).

Overall, though, I think it’s a stylish, imageless touch that could fit well into a lot of design situations. It’s a creative use of CSS3, it doesn’t require extra markup, and it degrades with near perfect gracefulness, so overall I’m proud of the idea and think it’s pretty robust.


from WebITEtc.net