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

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.

Stephen

>
> Greetings,
> Dirk
>