W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2011

Re: CSS Shaders 'filter-margin'

From: Vincent Hardy <vhardy@adobe.com>
Date: Mon, 31 Oct 2011 12:51:22 -0700
To: Chris Lilley <chris@w3.org>, Dirk Schulze <vbs85@gmx.de>
CC: "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <CAD4481F.1EEB6%vhardy@adobe.com>
Hi Drik, Chris,

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.

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?

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
Received on Monday, 31 October 2011 19:54:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 31 October 2011 19:54:25 GMT