W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2013

Re: [css-masking][filter-effects] Eliminate default boundaries for <mask> and <filter>

From: Dirk Schulze <dschulze@adobe.com>
Date: Thu, 21 Mar 2013 09:19:55 -0700
To: Stephen White <senorblanco@chromium.org>
CC: "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <A9DBC25E-05F4-4FF6-AB2F-2ADBC1345167@adobe.com>

On Mar 21, 2013, at 9:15 AM, Stephen White <senorblanco@chromium.org> wrote:

>> On Mon, Feb 25, 2013 at 11:45 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>> Hi FX TF,
>> I would like to eliminate the default boundaries for <mask> and <filter> element.
>> Currently both elements use the x, y, width and height attributes to limit the affected area of a filter or a masking operation. Both mean that you will not have visual content of the element outside these areas.
>> If the author does not set these attributes, then they default to -10%, -10%, 120% and 120% of the object bounding box. This is especially unexpected for new users who do not understand why the content gets clipped.
>> An example is a simple drop shadow, where the shadow gets clipped by the filter boundaries. A horizontal / vertical line or 1 dimensional object that can not be masked or filtered properly since the boundaries calculate to zero for one dimension.
>> Of course there are some edge cases that need discussion.
>> * The Filter effects spec has filter effect primitives with infinite dimensional results. The current boundaries are defined by the filter region described with x, y, width and height. Later primitives taking these results must rely on finite dimensioned results.
>> * The origin of a filter or mask on a vertical stroked line is in the middle of the stroke. Which needs attention of web authors or require a special treatment defined by the spec.
>> As a consequence, each filer primitive will need to define the dimension of its result. I would like to add a subsection to each filter primitive defining the resulting dimension. The short hand filters will rely on these dimensions as well. It is also a requirement for future plans of the SVG WG to allow specifying another affection box than object bounding box.
> +1 to this.  I've always thought this 10% margin default was silly.
>> With the above proposal, not setting x or y or width or height means no clipping boundaries on either the left, top, right or bottom site of the operation. Or better: The attributes calculate to the boundaries of the containing results instead of defining the boundaries them selfs.
> Not quite sure what you mean by the last sentence.  Does this mean that, for example, feGaussianBlur and blur() would automatically grow their intermediate buffers to accomodate for 3x stdDeviation in each dimension (or whatever the implementation decides is acceptable margin to prevent visible clipping)?  If so, that sounds good to me.

That is correct. For Filter Effects, the specification will give hints how the implementation can calculate these boundaries. For masking it is up to the implementation to calculate the boundaries (if it needs to). But is is far more easier on masking anyway.

Received on Thursday, 21 March 2013 16:20:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:45 UTC