Some CSS3 3D Transform information has been published on IEBlog that’s worth checking out.

I’m continually impressed with the work the IE team is doing, and this continues with that trend.

Advertise here with BSA

Type is an interesting segment of front end development. It’s always felt like an untamed beast, but that’s gotten better over the past couple of years with the adoption of @font-face and the number of foundries now offering Web fonts.

While that handles the font faces themselves, actual layout on page is still quite arbitrary. CSS3 has a number of properties that can and will help with that.

Advertise here with BSA

Novelty side projects are awesome. Unfortunately many are ridiculed for being a waste of time but in my opinion they’re gold when it comes to self-education.

Imagine the OS X Lion experience recreated in CSS3. That’s just what Alessio Atzeni has done, and it’s crazy detailed. Neat stuff to pick apart!

Advertise here with BSA

Although it doesn’t get too much of a spotlight anymore, Opera always has done (and is still doing) a lot of things first, and well. With all of us going off the wall with CSS3, actual render time is becoming a big(ger) concern with each passing day. Opera Dragonfly is aiming to help us out with style profiling:

How sweet is that?! Admittedly I haven’t checked out Dragonfly in some time, but it looks like a lot of work is going into it both under the hood and on the face of things with the UI. I’ll be keeping my eye on this for sure, and I can imagine we’ll be seeing it in our browser dev tools of choice any release now.

Advertise here with BSA

From time to time I’ll hear mumblings of CSS being ‘boring’ or ‘slow-moving’ or just an observation that everything CSS has ‘been done’. I beg to differ.

Every time I think about how exciting JavaScript has become, I try to keep in mind that an equivalent amount of work is being done on the style layer as well. As each browser gets updated, a little more of CSS makes it into the wild.

While pretty much none of this layout magic is truly usable at this point, to try and think about what it’s going to be like putting together a site from scratch in ten years is warping my mind.

Advertise here with BSA

Then there’s Dribbble. Seriously, if I don’t stop now I’ll never get to the book review. On top of the many reasons I respect Dan Cederholm professionally, he seems like a great person outside the modern Web. He’s a guy we can look up to in the most widespread of ways, and I’m appreciative that I’ve been following Dan for as long as I have.

CSS3 for Web Designers

I received my copy of CSS3 for Web Designers, the latest release from A Book Apart, just yesterday; it jumped the (ever growing) lineup of books I’d like to read and went straight to the top. I sat down with a cup of coffee near our freshly set up Christmas tree and got down to reading.

If Dan has a writing style, I’d have to label it consistent. He has a way with words that truly educates as much as it entertains. It’s a really difficult balance to find, something I strive for in my own way. It’s particularly admirable to hit such a stride with technical books. Dan has done it again with CSS3 for Web Designers.

Before talking about the book itself, I’d just like to express how delightful it is to read a printed copy of a book that primarily (and, in this case, singularly) focuses on such modern Web technology. I read a lot online. I appreciate the speedy delivery of a PDF, but I also enjoy sitting down and reading printed copy. I’m happy to see the increase in traditional publications on up-to-date subjects.

On the subject of CSS3

I’ve written before about the real impact of using CSS3 on client work, and much of what I wrote still rings true for me. One of the initial themes I quickly related to in CSS3 for Web Designers was Dan reiterating that while CSS3 can (and should) be implemented today, it should be used with a purpose, and the author should recognize the impact of the decision to use CSS3. Dan is always sure to include the acceptable fallback approach, and he also covers the aspect of future-proofing your styles to ensure forward compatibility.

I’m happy to report that CSS3 for Web Designers covers the exact set of properties I’ve been playing with both on client projects as well as personal work. Properties such as border-radius, text-shadow, box-shadow, multiple background images, opacity, and RGBA are covered from purpose to implementation.

Dan took the time to design a pseudo-site to walk us through the enhancements made to various elements within the design, explaining why and how each property is applicable. I love this approach to education, and in Dan’s traditional style, it worked out well.

In the newly defined A Book Apart style, CSS3 for Web Designers looks beautiful. The type is great, the quality of the book itself is awesome, and there is no shortage of code to check out. I can’t wait to see more of the A Book Apart collection in my library, CSS3 for Web Designers is an excellent addition that I’m sure will be reread at least a few times more if for nothing else than enjoying the quality.

My recommendation

I loved reading CSS3 for Web designers. If an up-and-coming designer asked me what they should know about CSS3, I can confidently say that I’d recommend CSS3 for Web Designers. It truly echos my sentiments regarding CSS3 at this point and with it being such a quick read, designers are sure to be brought up to date rapidly, with the only prerequisite being a basic working knowledge of HTML and CSS (2.1).

Seasoned designers and developers should give the book a read as well. It’s a great reminder that CSS3 should be used for good, not evil. Even professionals need to be reminded of the basics sometimes, and this book does a great job of that.

Giveaway details

If you haven’t had a chance to pick up CSS3 for Web Designers quite yet, I’d love to have the chance to send you one of my copies for free. To enter, just tweet the following:

Looking to win a free copy of CSS3 for Web Designers from @jchristopher /via /x/30

Entries are open for 7 days and will close at 11:59pm Eastern on December 5, 2010. The winner will be announced the following day. I’m sorry to say, but unless you’re willing to pay shipping, the contest is limited to those living the continental US. Each entry on Twitter will be counted once and only once. Good luck!

Advertise here with BSA

See also: Not Supported by Jonathan Snook.

It’s issues like these that have me concerned about whether or not we’re ready for CSS3. Sure, writing a few extra styles isn’t really that big of a deal, right? Yes and no. We’re coming into an age that is accepting a more radical implementation of CSS every day. With that comes even more variance as to how properties (and their values) are implemented. That could very well result in an endless combination of vendor prefixes as well as values that create a major headache for the people actually working with the styles.

PPK goes into quite a bit of detail pleading his case. I urge you to take note.

Advertise here with BSA

There are plenty of times in every project where CSS3 would save me time and effort, but I still consistently weigh the benefit and cost to implementing CSS3 on any level in a client project.

In some recent discussion I’ve had with other designers, a question that’s come up relates to which pseudo-selectors I find myself using most often. Pseudo-selectors are awesome. When it comes to a healthy blend of saving time and accounting for the smallest of details in design, it’s hard to find something that packs more of a punch than pseudo-selectors. I say that because the selectors allow you to more easily define a very particular element you’re looking to style. Of course this is already possible using a targeted combination of elements, classes, and ids, but pseudo-selectors let you do things dynamically.

Thumbnail image galleries

Thumbnails listings are awesome. I really like smart designs that incorporate thumbnails because to me it’s the best of both worlds. You’re able to quickly scan a volume of images and easily discern what you’d like to check out first, all the while without a large latency overhead waiting for assets to download. I also like grids. Thumbnail listings are most often a blatant and literal grid so they’re pleasing to my eye.

That said, I’ve engineered the front end of many projects that incorporate thumbnail image galleries, and with a combination of CSS3 and pseudo-selectors, life gets much easier when it comes to implementation. Even if people don’t recognize why, they can tell when something just doesn’t look right. I think it most commonly arises as a result of centering issues; people can most easily tell when something isn’t quite lined up in the middle. While not trivial to spot with a variety of design elements, a grid consisting of square elements is much easier to discern.

Out of the box, you can style a thumbnail gallery with floating list items possessing a certain width/height and specific thumbnail size. What you’ll end up with is an unbalanced group of images:

ul#gallery { overflow:hidden; zoom:1; width:320px; }
ul#gallery li { width:80px; height:90px; float:left; }
ul#gallery li img { display:block; width:50px; height:50px; }

Naturally, everyone has their own way of styling something like this, some will use margins, others padding, we’ll stick with width for this example. The point is, though, that there’s a better way to handle the end result.

Old and busted

We’ve all done it. It very well might be the only time you’ve used the modulus operator in your given server side language. As we’re dumping out the markup for our thumbnails, we’ll tag on either class="first", class="last", and sometimes both if for nothing more than applying a specific style alteration depending on where in the row a thumbnail sits.

ul#gallery { overflow:hidden; zoom:1; width:320px; }
ul#gallery li { width:90px; height:90px; float:left; }
ul#gallery li img { display:block; width:50px; height:50px; }
ul#gallery li.last { width:50px; }

It’s not a terrible solution, but it’s a bit clunky. When we step back and think about it, we’re simply adding these classes for the sake of presentation. While it can be argued that there’s some semantics to it, more often than not it ends up being on a presentational level. Can you truly say that class="last" benefits the document in any way? What happens when the design changes and there are now 5 thumbnails in a row? It’s just one more thing to consider as time goes on.

The new hotness

Pseudo-selectors open the door for elements like thumbnail galleries. With just an additional selector or two you’re able to cut out the extra classes and improve the maintainability of your document all at the same time. The selectors that will be of most use in this case are structural pseudo-selectors. It’s likely that you’ve seen some of these before, but we’ll cover implementation as a replacement for manually adding classes to elements during page load.

What comes in most handy in this situation is the :nth-child pseudo-selector. As defined by the recommendation:

The :nth-child(an+b) pseudo-class notation represents an element that has an+b-1 siblings before it in the document tree, for any positive integer or zero value of n, and has a parent element. For values of a and b greater than zero, this effectively divides the element’s children into groups of a elements (the last group taking the remainder), and selecting the bth element of each group. For example, this allows the selectors to address every other row in a table, and could be used to alternate the color of paragraph text in a cycle of four. The a and b values must be integers (positive, negative, or zero). The index of the first child of an element is 1.

In addition to this, :nth-child() can take ‘odd’ and ‘even’ as arguments instead. ‘odd’ has the same signification as 2n+1, and ‘even’ has the same signification as 2n.

Easy, right? It’s actually not all that bad. What this selector is going to let us do is most closely related to applying a modulus within a loop server side. It’s going to allow the selector to behave arithmetically, which is awesome. In our example, we’re going to use an nth-child selector that will grab every fourth list item and conditionally apply our desired style.

ul#gallery { overflow:hidden; zoom:1; width:320px; }
ul#gallery li { width:90px; height:90px; float:left; }
ul#gallery li img { display:block; width:50px; height:50px; }
ul#gallery li:nth-child(4n) { width:50px; }

So this is the best of both worlds, right? We’re not injecting unnecessary classes conditionally on the server side, and the rendered result is exactly what we’re looking for. Easy peasy!

Back to reality

Unfortunately, CSS3 is a double edged sword, particularly with client work. If you’re at all concerned about pixel (near) perfection in IE, in any shape or form, you can forget about nth-child().

It’s not the end of the world though. Personally, I would proceed in implementing nth-child() in this case. I’m willing to sacrifice the centering of the thumbnails for IE users, because it’s not a disastrous consequence. Combine that with the ease of implementation, and subsequent ease in maintenance and I’m sold.

It’s up to your discretion, though. If you’re willing to accept that it’s an unknown amount of time before the most popular browser on the face of the Earth will render your thumbnail gallery, go for it. This is just the beginning of nth-child(). I truly suggest you check out the recommendation and become familiar with it. There’s tons of stuff you can do with minimal recoil in substandard browsers.

Advertise here with BSA

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?

Advertise here with BSA

Advertise here with BSA