RE: Filter Templates

Thanks Dean,

I hadn’t read the minutes. It’s good to see that there’s movement on that front.
Let me know when you have a proposal or if you need more info on how we (=adobe) are using filters.

Rik

From: Dean Jackson [mailto:dino@apple.com]
Sent: Monday, February 07, 2011 10:11 AM
To: Rik Cabanier
Cc: Cameron McCormack; Brad Kemper; www-style list; public-fx@w3.org
Subject: 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<mailto: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> [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<mailto: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/