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.
