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

Thanks for the reply Dirk. Very clarifying. A few minor notes inline.

On Tue, Feb 26, 2013 at 1:39 AM, Dirk Schulze <dschulze@adobe.com> wrote:

> Hi Michael,
>
> Thank you very much for your input. See inline comments.
>
> On Feb 25, 2013, at 2:32 PM, Michael Mullany <michael@sencha.com> wrote:
>
> >> 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"
>
> These seem to be different problems that you address here. One is pointer
> events that are not affected by filters. The second is transforming the
> image or element (referenced by feImage) to the userspace of the filtered
> element. And the third is the portion of the referenced element and image
> that you take for following filter primitives. The last issue is a problem
> with all image generators: pseudo filter primitives (e.g. SourceGraphic),
> feImage, feFlood, feTurbulence, feTile. I want to address these as well and
> make sure that they are still compatible with the current behavior of
> browsers.
>

The first problem was the one I wanted to highlight, but on consideration,
if the default behavior for various primitives is specified in a helpful
way, then it won't be an issue.


>
> Btw. the dimension of lightning filters may need more discussion since the
> implementations differ here anyway.
>

Webkit doesn't conform to the spec - it treats all dimensions as user space
units relative to the origin of the objectBoundingBox. I've previously
filed chromium bugs in Chromium against this behavior. Firefox, Opera (and
I believe IE10) all conform to spec.

>
> >
> > 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?
>
> This doesn't make the situation better. The local coordinates depend on
> the transformation of the filtered element and it's ancestors as well as
> the viewBox used on the viewport. 10 in userspace could be extremely huge
> or extremely small. It is less predictable than percentage values IMO.


> >>
> >> 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
>
> I assume that your "border region" is similar to border box on CSS boxing
> model. It was indeed discussed to allow users to differentiate between
> different bounding boxes and do not just use object bounding box. However,
> this is a different discussion and not in the scope of the first revisions
> of Filter Effects and Masking. But we can see it as a solution for the
> future. Defaulting to a "border region" is not possible to keep backward
> compatibility with existing content.
>

Sounds good.

>
> >
> >> 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).
>
> Most values are unit less at this time but depend on the attribute
> setting: primitiveUnits=" objectBoundingBox | userSpaceOnUse " in which
> case they are dependent to the user space of to the object bounding box.
>

SVG 1.1 only allows a single value for primitiveUnits within a filter -
which means if you want a filter that puts a lightsource in the middle of
your filtered content and then adds a 3 pixel frame, you have to get your
calculator out and convert 3 pixels to an appropriate % of
objectBoundingBox. (I've been reproducing Instagram filters with SVG and
have run into a few of these limitations).

>
> >> 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?
>
> I would not call it a problem. But it is likely the case that
> modifications on a previous filter chain require recalculations on a later
> filter chain. This is likely the case anyway, since the input graphics
> changes.
>
> >
> >> 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.)
>
> It is up to you to use results and ins all the time if you feel that this
> is more helpful for authors. It is not possible to enforce it at this point
> since this would require to break compatibility to SVG 1.1 content.
>
> Greetings,
> Dirk
>
>
>