1. Using CSS3 Today

LOOKING BACK upon the storied history of CSS, we see some important milestones that have shaped our direction as web designers. These watershed techniques, articles, and events helped us create flexible, accessible websites that we could be proud of both visually as well as under the hood.

You could argue that things began to get interesting back in 2001, when Jeffrey Zeldman wrote “To Hell With Bad Browsers” (http://bkaprt.com/css3-2/1/), signaling the dawn of the CSS Age. This manifesto encouraged designers to push forward and use CSS for more than just link colors and fonts, leaving behind older, incapable browsers that choked on CSS1. Yes, CSS1.

We spent the next several years discovering and sharing techniques for using CSS to achieve what we wanted for our clients and bosses. It was an exciting time to be experimenting, pushing boundaries, and figuring out complex ways of handling cross-browser rendering issues—all in the name of increased flexibility, improved accessibility, and reduced code.

Somewhere around 2006 or so, the talk about CSS went quiet. Most of the problems we needed to solve had documented solutions. Common browser bugs had multiple workarounds. We created support groups for designers emotionally scarred by inexplicable Internet Explorer bugs. Our hair started to gray. (OK, I’m speaking for myself here.) Most importantly though, the contemporary crop of browsers was relatively stagnant. This period of status quo gave us time to craft reusable approaches and establish best practices, but things got a little, dare I say, boring for the CSS aficionado yearning for better tools.

Thankfully things changed. Browsers began iterating and updating more rapidly (well, some of them anyway). Firefox and Safari not only started to gain market share, they also thrived on a quicker development cycle, adding solid standards support alongside more experimental properties. In many cases, the technologies that these forward-thinking browsers chose to implement were then folded back into draft specifications. In other words, periodically it was the browser vendors that pushed the spec along.

But Don’t Read the Spec

Ask a roomful of web designers, “Who likes reading specs?” and you might get one person to raise their hand. (If you are that person, I commend you and the free time you apparently have.) Although they serve as important references, I certainly don’t enjoy reading specifications in their entirety, nor do I recommend doing so in order to grasp CSS3 as a whole.

The good news is that CSS3 is actually a series of modules that are designed to be implemented separately and independently from each other. This is a very good thing. This segmented approach has enabled portions of the spec to move faster (or slower) than others, and has encouraged browser vendors to implement the pieces that are further along before the entirety of CSS3 is considered finished.

The W3C (http://bkaprt.com/css3-2/2/) explains the module approach:

Rather than attempting to shove dozens of updates into a single monolithic specification, it will be much easier and more efficient to be able to update individual pieces of the specification. Modules will enable CSS to be updated in a more timely and precise fashion, thus allowing for a more flexible and timely evolution of the specification as a whole.

The benefit here for us web designers is that along with experimentation and faster release cycle comes the ability to use many CSS3 properties before waiting until they become Candidate Recommendations, perhaps years from now.

Now, by all means, if you enjoy reading specifications, go for it! Naturally there’s a lot to be learned in there—but it’s far more practical to focus on what’s currently implemented and usable today, and those are the bits that we’ll be talking about in the rest of this chapter. Later, we’ll apply those bits in examples throughout the rest of the book.

I’ve always learned more about web design by dissecting examples in the wild rather than reading white papers, and that’s what we’ll stress in the pages that follow.

CSS3 Is for Everyone

I’ve been hearing this quite a bit from fellow web designers across the globe: “I can’t wait to use CSS3 . . . when it’s supported in all browsers.”

But the truth is large portions of CSS3 are now very well supported in the majority of browsers, and everyone can begin using CSS3 right now. Fortunately you don’t have to think differently or make drastic changes to the way you craft websites in order to do so. How can anyone use CSS3 on any project? By carefully choosing the situations where we apply CSS3, focusing squarely on the experience layer.

Targeting the experience layer

If we’ve been doing things right over the past several years, we’ve been building upon a foundation of web standards (semantic HTML and CSS for layout, type, color, etc.), leaving many of the interaction effects—animation, feedback, and movement—to technologies like Flash and JavaScript. With CSS3 properties being slowly but steadily introduced in forward-thinking browsers, we can start to shift some of that experience layer to our stylesheets.

As an interface designer who leans heavily toward the visual side of design rather than the programmatic side, the more I can do to make a compelling user experience using already-familiar tools like HTML and CSS, the more I do a happy little dance.

CSS3 is for web designers like you and me, and we can start using portions of it today, so long as we know when and how to fold it in.

When to apply CSS3

In terms of a website’s visual experience, we could group things into two categories: critical and non-critical (TABLE 1.1).

TABLE 1.1: A website’s visual experience can be grouped into critical and non-critical categories. The latter are where CSS3 can be applied today.

Areas like branding, usability, and layout are crucial to any website’s success, and as such utilizing technology that’s not fully supported by the majority of browsers would be a risky venture there.

For example, in the evolving CSS3 spec there are multiple drafts for controlling layout—something we drastically need. We’ve been bending the float property to handle layout for years now. We’ve figured out how to get by with what we have, but a real page layout engine is absolutely a necessity.

That said, the new layout modules in CSS3 are still being worked out and/or they have support only in the most recent browsers. While CSS3 gives us some new layout options for certain design patterns (which we’ll get into later in the book), for something as important as page layout, CSS3 likely isn’t the perfect tool. Yet.

On the opposite end of the spectrum are non-critical events like interaction (hover, focus, form elements, browser viewport flexibility), and visual enhancements that result from those interactions (along with animation). It’s far less crucial to match an identical experience between browsers for events like these, and that’s why it’s a perfect opportunity to apply certain portions of CSS3 here for browsers that support them now.

It’s atop these non-critical events where we’ll be applying CSS3 throughout the book, keeping the more important characteristics of the page intact for all browsers, regardless of their current CSS3 support.

When we decide to focus on and target these non-critical areas of the visual experience, it becomes incredibly freeing to layer on CSS3 and enrich the interaction of a website without worrying that the core message, layout, and accessibility will be hindered.

Core CSS3 Properties That are Usable Today

So, while we’ve pinpointed the experience layer as a place we can safely apply CSS3 today, we’ll also want to pinpoint which CSS3 properties we can use. That is, which portions of the spec have a reached enough of a browser implementation tipping point to be practical and usable right now.

Large chunks of CSS3 have not yet been implemented in any browser. Things are still being worked out. We can be curious about those chunks that are in flux, but we’re better off focusing our attention on what actually works, and lucky for us there’s a fair amount now that does.

Let’s take a quick look at the relatively small set of core CSS3 properties that we’ll be using in the examples in the book (below, and TABLE 1.2). I’m merely introducing them here, as we’ll be digging much deeper into advanced syntax and real-world usage later.

TABLE 1.2: CSS3 properties and the browsers that support them.

border-radius

Rounds the corners of an element with a specified radius value. Supported in Safari 3+, Chrome 3+, Firefox 1+, Opera 10.5+, and IE9+. Example:

.foo {
  border-radius: 10px; }

text-shadow

A CSS2 property (dropped in 2.1 then reintroduced in CSS3) that adds a shadow to hypertext, with options for the direction, amount of blur, and color of the shadow. Supported in Safari 1.1+, Chrome 2+, Firefox 3.1+, Opera 9.5+, and IE10+. Example:

p {
  text-shadow: 1px 1px 2px #999; }

box-shadow

Adds a shadow to an element. Identical syntax to text-shadow. Supported in Safari 3+, Chrome 3+, Firefox 3.5+, Opera 10.5+, and IE9+. Example:

.foo {
  box-shadow: 1px 1px 2px #999; }

box-sizing

Normally, padding and borders are added to an element’s width. This gets annoyingly tricky when assigning percentage-based widths. Applying the border-box value will reverse that and the element’s width will always be what you declare. For instance, a form input with a 100% width, 10px of padding, and a 2px

border will be 100% and not 100% + 24px. Supported in Safari 3+, Chrome 3+, Firefox 2+, Opera 9.5+, and IE8+. Example:

input[type="text"] {
  width: 100%;
  padding: 10px;
  border: 2px solid #999;
  box-sizing: border-box; }

Multiple background images

CSS3 adds the ability to apply multiple background images on an element (separated with commas), as opposed to just one as defined in CSS2.1. Supported in Safari 1.3+, Chrome 2+, Firefox 3.6+, Opera 10.5+, and IE9+. Example:

body {
  background: url(image1.png) no-repeat top left,
  url(image2.png) repeat-x bottom left,
  url(image3.png) repeat-y top right;
  }

opacity

Defines how opaque an element is. A value of 1 means completely opaque, while a value of 0 means fully transparent. Supported in Safari 1.2+, Chrome 1+, Firefox 1.5+, Opera 9+, and IE9+. Example:

.foo {
  opacity: 0.5; /* .foo will be 50% transparent */
  }

RGBA

Not a CSS property, but rather a new color model introduced in CSS3, adding the ability to specify a level of opacity along with an RGB color value. Supported in Safari 3.2+, Chrome 3+, Firefox 3+, Opera 10+, and IE9+. Example:

.foo {
  color: rgba(0, 0, 0, 0.75); /* black at 75% opacity */
  }

Now that list is far from exhaustive, of course. CSS3 contains many more properties and tools, many of which are still being developed and are not yet implemented in any browser. But you’ll notice that each property in the previous list has a reached a certain threshold of browser support: it works in most of the major browsers.

So we now have a nice concise list of properties to play with, based on their relatively decent support in Safari, Chrome, Firefox, Internet Explorer, and Opera. They don’t work in older versions of those browsers, but we’ll be discussing why that’s OK, and how to plan for that non-uniform support later in the book.

What we aren’t going to cover

I’ve listed the handful of CSS3 properties that we’ll be using often in the book, but what about the rest? I’ve chosen not to exhaustively cover everything here, but rather what’s practically usable right now because it has decent, stable browser support.

There are also other portions of the CSS3 spec that might be usable today, but are out of the scope of this book (and might warrant a book entirely on their own):

1. Media Queries (http://www.w3.org/TR/CSS3-mediaqueries/)

2. Grid Layout (http://www.w3.org/TR/css3-grid-layout/)

3. CSS3 Selectors (http://www.w3.org/TR/css3-selectors/)

4. Regions (http://www.w3.org/TR/css3-regions/)

5. Web Fonts (http://www.w3.org/TR/CSS3-webfonts/)

Be sure to check out these other modules after you’ve finished reading this book.

Vendor-Specific Prefixes

I mentioned earlier that the CSS3 specification is a series of modules that are being gradually rolled out by browser vendors. In some cases this rolling out involves experimental support. That is, while the spec is being written, debated, and hashed out at the W3C, a browser maker might choose to add support for certain properties anyway, testing it in a real-world environment. It’s become a healthy part of the process, where feedback from experimental usage is often used to make adjustments to the spec.

Alternatively, a browser vendor might want to introduce an experimental property that’s not part of any proposed standard, but may become one at a later date.

Often this experimental support for CSS properties is handled by the use of a vendor prefix like so:

-webkit-border-radius

This dash-prefixed keyword attached to the beginning of the property name flags it as a work-in-progress, specific to the browser’s implementation and interpretation of the evolving spec. If and when the experiment becomes part of a finished CSS3 module, the browser should support the non-prefixed property name going forward.

Each browser vendor has their own prefix, essentially namespacing their experimental properties. Other browsers will ignore rules containing prefixes they don’t recognize.

TABLE 1.3 shows the most widely used vendors and their associated prefixes, and we’ll be using the WebKit, Mozilla, and Opera prefixes as they pertain to CSS3 in the examples in the chapters ahead.

TABLE 1.3: The most widely-used vendors and their associated prefixes.

How vendor prefixes work

Here’s how vendor-prefixed CSS works in practice; we’ll use the border-radius property as an example. Say we wanted to round the corners of an element with a radius of 10 pixels; here’s how we’d do it:

.foo {
  -webkit-border-radius: 10px;
  -moz-border-radius: 10px;
  border-radius: 10px;
  }

Earlier versions of WebKit (the engine behind Safari, mobile Safari, and Chrome) and Gecko (the engine behind Firefox) browsers each supported the border-radius property by way of their own vendor-prefixed versions, while Opera 10.5 and IE9+ have supported the property without a vendor prefix.

Optimal ordering

When using vendor prefixes, it’s important to keep in mind the order in which you list rules in your declarations. You’ll notice in the above example that we listed the vendor-prefixed property first, followed by the non-prefixed CSS3 property.

Why put the actual CSS3 property last? Because your styles will likely work in more browsers in the future, progressively enhancing your designs going forward. And when a browser finally implements support for the property as defined in the specification, that real property will trump the experimental version since it comes last in the list. Should the implementation for the vendor-specific version differ from the real property, you’re ensuring that the final standard reigns supreme.

For example, Webkit and Firefox have been supporting non-prefixed border-radius for several versions now. It may be safe to simply use the non-prefixed property, depending on your project. However, there’s no harm in continuing to include the vendor prefixes for older browsers.

Don’t be afraid of vendor prefixes!

Your initial reaction might be one of, “Blech, this is messy, proprietary stuff!” But I assure you, not only is it a way forward, it’s much less messy than the code bloat and inflexibility that often come along with non-CSS3 solutions, and an important part of the evolution of the specification as well.

By using these properties now via vendor prefixes, we can test the waters, even giving valuable feedback to browser makers before the spec is final. Remember, too, that the prefixes are usually attached to proposed standards. That’s a big difference from other hackish CSS we’ve all periodically used to solve cross-browser issues.

Some might compare vendor prefixes to the syntax exploits many of us have used to target specific browser versions (for example, using width: 200px or _width: 200px to target specific versions of IE). But rather, vendor prefixes are an important part of the standards process, allowing the evolution of a property in a real-world implementation.

As CSS expert Eric Meyer explains in “Prefix or Posthack” on A List Apart (http://bkaprt.com/css3-2/3/):

Prefixes give us control of our hacking destiny. In the past, we had to invent a bunch of parser exploits just to get inconsistent implementations to act the same once we found out they were inconsistent. It was a wholly reactive approach. Prefixes are a proactive approach.

He goes on to suggest that vendor prefixing is not only positive, but should be made more central to the standards process, and would:

. . . force the vendors and the Working Group to work together to devise the tests necessary to determine interoperability. Those tests can then guide those who follow, helping them to achieve interoperable status much faster. They could literally ship the prefixed implementation in one public beta and drop the prefix in the next.

So, don’t fret over vendor prefixes. Use them knowing you’re a part of a process that allows you to get work done today, and paves the way toward a future when prefixes can be dropped.

It’s also worth mentioning that Chrome, Mozilla, and even the W3C are headed toward ditching the concept of vendor prefixes altogether (http://bkaprt.com/css3-2/4/). For now, they’re necessary, but the future could very well be vendor-prefix-less, where experimental features would be hidden behind special browser preferences. That’ll make using in-progress properties a bit harder for us to implement before full support is offered, which is a bit of a bummer. Something to keep an eye on!

What about all that repetition?

You might think it’s silly to have to repeat what seems like the same property three or four times for each vendor, and I might agree with you.

But the reality is that non-CSS3 solutions would likely require inflexible and more complex code, albeit perhaps non-repetitive.

We won’t need to repeat ourselves forever. For now, it’s a necessary but temporary step to keep potentially varying implementations between browsers separate from the final spec implementation. Fortunately, CSS preprocessors like Sass and LESS help immensely in regards to writing vendor prefix patterns once, keeping them quarantined and easily updated for an entire project. For more on getting started with Sass, check out my Sass for Web Designers book, also from A Book Apart.

Before we start doing compelling things with the handful of usable CSS3 properties and their respective vendor prefixes, let’s get a basic grasp on CSS transitions. Understanding transitions and how they operate will help us combine them with other properties to create wonderful experiences.