Re: Updated filters specification

Hi Dean,
>>>
>>> This looks very good!
>>>
>>> A couple of questions:
>>> 1. Filter region extensions.
>>> Why do you need to specify this? I can see that this is necessary for
>>> certain types of filters, but for the most common ones, the browser can
>>> just
>>> calculate if for you.
>>> Could this be optional? It will for sure make author's life easier...
>>>
>>
>> Yeah, that's been discussed before, and they're going away, I have an
>> action to remove that (it's basically leftovers from an old SVG 1.2 Full
>> draft).
>>
>>
>>  2. Accessing the background image
>>> Would there ever be a reason to do this? This seems like a very expensive
>>> operation that could be worked around by rearranging the content.
>>>
>>
>> You're right that it can be expensive to generate. I think in some (rare?)
>> scenarios it is necessary to have something like enable-background.
>
>
> A user could put the background content in with the content that has the
> filter applied to it.
> In addition to that, he would also have to draw a white box to make sure
> that the actual background doesn't peek through where there's alpha.
>
> This feature could be especially hard to implement in a world where things
> are accelerated in the GPU
>
>
> It's also worth noting that you could implement the shorthand effects
> without having a full 'filter'/SVG engine. The shorthands don't need
> enable-background.
>
> (We need a term for the previously-SVG part of the Filters spec.
> "Shorthands" works ok for the new part. I was going to say "XML" for the
> other part, but it isn't strictly XML any more. "Markup" doesn't work so
> well since everything is markup - same with "declarative").
>

I noticed that drop-shadow is not defined as a built-in filter. Is there a
reason for this? Is it possible to add a parameter to add an inner shadow? I
believe that this construct will solve many issues that people currently
have with the box-shadow feature.
Another possible filter is 'bevel'. It's calculated in a similar way so
should be easy to add.

Thanks!
   Rik



> There is also the SVG 1.1 backwards compatibility aspect to consider.
>
>
> Do we care about this if we move to CSS? SVG1.1 was not designed for this.
>
>
>>
>> I think that the optional <x>,<y>,<width>,<height> values in
>> 'enable-background' should be deprecated, because they are useless in
>> practice. We should let the UA compute the necessary background buffer
>> region, and just ignore these values if specified.
>
>
> I agree. We can discuss that in the context of the SVG compositing spec.
> Maybe there are workflows were this makes sense.
>
> Rik
>
>
>