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.
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:
A few months ago, after helping to co-author HTML5 & CSS3 for the Real World, SitePoint asked me to do a related video screencast series on their new Learnable.com website.
I agreed, and the course has been available online now for a few weeks. It was a fun experience, and it’s motivated me to plan for some screencasts here on this site, too. I won’t go into great detail on the course here — you can review the course contents on Learnable.com at your leisure.
Basically, the course consists of 28 separate video tutorials that make up 9 full lessons. Most of the videos are about 10 to 15 minutes long, with a few under 10 minutes, so they’re pretty easily digestible. Lesson 10 is a “resources” section that I’ll probably continue to add to, and Lesson 11 is a “bonus voucher”.
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.
As much as we would like to turn a blind eye to the large number people using Internet Explorer and thus take advantage of CSS3 and HTML5 in all its glory, with certain projects, we really don’t have much of a choice.
If the traffic in a particular niche is IE-heavy, then you have to deal with that accordingly. If you go the Andy Clarke route then you may choose to use those new enhancements to the full, but allow a degraded experience in IE.
If you go the traditional corporate route, then you do everything you can to get IE to look and behave the same as the other browsers. That could mean ignoring a lot of new CSS3 and HTML5 stuff, or else it means filling in the gaps with scripts, hacks, and IE-only filters.
Two other authors took part in this exciting new project: Estelle Weyl — who probably doesn’t need much of an introduction if you’re familiar with many conference speakers in the web standards world — and Alexis Goldstein, a well-rounded programmer from Brooklyn.