Re: [filters] Custom filter functions proposal

Hi Lea,

On Feb 21, 2012, at 12:57 PM, Lea Verou wrote:

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.

[vh] Yes. But for CSS shaders, we do have arrays, see the <param> description at:

https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html#feCustom

so it would be good to have a solution to pass arrays into shaders. But we can deal with that later I think.

If I try to convert one of the existing CSS shaders example:

filter: custom(url('wave.vs') url('old-paper.fs'), 20 20, phase 0, amplitude 50);

we could have something like:

@filter old-wave {
src: shader(url('wave.vs') url(old-paper.fs));
mesh: 20 20;
parameters: phase, amplitude;
default: 0 0;
}

So one thing I would note for shaders is that we would need a property for the mesh in the @filter rule (the syntax is described at:

https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html#vertexMesh-attribute

On a different topic, the example you provided uses:

    parameters: x, y, z;
    default: 0 1pt black; /* this means that filter: foo(); is equivalent to filter: foo(0 1pt black); */

I find it a little disconcerting to use comas between the parameters but not between the defaults, so I would prefer both to be the same, as in:

parameters: phase, amplitude;
default: 0, 0;

or

parameters: phase amplitude;
default: 0 0;

So I am ok with what you propose and how it could work with shaders. I have concerns about trying to use the same @rule for alternate filters, but I'll respond to the other message on that topic.

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.

[vh] I do not have a strong feeling about commas vs. whitespaces, but I'd like 'default' and 'parameters' to be consistent and since they were not in the example, I'd like to make sure we agree they should.

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.


[vh] For using the filters, I actually prefer naming the parameters as in the CSS shaders proposal than having anonymous arguments, especially for custom filters. So I would prefer to have to write:

filter: old-wave(phase 90, amplitude 10);

than:

filter: old-wave(90, 10);

I realize this is different than the predefined filters notation but I think code would be more legible this way, easier to maintain and less error prone.

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

[vh] In the CSS shader spec, the types are not provided but inferred from the values:

true|false[wsp+true|false]{0-3} |
<number>[wsp+<number>]{0-3} |
<array> |
<transform> |
<texture(<uri>)>

However, I like the idea of providing the type. This was not needed for the implementation of CSS shaders, but it may make things easier and also help with the CSS OM down the line to get these custom parameters with the proper type.

I like your proposal of:

parameters: <parameter-name> <parameter-type>[, <parameter-name> <parameter-type>]*

Kind regards,
Vincent


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


Lea Verou (http://lea.verou.me<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<http://lea.verou.me/> | @LeaVerou)