Adobe’s CSS Shaders proposal, which will bring high-quality cinematic effects to the web through some new CSS tools, has been accepted by the World Wide Web Consortium (W3C).

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.]

Sisyphus, by Max Klinger. The four ladies up top are named Gecko, WebKit, Trident and Presto. Image: Max Klinger via Wikimedia

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.

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.

If all you want to do is know when to use <section> and when to use <article>, the HTML5 spec isn’t very helpful. To eliminate the confusing nature of the spec, the WHATWG, one of the two groups that oversees the creation of HTML (see our overview of the difference between the WHATWG and HTMLWG) has released a version of the HTML5 spec written specifically for web developers.

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.

Now you’ve got no excuse for not reading up on HTML5.

See Also:

• HTML5 Will Be Done in 2014, What Comes Next?
• Meet HTML, The Spec Formerly Known as HTML5
• Where on the Web Is HTML5?

Apple posted a showcase of “HTML5 and web standards” on its website Thursday that highlights the level of support for the emerging standard in the company’s Safari and Mobile Safari browsers.

It’s nice to see Apple (or anyone for that matter) talking about HTML5 and mentioning more than just video. The site showcases HTML5 audio and canvas elements, as well as CSS 3 transitions and typography tools. It also has a nice photo gallery that looks and behaves just like former Apple designer Mike Matas’ amazing photo-gallery site.

Unfortunately, the way Apple presents the showcase, you would think Safari is the only web browser that supports these new web standards.

In fact, visit the site with any other browser and you’ll get a message telling you to download Safari. Surely your browser must be inadequate? Actually, your browser is probably capable of handling the showcase just fine, but ultimately the showcase isn’t about web standards: It’s about Apple’s version of web standards.

Apple is detecting the user-agent string (the bit of identifying data your browser passes to a web server when it requests a page) and only allowing Safari users to see the galleries. Other browsers are effectively cut off, regardless of the fact that many can render them just fine.

Worse, Apple’s CSS code uses only WebKit-specific selectors — for example, -webkit-border-radius instead of the actual CSS 3 selector border-radius. WebKit is the open source engine that powers Safari and Google Chrome. Firefox, IE and Opera can’t understand this code as clearly.

So much for web standards. Not only is user-agent sniffing absolutely the wrong way to determine the HTML5 capabilities of the current user, the implicit suggestion is that HTML5 is something only Apple supports.

Microsoft recently published its own HTML5 showcase to hype the coming release of Internet Explorer 9, and its demo pages are viewable (and work) in any non-IE browser with the proper support. Mozilla’s HTML5 demo pages are geared to work with experimental builds of Firefox, but at least other browsers aren’t blocked, and most of the demos actually work in Chrome.

To test Apple’s demos in other browsers, we spoofed the user agent in Firefox and Chromium and found that, while several examples do indeed fail in Firefox, most worked just fine. Naturally, everything works without issue in Chromium, because it uses the same WebKit rendering engine as Safari. Apple is being disingenuous by making its browser seem more compelling than others. That’s not surprising, but we’d be disappointed to see independent developers follow suit. [Update: As several commenters, and John Gruber point out, the version WebKit that Chromium uses doesn't yet support all of CSS 3's 3D transforms, which renders this demo incomplete, though still functional, in Chrome/Chromium.]

So how should you detect whether the current browser can display whatever bit of HTML5 or CSS 3 you’re using? The long-established best practice is to detect for features, not browsers. To find out which features are available in the current browser isn’t hard — there are even several free, open source libraries out there that do just that.

Modernizr is one of our favorites. This handy little JavaScript library can detect which HTML5 features are available. Then, armed with that information, you can then create conditional JavaScript statements to offer HTML5 to those browsers that support it, but still fall back on other content for those that don’t.

There are however, some cases where Modernizr might be overkill. For example, if you just want to embed some HTML5 video, you only need to detect one element. If Modernizr isn’t right for your project, check out Mark Pilgrim’s list of ways to detect HTML5 elements. The list of elements and how to detect them is an appendix to Pilgrim’s book in progress, Dive Into HTML5.

The list isn’t just elements, though it does cover those as well. But it also shows you how to detect API support for things like offline storage or geolocation, as well as SVG, SVG-in-HTML and even which video codec the current browser supports.

One thing Pilgrim doesn’t cover is CSS 3 features (CSS 3 != HTML5). To detect which CSS 3 features are available in the current browser you can use Modernizer or you can roll your own code using a library like jQuery, which includes a support() method to check a wide range of browser features before executing code.

See Also:

• Handy Guide to Detecting Support for HTML5
• Where on the Web Is HTML5?
• Beautiful Websites: Former Apple Designer’s Amazing Photo Gallery
• Beautiful Websites: Slippy for Presentations