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

On Mon, Feb 25, 2013 at 5:45 PM, 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.
>

+1 on the weirdness of the -10%, -10% etc. defaults. I answer the
svg-filters tag on stackoverflow and clipped results are a common question
(as are lighting effects that overflow the source graphic) However,
eliminating a reasonable default could cause another problem - which is
that the visual results will become disconnected from the underlying object
bounding box, and this could cause just as many problems. Sample question I
foresee:

Q: "Why is part of my graphic not clickable"
A: "Because you imported an image with feImage that was much larger than
the obejctboundingbox, and although the filter effects region result was
enlarged as a result, the objectboundingbox was not"

Have you considered moving to a possibly more useful default like -10, -10,
+10, +10 - where the default is specified as a border region in
userspaceunits?

>
> 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.
>

Moving to a border region default would solve this second problem

>
> 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.
>

If you end up doing this, could you also consider allowing mixed units
within a filter. Some primitives like blur lend themselves to user space
units, some (specifically lightsources) lend themselves to object bounding
box (I want the light source in the middle).

>
> 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.


Could this cause problems with dependencies between two filter chains when
they are combined? If one filter chain results in an enlarged effects
region, would another filter chain then have to recalculate itself based on
the enlarged region before combination?

>
> Greetings,
> Dirk
>

(As as side note, not requiring explicit "ins" and "results" in filters
causes as many problems as this. People lose track of what primitive is
feeding what quite commonly.)