- From: Dirk Schulze <vbs85@gmx.de>
- Date: Mon, 31 Oct 2011 22:12:37 +0100
- To: Vincent Hardy <vhardy@adobe.com>
- Cc: Chris Lilley <chris@w3.org>, "public-fx@w3.org" <public-fx@w3.org>
- Message-Id: <B555B660-2846-415E-BFE2-49ECDA09675A@gmx.de>
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? > > 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. 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. 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> > Reply-To: Chris Lilley <chris@w3.org> > Date: Mon, 31 Oct 2011 12:28:24 -0700 > To: Dirk Schulze <vbs85@gmx.de> > Cc: "public-fx@w3.org" <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 >
Received on Monday, 31 October 2011 21:13:10 UTC