Re: [filters] Custom filter functions proposal

The src descriptor could accept multiple values so that if one can't be 
used, fall back to the 2nd, 3rd etc, like the src descriptor in @font-face.

Lea Verou (http://lea.verou.me | @LeaVerou)

On 24/2/12 06:22, Rik Cabanier wrote:
> 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 
> <mailto: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 <mailto:cmarrin@apple.com>
>
>