Re: [filters] Custom filter functions proposal

Hi Vincent,

About your question, let's assume we have a filter in filterlib.svg with 
the id #foobar and the parameters x, y, z of types number, length and 
color respectively and we want them specified in the same order in our 
filter function, which is going to be called foo(). With my proposal, it 
would be something along these lines:

@filter foo {
     src: url(filterlib.svg#foobar);
     parameters: x, y, z;
     default: 0 1pt black; /* this means that filter: foo(); is 
equivalent to filter: foo(0 1pt black); */
}

I didn't use "array" like in your example, since that doesn't correspond 
to a CSS type. Also, I assumed that we want the arguments to be 
whitespace separated, rather than comma separated, as this seems 
consistent with the filters already defined in the draft. I'd like a 
mechanism to avoid the need for a specific order when it's not required 
for disambiguation (like in drop-shadow() where the color can be either 
first or last), but I can't think of anything right now.

However, please note that one of the issues I initially pointed out is 
that my proposal lacks the ability to constraint parameters by type, 
which is serious as it could potentially waive one of the biggest 
advantages of this idea: interpolation. This could be easily solved by 
extending the `parameters` definition to allow for types, so that it 
would become:

parameters: x of number, y of length, z of color;

or just:

parameters: x number, y length, z color;

The type keyword would be the same as the ones defined for CSS3 attr() 
[1]. The order needs to be specific (parameter name first, type second) 
otherwise we won't be able to have parameters with the same name as a 
CSS type which could potentially lead to confusion.

However, I'm not very fond of this idea, as I think that if something 
like this is needed, it needs to be addressed by SVGParams (same goes 
for calculations). A first thought might be that the type could be 
automatically detected by the placement of the parameter in the SVG 
file, however this can sometimes be ambiguous in properties or 
attributes that accept multiple different types. The CSSWG had the same 
debate for attr() and the consensus was to avoid such "magical" type 
detection for this exact reason (in the current css3-values ED, when no 
type is given in attr(), <string> is assumed, whether it's valid in its 
context or not).

[1]: http://dev.w3.org/csswg/css3-values/#attr

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


On 21/2/12 19:02, Vincent Hardy wrote:
> Hi Lea, all,
>
> I like the idea. If we go this route, then we should have a common 
> solution for custom SVG filters and for shaders. It would be more 
> consistent, I think to have the same syntax for custom filters, no 
> matter how the filter itself is defined.
>
> I like the approach of using an @filter rule, but I am not clear on 
> what the syntax would look like to define, say, three parameters (one 
> number, one point and one array) with their names and defaults.
>
> Cheers,
> Vincent
> From: Lea Verou <leaverou@gmail.com <mailto:leaverou@gmail.com>>
> Date: Mon, 20 Feb 2012 15:00:35 -0800
> To: Dean Jackson <dino@apple.com <mailto:dino@apple.com>>
> Cc: Lea Verou <leaverou@gmail.com <mailto:leaverou@gmail.com>>, Rik 
> Cabanier <cabanier@gmail.com <mailto:cabanier@gmail.com>>, 
> "public-fx@w3.org <mailto:public-fx@w3.org>" <public-fx@w3.org 
> <mailto:public-fx@w3.org>>
> Subject: Re: [filters] Custom filter functions proposal
>
>     On 20/2/12 22:59, Dean Jackson wrote:
>
>         I agree this is a good idea. We had considered proposing this
>         from the start, but figured it would slow the process down (I
>         expect we would spend a lot of time iterating over syntax).
>         It's also a change to parsing in SVG.
>
>         I hope we can get to it soon.
>
>         Dean
>
>     The change in SVG parsing is not tied to this proposal though, it
>     needs
>     to be done anyway for SVG Parameters. SVG Parameters is something
>     badly
>     needed in SVG anyway and I'd love to see development continue for
>     that
>     spec. Authors are currently abusing Webfonts to get behavior that
>     would
>     be much better implemented with SVG Parameters (i.e. utlizing the
>     same
>     vector icon with different colors in different places).
>
>     -- 
>     Lea Verou (http://lea.verou.me | @LeaVerou)
>
>
>
>
>