Re: [filters] Custom filter functions proposal

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.

Can you write out a complete example of such a filter?

Rik

On Sat, Feb 18, 2012 at 4:48 PM, Lea Verou <leaverou@gmail.com> wrote:

> The filter functions defined by the Filter Effects draft [1] are
> tremendously useful, however there will always be the case where something
> more custom is needed. To solve this, the current syntax provides the
> ability to reference arbitrary SVG filters and shaders.
>
> I think it would be even better to additionally provide a mechanism that
> combines the simplicity and ease of use of filter functions with the power
> of referencing arbitrary SVG filters. In other words, a way to define
> custom filter functions that refer to a certain parameterized SVG filter.
>
> This could be done with SVG Parameters [2], so I'm merely suggesting some
> syntax sugar on top of that, to ease readability, avoid repeating URLs and
> facilitate sharing of filter libraries between authors. Also, to make
> custom filters animatable, as UAs generally don't interpolate between IRIs.
>
> This would allow authors to write:
>
> filter: foo(1.5);
>
> instead of:
>
> filter: url(path/to/filter/filterlib.**svg?foo-amount=1.5#foo-filter)**;
>
> as long as the `foo` function was defined with an @filter rule that
> references the filter and defines the function arguments (a subset of the
> SVG’s params). It would accept the following descriptors:
>
> Name: src
> Value: <iri>
> An IRI reference to a ‘filter element’ element that defines the filter
> effect. For example "url(commonfilters.svg#large-**blur)"
>
> Name: name
> Value: <string>
> The name of the custom function. If it collides with a predefined
> function, it overrides it.
>
> Name: parameters
> Value: <string>+
> The (space separated) parameters the function accepts, in the order it
> accepts them. They correspond to parameters in the SVG document with the
> same name.
>
> Name: default
> Value: <string>
> The default value, when the function is called with no arguments.
>
> Issues:
> - Is the SVG Parameters spec still in development? I see it hasn't been
> updated for almost three years.
> - This proposal would introduce a dependency on SVG Parameters that might
> not be desirable.
> - Added complexity may be too much for the benefit it provides.
> - Since SVG Parameters allow for a default value too, the `default`
> descriptor may be redundant.
> - No way to specify optional parameters, such as the ones for <shadow>,
> it's all or nothing. No way to restrict parameter types.
> - The markup equivalent of most predefined filter functions includes basic
> math on the arguments, such as [1 - amount]. Not sure how this would be
> possible with this proposal, as SVGParams doesn't seem to allow
> calculations.
>
> [1]: https://dvcs.w3.org/hg/FXTF/**raw-file/tip/filters/index.**html<https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html>
> [2]: http://www.w3.org/TR/SVGParam/
>
> --
> Lea Verou (http://lea.verou.me | @LeaVerou)
>
>