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

Re: [filters] Custom filter functions proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 24 Feb 2012 09:14:25 -0800
Message-ID: <CAAWBYDBaD-2KNi3h59usjM4kdDFEwGkc3qX6PY20nQvsU03ciw@mail.gmail.com>
To: Lea Verou <leaverou@gmail.com>
Cc: public-fx@w3.org
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.

I definitely like this idea.

> Issues:
> - Is the SVG Parameters spec still in development? I see it hasn't been
> updated for almost three years.

That's a question for Doug Shepers, I believe.  I've been meaning to
bug him about merging with CSS Variables.


> - This proposal would introduce a dependency on SVG Parameters that might
> not be desirable.

We obviously need *something* for passing data into SVG.  Whether it's
SVG Parameters or CSS Variables, we'll have a dependency.


> - Added complexity may be too much for the benefit it provides.

Nah.


> - Since SVG Parameters allow for a default value too, the `default`
> descriptor may be redundant.

Possibly, yeah.  On the other hand declaring the default up-front is
nicely readable - you don't need to dig into the referenced SVG to
figure out what the default values are.


> - No way to specify optional parameters, such as the ones for <shadow>, it's
> all or nothing. No way to restrict parameter types.

Yup, this is probably unavoidable.  Optional or reorderable parameters
need a grammar, and grammars need some guarantee that they're
well-designed (or else some good fallback rules when they end up being
ambiguous).


> - 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.

calc() should end up being usable everywhere in SVG, I think.


On Fri, Feb 24, 2012 at 7:58 AM, Chris Marrin <cmarrin@apple.com> wrote:
> On Feb 24, 2012, at 2:47 AM, Lea Verou wrote:
>> 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.
>
> What is the type of the src property? Is it a currently a function, so we
> can just drop in shader(...)?

It would need a bit more finessing than that.  shader() (by which I
think you mean the custom() function currently in the Shaders draft)
currently requires you to specify the parameters in the function.
That's obviously not compatible with this proposal.  ^_^

~TJ
Received on Friday, 24 February 2012 17:15:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 24 February 2012 17:15:14 GMT