W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2012

Re: [filters] Custom filter functions proposal

From: Rik Cabanier <cabanier@gmail.com>
Date: Sun, 19 Feb 2012 07:48:40 -0800
Message-ID: <CAGN7qDBRNZ4guX38VmKv63+aZuzp37pYphLSoxDUG81VUpdNxQ@mail.gmail.com>
To: Lea Verou <leaverou@gmail.com>
Cc: public-fx@w3.org
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?


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)
Received on Sunday, 19 February 2012 15:49:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:46 UTC