Targetting Filter Effects

[fantasai]

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

I don't have any solutions. I just wanted to point out that we
should look at all these together. It's part of the reason why
I wanted to pull back box-shadow from the css3-background LC:
it's a much bigger problem we're looking at here.

CCing www-svg, please follow-up to www-style.

~fantasai

[Robert O'Callahan-3]

On Tue, Oct 13, 2009 at 1:32 PM, fantasai <fantasai.lists@...> 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').

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]

[Jonathan Watt-3]

On 2009-10-13 3:18 AM, Robert O'Callahan wrote:

> On Tue, Oct 13, 2009 at 1:32 PM, fantasai <fantasai.lists@...
> <mailto:fantasai.lists@...>> 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]

[Robert O'Callahan-3]

On Wed, Oct 28, 2009 at 10:30 PM, Jonathan Watt <jwatt@...> wrote:

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.

 

We should add support for passing parameters to filters from the CSS 'filter' property (see thread on www-style), then input image names could be passed as parameters.

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]