- From: Dean Jackson <dino@apple.com>
- Date: Mon, 7 Feb 2011 10:10:41 -0800
- To: Rik Cabanier <cabanier@adobe.com>
- Cc: Cameron McCormack <cam@mcc.id.au>, Brad Kemper <brad.kemper@gmail.com>, www-style list <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>
- Message-Id: <8504E05B-6882-4D1E-89F1-39A6461F32D7@apple.com>
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/ >
Received on Monday, 7 February 2011 18:13:59 UTC