Last week, with a profound sense of importance, our infamous design engineer, Taylor, offered us the future of graphic art on the Web - CSS filters.
This technology allows your browser to download simple images and text and apply graphics filters from inside the browser, giving you the ability to display effects like drop shadows, weird glows, and a host of other visual effects at a low cost to bandwidth.
The concept behind the filters, which you can explore more in depth in Taylor's piece, is to offer a way of extending the presentational power of the Cascading Style Sheet specification without having to change the language itself; it's a way of piggybacking new functions without rewriting the spec every time. And while this might seem like an obvious direction to move in, it may well be a long and arduous journey. Let's take a look at the issues.
You can start by thinking of CSS filters as much like in HTML. Imagine, for example, if the Web community had to wait for a standards committee to deliberate and create specifications every time some company wanted to offer another plug-in. Each flavor of digital video, every sound and audio format, even different Java apps would require a proposed syntax within the structure of HTML. Blech....
The same would hold true of CSS without filters. Every possible visual effect - from automatic drop shadows to motion blurs and color shifts - would have to be proposed, deliberated, and specified before the design community could move forward. As we've seen with HTML, this just isn't realistic in the hyperspeed world of the Web.
So this time, Microsoft has stepped forward with both a proposal for achieving this in a standard way and an example of implementation (shipping now in Internet Explorer 4.0pr2 for Windows 95). They've proposed it to the World Wide Web Consortium as an addition to the CSS spec. You should take this as a warning: This isn't a standard, or even a recommendation for one - it's merely a proposal by one browser developer, and it could change at any time. Filter your content with care.
We've already talked about how opening up the CSS language to extensibility is a good thing. But think for a moment about the fantastic third-party opportunity that would be available. Although Microsoft's current implementation doesn't allow for downloading and installing filters, it's a logical next step, especially when you notice that their currently shipping filters are simply ActiveX controls.
If there were a common interface for creating new filters, we could expect to see the same sort of convergence of third-party development that has happened with extensible applications like Photoshop, Illustrator, and yes, even Web browsers.
But there's an even more compelling reason to adopt filters: the end of GIF text. Designers frustrated with primitive typographic control on the Web have resorted to encoding their text in graphics. On the Web, pages striving for a unique visual identity almost always demand that users download headlines that are created in a graphics app, then rendered on the page. The price, of course, is bandwidth and degradability. Image-based headlines take time to download and, frankly, no longer exist as text. Think about it: The most important words on your page, the ones you want to stand out, don't show up in search engines, can't be processed by indexers, and aren't even seen if users are surfing with images turned off.
Add a visual effect to a piece of HTML text with CSS filters, however, and you get the best of both worlds. The text is still text (and maintains all the benefits thereof), and your page gets the atmosphere and personality you demand. Cool.
By now, you must be thinking, "Great! Gimme filters. Gimme them now!" But hold on a moment. Not all is rosy.
I've made the analogy to Photoshop filters as a conceptual model for how filters will work on the Web, but there are significant differences between a graphics process application and a client-side manipulation of HTML.
First off, you can't expect every browser on every platform to ship with the same set of identical filters. Therefore, there's got to be a way to download and install new filters when a designer wants to use them on a page.
Uh-oh.
If there's one thing that has frustrated content providers on the Web, it's been the empty promise of Netscape's plug-in architecture. While the idea of opening up Web pages to any media type was exceptionally tantalizing, the reality proved to be all but unusable. Like filters, plug-ins often need to take advantage of an operating system's native features, such as screen-drawing routines or multimedia libraries. That means they must be rewritten for each platform, and delivered independently to the users of those platforms. Not exactly seamless. And I won't even get into the security implications behind automatically installing executable code....
The Photoshop analogy also breaks down when you consider applying filters on a user's machine rather than creating the effect on your end and shipping the result down the wire. In Photoshop, you know exactly what the pixels will do when you apply a filter. You can craft drop-shadows exactly and blur out type with precision. But in the volatile and inconsistent universe of your readers' computers, how will those effects be rendered? You still can't make assumptions about installed fonts or screen size and resolution. Big issues indeed.
But filters are still a good start. Just as Netscape plug-ins and Java applets can give us a glimpse of a rich, networked environment, so can filters enable us to start thinking about extensible visual presentations on the Web.
This article appeared originally in HotWired.
