That means CSS Shaders will become a web standard, though not on their own; instead the W3C is going to roll CSS Shaders into the CSS Filter Effects specification. The feature formerly known as Shaders will now be referred to as Custom Filters

The original name “Shader” has its roots in the 3-D graphics world and roughly describes what “Custom Filters” will do, namely create 3-D effects, like the rippling motion in a waving flag, by “shading” regions.

In the end the name isn’t that important; just know that Custom Filters will allow web developers to easily apply cinema-style filter effects to any HTML content. Think grayscale-to-color transitions, animated shadows, photo-realistic warping and other mainstays of the 3-D animation world.

You’ll still need a special build of WebKit that Adobe put together to see Custom Filters in action. You can grab the experimental browser from the GitHub page, where you’ll also find plenty of examples and sample code that show how shaders, er, Custom Filters work. Also be sure to check out Adobe’s earlier write-up on how Filters work and how you can use them.

Now that Shaders are an official part of CSS, hopefully web browsers will begin adding support.

[Update:The original title of this post was Adobe’s CSS Shaders Now an Official Web Standard, wherein I intended “Official Web Standard” to mean “a part of the web standards process”, not actually a published W3C recommendation. Judging by the comments that’s how most of you took it, but of course it was definitely possible to read it as something more than it actually is, so the headline has been updated to clarify that point.]

CSS expert Eric Meyer thinks that a new proposal, CSS Vendor Tokens, might offer a way out of the CSS vendor prefixes mess.

CSS vendor prefixes were designed to help web developers by providing a way to target CSS rules to specific browsers and use proposed standards before they were finalized. Alas, while they have helped, they’ve also hurt the web.

The W3C’s CSS Working Group is currently in the process of trying to fix some of the problems. We’ve covered one proposed solution from Florian Rivoal, which would make vendor prefixes into aliases and ensure that when a browser implements a new CSS feature, it will work both prefixed and unprefixed.

Another proposal that Meyer wrote to tell us about comes from François Remy, who proposes what he calls Vendor Tokens. “I propose we use unprefixed properties from start,” writes Remy in a message to the www-style mailing list, “but with a token explaining which version of the property we built our CSS for.”

Essentially what Remy proposes is to use a flag much like !important, but to signal which version of the CSS property the rule is aimed at. The advantage is that instead of targeting browsers directly, you’re targeting a draft version of the spec.

Here’s Remy’s example of the syntax:

selector {
border-radius: 1em !webkit-draft;
}

It’s a bit less typing than the current method, which would require four lines to convey the same information and, as Meyer suggests, dropping the -draft would simplify things even more. But more important than a simpler syntax is that, as Remy explains it: “any browser which is not webkit but implemented border-radius in a way that is compatible with the ‘webkit draft’ can support the declaration.” That’s a little different than vendor prefixes. With Remy’s proposal other browsers wouldn’t need to impersonate webkit, “they just acknowledge they support one specific property the way the webkit draft defines it.”

So a more full-featured declaration might look like this:

selector {
border-radius: 1em !webkit-draft !moz-draft !o-draft;
}

Remy also includes a way to handle scenarios where Apple’s version of WebKit might differ from Google’s or even account for differences in versions of the spec.

As Remy admits, there are some drawbacks to this approach, and the syntax isn’t the cleanest we’ve seen, but as Meyer writes, “it feels cleaner than trying to do the same thing with prefixes.”

It will likely be some time before the CSS Working Group makes a decision on what, if anything, to do about vendor prefixes. If you’re interested in keeping up with the discussion on this and other proposals keep an eye on the www-style mailing list.

CSS vendor prefixes were designed to help web developers by giving them a way to target CSS to specific browsers and use proposed standards before they were finalized. The idea was to move the web forward without rushing the CSS standards process. Unfortunately, it hasn’t always worked out that way. In fact, web developers fell in love with the -webkit- prefix and often forget that there are other prefixes as well: -o- for Opera, -moz- for Firefox and -ms- for Internet Explorer.

Now Opera says that to remain competitive it plans to support -webkit- in addition to its normal -o- prefix.

The problem, in Opera’s view, is that instead of writing code that will work in any web browser, some of even the largest sites on the web are coding exclusively for WebKit (the rendering engine that powers web browsers on the iPhone, iPad and Android phones). Web developers have, the argument goes, created the same sort of monoculture that used to exist around Internet Explorer, with websites proudly proclaiming they “work best in WebKit.”

In most cases Opera, Firefox and Internet Explorer support the same CSS features found in WebKit. The problem is that developers are only using the -webkit prefix, so only WebKit browsers render the effects. As a result, Opera, Firefox and IE look like less capable browsers even when they aren’t.

Opera web evangelist Bruce Lawson writes on the Opera development blog, “this leads to a reduced user experience on Opera and Firefox, which don’t receive the same shiny effects such as transitions, gradients and the like, even if the browser supported those effects” (emphasis in original).

Non-WebKit browser vendors first started talking about implementing the -webkit prefix earlier this year during a CSS Working Group meeting. Microsoft, Mozilla and Opera all said they felt the need to support -webkit, lest their users be relegated to an inferior browsing experience (because so many sites are using only the -webkit prefix).

While it’s not hard to understand Opera’s position, we’re disappointed to see Opera moving forward with this plan.

The very real danger is that if other browsers implement -webkit prefixes then the entire CSS standards effort will be broken.

Instead of coding against a single CSS specification developers will need to code against changing vendor prefixes. As CSS Working Group co-chair, Daniel Glazman, wrote when Opera first floated the idea, “I don’t think this is the right way. And this is the first time in this WG that we are proposing to do things that are not the right way.”

We at Webmonkey hope it’s obvious that building WebKit-only sites is a mistake. If you’re only interested in iOS users then take a tip from Instagram and build a native app. As Peter Linss, Hewlett-Packard’s CSS WG representative and co-chair of the working group, said at the earlier CSS WG meeting, “there’s no advantage to the web to have someone write a platform-specific website.” There’s no real advantage for the developer either, especially when an automated CSS prefixer can do all the work for you. So, if you’re using prefixes, we encourage you to take the time to add them all, test your site in as many browsers as possible and make sure your site works for everyone.

Chances are, despite embracing the tools therein, you’ve probably never read the HTML5 spec. We don’t blame you. Frankly the worst part of this job is when we have to translate gibberish from the actual HTML5 spec into words normal humans can understand.

The problem is that the HTML5 spec is written for browser makers, not web developers, and contains highly technical and very esoteric language.

The W3C’s web developer version of the spec is still more technical than the WHATWG’s version, and nowhere near as nice to look at, but at least you can read the HTML5 spec without all the notes about conformance criteria and other browser maker-specific lingo. Flipping between the two web developer versions it’s actually not hard to wrap your head around when to use <section> and when to use <article>.

If you’ve ever tried to wrestled your way through the complexities of the HTML5 specification, we’ve got good news — there’s now a “web developer edition.”

The main HTML5 spec can be overwhelming for web developers trying to understand how to use HTML5 in their sites and web apps. Much of the spec is written for browser makers and other implementers, not web developers, and contains highly technical and very esoteric language.

The web developer version of HTML5 strips out all the elements that are only of interest to browser makers, and focuses on developers, making for a more readable, understandable document. In other words, it makes sense to mere mortals.

As an added bonus, the new website hosting the web developer version has a much cleaner, simpler design that doesn’t look like it crawled, zombie-style, out of 1994.