W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2011

Re: Updated filters specification

From: Erik Dahlstrom <ed@opera.com>
Date: Wed, 20 Apr 2011 09:41:32 +0200
To: "Rik Cabanier" <cabanier@gmail.com>
Cc: "Dean Jackson" <dino@apple.com>, public-fx@w3.org, "Anthony Grasso" <anthony.grasso@cisra.canon.com.au>
Message-ID: <op.vt77niz0geuyw5@localhost>
On Tue, 19 Apr 2011 22:58:54 +0200, Rik Cabanier <cabanier@gmail.com>  

> On Tue, Apr 19, 2011 at 1:22 AM, Erik Dahlstrom <ed@opera.com> wrote:
>> On Tue, 19 Apr 2011 06:23:57 +0200, Rik Cabanier <cabanier@gmail.com>
>> wrote:
>>  Hi Dean,
>>> This looks very good!
>>> A couple of questions:
>>> 1. Filter region extensions.

If you reload the spec now you'll find that the margin attributes (the  
filter region extensions) have been removed.

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

I agree.

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

As much as I like having backwards compatibility with SVG 1.1 this is one  
of the things I'm happy to drop from the spec. The reason for that is that  
few implementations support enable-background anyway, and there's very  
little content that depends on it. And as you said, it's possible to find  
workarounds. For example one can use feImage to pull in some subtree as  
the filter input image.

Any objections to dropping 'enable-background' from the filters spec?

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

Anthony, what's your take on that?

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Wednesday, 20 April 2011 07:42:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:38 UTC