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