RE: Filter Templates

Instead of embedding or referring to SVG filters, could we instead implement a small subset of filters in CSS syntax?

Part of the spec would describe how they will map to SVG.



This would make it very easy for the user to apply simple effects and it would also limit the number of filters that a browser vendor would need to implement.

In addition, since it's CSS with established rules, it could be used in transitions and animations.

Here's a set of canned filters:

1.       blur(X, Y, Q) with

a.       X = width of the blur box

b.      Y = height of the blur box

c.       Q = number of passes

2.       dropshadow(X, Y, Q, C, A, D, S, I, K) with

a.       X = width of the blur box

b.      Y = height of the blur box

c.       Q = number of passes

d.      C = color

e.      A = angle of the dropshadow

f.        D = distance vector of the dropshadow

g.       S = strength (Color of the dropshadow is multiplied by this)

h.      I = inner shadow

i.         K = knockout (just display the shadow, not the original artwork)

3.       gradientglow/bevel

4.       colormatrix



A user could define an animation with the following syntax:
-keyframes animatedblur
{
from{
-transform: translate(-100px, 50px);
-filter: blur(5);
}
to{
-transform: translate(200px, 50px);
-filter: blur(0);
}}


Or he could use a list of filters:
-filter: blur, dropshadow



Rik

> -----Original Message-----

> From: public-fx-request@w3.org [mailto:public-fx-request@w3.org] On

> Behalf Of Cameron McCormack

> Sent: Tuesday, January 11, 2011 12:23 PM

> To: Brad Kemper

> Cc: www-style list; public-fx@w3.org

> Subject: Re: Filter Templates

>

> Brad Kemper:

> > Given the above "feTemplate" values, it could be used in a declaration

> > like this:

> >

> > filter: url(#bradsDropShadow) 4px 5px;

> >

> > ...and the two lengths would be mapped to the "dx" and "dy" of

> > feOffset.dx, and the omitted values would take their default values

> > from the regular filter values ("black" for flood-color and "2" for

> > stdDeviation in the above example), as long as the order and so forth

> > of the feTemplate values were satisfied.

> >

> > Could that work?

>

> I like this idea too – it could be a good solution to the problem that filters are

> often very specific to the content they’re going to be applied to.

>

> As with Tab, I’m not sure about the feTemplate syntax, but I like the idea in

> general.  I think we need to carefully think about what parameters the filters

> are allowed to expose; we obviously don’t want this to turn into a general

> templating solution.

>

> There’s some overlap here with Doug’s SVG Parameters proposal, too, at

> least conceptually:

>

>   http://www.w3.org/TR/2009/WD-SVGParam-20090616/


>

> --

> Cameron McCormack ≝ http://mcc.id.au/