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

Re: [filters] Custom filter functions proposal

From: Brad Kemper <brad.kemper@gmail.com>
Date: Sat, 18 Feb 2012 19:21:23 -0800
Cc: public-fx@w3.org
Message-Id: <C5FDD94D-1B7B-43CA-B21E-FB6AA87CDC06@gmail.com>
To: Lea Verou <leaverou@gmail.com>

On Feb 18, 2012, at 4:48 PM, Lea Verou 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
> [2]: http://www.w3.org/TR/SVGParam/
> -- 
> Lea Verou (http://lea.verou.me | @LeaVerou)
Received on Sunday, 19 February 2012 03:21:54 UTC

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