CSS3

Now that the numbers for IE6 and IE7 usage are diminishing rapidly, more and more development teams are starting to weed out support for those older browsers.

Most readers will probably have removed IE6 completely from the equation and soon IE7 will follow. Despite IE8 still having the highest share of any single browser version, the demise of IE6/7 now allows us to be more creative with CSS selectors.

This post will provide a comprehensive review of support for CSS3 selectors in the most troublesome browsers (guess which ones?). Each selector links to the appropriate location in the CSS3 spec.

A List Apart’s Issue #344 went live yesterday with a focus on the recent vendor prefix drama. I didn’t get a chance yet to read the entire Meyer/Tantek interview, but I did read Lea Verou’s piece.

First of all, congratulations to Lea for getting published in ALA. She’s certainly one of the most talented web developers I know, and deserves to be featured in such a context. I hope Zeldman and company continue to use new and fresh authors like her.

So what’s the point of my post here? And what’s the deal with the hyperbolic title that resembles Lea’s? Well, in many ways, this post is a response to what Lea wrote in her article. But this is not to say that what I’m going to write necessarily contradicts or opposes what she’s written. For the record, I agree with the spirit and forward-thinking approach in her post.

About a year and a half ago, I wrote about CSS3’s word-wrap property. The angle of the article was the fact that it was a feature that was new in CSS3 that didn’t exist in CSS2.1 and it worked in just about every browser, including old IE.

Well, now that’s all changed, which I discovered while researching additions to my CSS3 Click Chart. The word-wrap property has been removed from the CSS3 spec and other related properties have been added.

Over the past month or so I’ve been slowly working on a redesign and revamp of my CSS3 Click Chart.

A whole slew of things have changed. Here’s a summary.

Currently, there are still a number of CSS3 properties that will not work unless you include all the various vendor prefixes. And that number is growing now that IE10 has added support for a bunch of new properties and features.

Let’s look at a simple example of some CSS3 keyframe animation code that includes other prefixed CSS3 properties, and consider a problem that might arise when trying to future-proof the animation code.

As of this writing, the full code required to cover all current browser support, plus future support for the standard syntax, would look something like this:

The other day someone on another post asked a question about validating your stylesheets. This person is concerned with the fact that the validator views vendor prefixes as errors.

Here are my thoughts on this subject, with some tips on using the CSS validator, if you decide that you’re still concerned about validation to some degree.

After messing around with CSS3 keyframe animations for a few months now, I realized (as is the case with most CSS3 stuff) repeating the code can be annoying.

For CSS3 animations, it’s worse. You have to write sometimes dozens of lines of code for a single rendering engine (I always start with WebKit) then copy all the code two more times, then change the prefixes to get it to work in another rendering engine (in this case Gecko/Firefox) and have a standard equivalent.

After a quick search, there didn’t seem to be a tool to do this (other than whatever find-and-replace functionality you have in your text editor), so I wrote one myself. It’s called Animation Fill Code.

The CSS3 fonts module has a number of interesting CSS3 properties and features. Browser support for many of these is pretty limited right now, but I thought I’d summarize some of these features here.

The first three properties discussed here are CSS3 properties, while the last section will discuss features that have existed for a while but that you may not know about because of their limited potential for use.