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

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.

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

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

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

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

Received on Tuesday, 26 February 2013 00:40:24 UTC