Re: CSS Shaders 'filter-margin'

Hi Dirk,

On Oct 31, 2011, at 2:12 PM, Dirk Schulze wrote:

Hi Vincent,


The reason we have filter margins is that for almost all the use cases we had, we found we needed them. The reason for needing margins is that you cannot figure out the proper filter regions for an arbitrary shader. While for several of the Filter Effects filter primitives, there is a way to compute what a good, default filter primitive region should be, that is not so for custom shaders, where it is not possible to predict what the author wants and what the shaders do. So from our experience, I have not seen yet how we could create the content we created without the ability to specify filter margins. This said, issue 5 in the draft captures your concern already.
The default values are 'auto'. How would browsers clip the filter results if the developer doesn't specify these values? To the viewport? To the margin of the element?

See the filter-margin-* properties description:

"Computed value: the percentage as specified or the absolute length. A value of auto computes to 10% of the targetBox"

(just before the section 5 heading).



To answer the specific questions that were raised:

- problems merging the filter-margin properties and the filter element x/y/width/height attribute values. The second sentence of the first paragraph in section 4.1, says that: "If the filter property references a <filter> element, then the filter effect region defined by the element takes precedence over the ‘filter-margin’ property." I think this specifies the precedence rule.

- how are values calculated? I am not sure I understand the question. The values are computed like other CSS values. Can you clarify the concern?

The Filter Effects 1.0 specification defines x, y, width and height [1] as SVGLength units [2]. The 'filter-margin' properties take CSS length values. When you compare both data unit types, you'll see some differences.

I realize there are differences. But I do not understand the problem it introduces in the CSS shaders spec with regards to saying that the filter-margins property define an equivalent filter region (section 4.1). The values are specified and resolve to a resolved/used value. Is your concern about having the user specify a filter-margin with a CSS Length unit that is not available in SVGLength?

Now you have some filter definitions like the following:

<filter x="20" y="20" style="filter-margin: 40vm"/>
In this example the filter-margin property takes 'vm', which is a viewport dependent relative value. It now depends in which viewport you embed the filter element. More interesting is, how the values x, y and filter-margin apply together to calculate the missing width and height of the filter size. How is it possible to determine these information for web developers? Currently this wouldn't be impossible, but still not easy.

The filter-margin property is not meant to apply to filter elements. It is only on filter*ed* elements and provide a shorthand way to specify the filter regions (section 4.1). Is the disconnect here that you are wondering whether or not the values are resolved before the equivalent filter region's x/y/width/height is computed? This is indeed missing: we should explain that the used value for the property (in the CSS 2.1 sense, section 6.1) is used in the formulas the draft proposes. Would that address your concern?

Vincent


Dirk

[1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html#FilterEffectsRegion
[2] http://www.w3.org/TR/2011/REC-SVG11-20110816/types.html#DataTypeLength
[3] http://www.w3.org/TR/css3-values/#lengths


Kind regards,
Vincent

From: Chris Lilley <chris@w3.org<mailto:chris@w3.org>>
Reply-To: Chris Lilley <chris@w3.org<mailto:chris@w3.org>>
Date: Mon, 31 Oct 2011 12:28:24 -0700
To: Dirk Schulze <vbs85@gmx.de<mailto:vbs85@gmx.de>>
Cc: "public-fx@w3.org<mailto:public-fx@w3.org>" <public-fx@w3.org<mailto:public-fx@w3.org>>
Subject: Re: CSS Shaders 'filter-margin'

On Monday, October 31, 2011, 9:08:47 AM, Dirk wrote:

DS> In general I don't think that 'filter-margin' is really needed at
DS> all for shorthand filters. We don't have primitive boundaries
DS> either for them. If someone wants to specify a clipping region for
DS> Filter Effects, he/she should use the XML element <filter> and can't use shorthand filters.

I tend to agree. These are supposed to have sensible defaults.

Also, for a given shorthand, if the defaults are unsuitable, the shorthand can state that this is 'equivalent to' a particular filter with different, specified values for filter-margin.

And as usual, if the author wants complete control, a syntax exists for them to do that. Plus, since its referred to by URI, its easy for authors to share or copy existing examples without necessarily understanding or editing them, as they do now with script libraries or stylesheets.


--
Chris Lilley   Technical Director, Interaction Domain
W3C Graphics Activity Lead, Fonts Activity Lead
Co-Chair, W3C Hypertext CG
Member, CSS, WebFonts, SVG Working Groups




Hi,

The CSS Shader specification introduces the CSS properties filter-margin(-left, -top, -right, -bottom) and tries to describe how they match into the filter regions concept from SVG Filters. SVG and CSS still have different supported unit types for SVGLength and CSS lengths. I see problems in merging both values, if XML attributes and CSS properties are defined together for the <filter> element like 'x' attribute and the 'filter-margin-right' property. How are these values calculated? How the unit types transformed? What if both, 'x' attribute and 'filter-margin-left' are specified? Does the CSS property replace the XML attribute?

In general I don't think that 'filter-margin' is really needed at all for shorthand filters. We don't have primitive boundaries either for them. If someone wants to specify a clipping region for Filter Effects, he/she should use the XML element <filter> and can't use shorthand filters.

Greetings
Dirk