Re: Filter Templates

If you read the minutes of the public-fx telecon, which you are welcome to attend btw, you'll see that we did agree to move forward on a set of canned filters. I volunteered to write up a proposal.

I agree with Rob's followup about complexity as well. 

Dean

On Feb 6, 2011, at 2:06 PM, Rik Cabanier wrote:

> All,
>  
> I never heard back on my proposal.
> Is it because it’s too limited or doesn’t rely on SVG?
>  
> I believe the CSS filters need to be very simple so
> -          They can be accelerated on the GPU
> -          The can be implemented by browsers that choose not to implement SVG filters.
>  
> rik
>  
> From: Rik Cabanier 
> Sent: Wednesday, January 26, 2011 2:57 PM
> To: 'Cameron McCormack'; Brad Kemper
> Cc: www-style list; public-fx@w3.org
> Subject: 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/
>