Re: [filters] Custom filter functions proposal

Hi Chris,

that's a terrific idea.
Depending where we go with the security model, we could design a way to
switch to the SVG filter implementation if we detect that the shader
violates the rule. Could this still be done with a media query? It seems
that more would be necessary...
(This is of course assuming that SVG filter don't suffer from the same
security issues.)

Rik

On Thu, Feb 23, 2012 at 5:06 PM, Chris Marrin <cmarrin@apple.com> wrote:

>
> On Feb 19, 2012, at 8:31 AM, Lea Verou wrote:
>
> On 19/2/12 17:48, Rik Cabanier wrote:
> > Hi Lea,
> > I can see how this would be very useful.
> > It would also allow people to create libraries with filters that could
> be used as short hands.
>
> Exactly! This is one of the benefits I mentioned ;)
>
> > Can you write out a complete example of such a filter?
> > Rik
>
> Sure. My imagination is running kinda low at the moment, so lets assume
> hue-rotate wasn't already in the draft.
>
> An author would include this filter in an SVG called filterlib.svg (which
> could obviously include other filters as well):
>
> <filter id="hue-rotate">
>  <feColorMatrix type="hueRotate" values="param(angle) 0"/>
> </filter>
>
> Note that the syntax of param() and its default value (of 0 here) is
> defined in SVGParam [1].
>
> And then would define it as a function in their CSS like so:
>
> @filter {
>  src: url(/path/to/filterlib.svg#hue-rotate);
>  name: hue-rotate;
>  parameters: angle;
>  default: 0;
> }
>
> And then they'd be able to use hue-rotate() as is currently defined by the
> Filter Effects draft.
>
> An alternative syntax could include the function name outside the braces,
> @keyframes-style:
>
> @filter hue-rotate {
>  src: url(/path/to/filterlib.svg#hue-rotate);
>  parameters: angle;
>  default: 0;
> }
>
> `default` isn't really needed in this case, as the SVG already defines a
> default, so it could be omitted.
>
> [1]: http://www.w3.org/TR/SVGParam/
>
>
> I really like the idea of an @filter rule for customized filter functions.
> But I'd really like to be able to define a CSS shader as the underlying
> implementation. SVG filters give authors a lot of power. But they're very
> difficult to hardware accelerate. If @filter can accommodate both SVG
> filters and CSS shaders it leaves authors with path for assuring a hardware
> acceleration path. Assuming there is a media query for SVG filter and CSS
> shader support, authors can supply both and the appropriate one can be
> chosen for the platform.
>
> -----
> ~Chris
> cmarrin@apple.com
>
>
>
>
>