W3C home > Mailing lists > Public > www-svg@w3.org > October 2009

Re: Targetting Filter Effects

From: Jonathan Watt <jwatt@jwatt.org>
Date: Wed, 28 Oct 2009 10:30:15 +0100
Message-ID: <4AE80F27.6090700@jwatt.org>
To: robert@ocallahan.org
CC: www-style@w3.org, www-svg <www-svg@w3.org>, David Hyatt <hyatt@apple.com>
On 2009-10-13 3:18 AM, Robert O'Callahan wrote:
> On Tue, Oct 13, 2009 at 1:32 PM, fantasai <fantasai.lists@inkedblade.net
> <mailto:fantasai.lists@inkedblade.net>> wrote:
> 
>     I'm looking at the things coming into www-style, and there's
>     a class of them that are all about filter effects: shadows,
>     opacity, and the like. roc had proposed using the SVG 'filter'
>     property to expand the range of filters beyond shadows and
>     opacity. I think that's a great idea. But the problem we have
>     here is targetting different aspects of the box. We've got
>     requests for targetting:
> 
>      - the entire element, composited
>      - the border layer only
>      - the background layer only
>      - individual background layers
>      - the backdrop only (border + backgrounds)
>      - the composited content of the element minus the backdrop
> 
>     I might even be missing some combinations here. Problem is,
>     that we're going to look at a property explosion if we try
>     to address these separately. Nevermind the overhead, it's
>     going to be a hard-to-control cascading mess if that happens.
>     And the alternative of stuffing them all into one comma-
>     separated property is unweildy for other reasons. (Plus it
>     won't be able to address individual background layers, if we
>     decide to address that.)
> 
>  
> One possible solution is to define SVG filter images that correspond to
> different parts of the rendered element. See the description of 'in' here:
> http://www.w3.org/TR/SVG/filters.html#CommonAttributes
> 
> In our implementation of SVG filters for HTML I made 'SourceAlpha' and
> 'SourceGraphic' refer to the entire element, and that definitely makes
> the most sense IMHO. But we could add 'CSSBorder', 'CSSBackground',
> 'CSSOutline' and 'CSSContent' to refer to the borders, backgrounds,
> outline and "other content" of the element. We could even add
> 'CSSBackground-0', 'CSSBackground-1' etc to access individual background
> layers. It's fairly easy to use feComposite or feMerge to composite
> together multiple filter images. It would also be easy to add new image
> names for common combinations (e.g. 'CSSBorderBackground').

I think that's a good idea, but there's the issue of canned filters - filters
that don't use url() to reference an SVG filter. I think we should probably have
canned filters to make common cases easy for authors, but then if you have no
SVG filter your idea doesn't help those cases. Perhaps a 'filter-input' property
could be added, and in the case of an SVG filter that property could be ignored.
Better yet, we could have another keyword for SVG filters saying to use the
value of that property (SpecifiedInput?). That way SVG filters could be made
more target agnostic, allowing the consumer to selectively applied them to the
part of the element that they want. That would seem desirable, especially for
libraries of filters.

Jonathan

> We would have to define exactly what CSSBackground and CSSBorder means,
> it's not obvious especially for tables with collapsed borders.
> 
> Rob
> -- 
> "He was pierced for our transgressions, he was crushed for our
> iniquities; the punishment that brought us peace was upon him, and by
> his wounds we are healed. We all, like sheep, have gone astray, each of
> us has turned to his own way; and the LORD has laid on him the iniquity
> of us all." [Isaiah 53:5-6]
Received on Wednesday, 28 October 2009 09:30:46 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:43 GMT