[filters-1] filter region and filter primitive subregion should be defined better for CSS filter functions

[dbaron]

The filters spec defines new CSS filter functions that do the same thing as some of the SVG filters.

However, I don't see where it defines when (if at all) these filters should be clipped to a rectangle, as is defined much more clearly for SVG filters in the definitions of the filter region and the filter primitive subregion.

This is probably most relevant for the filters where pixels in the input can affect different pixels in the output, i.e., blur() and drop-shadow().

The spec should be clear when (if at all) effects are clipped to a rectangle (e.g., between filter functions, between a CSS filter function and an SVG filter referenced by url(), etc.) and to what rectangle they're clipped.

(I got here, somewhat indirectly, from w3ctag/design-reviews#116 .)

[AmeliaBR]

Section 12.2 states:

All shorthand filters implemented with filter primitives in the previous subsection must have a UA defined filter region. The filter region must cover the visual content of an element including overflowing content, graphical control elements such as scrollbars, border/border-image, box-shadow, text-shadow and outline. Furthermore, if a shorthand filter expands this visible area like it is the case for blur() or drop-shadow() the filter region must cover this area as well.

See also #2, a feature request to have this same sort of automatic filter region available for <filter> and <fe*> elements.

[dirkschulze]

@dbaron The spec does not state how to compute this area but it does say:

Furthermore, if a shorthand filter expands this visible area like it is the case for <blur()> or <drop-shadow()> the filter region must cover this area as well.

https://drafts.fxtf.org/filters/#filter-region-for-shorthands

[dirkschulze]

@dbaron Do you think it is necessary to describe the details of how to compute the auto filter region? We deferred the computation in previous WG resolutions (See issue #2 ) and implementations can have their freedom how to implement the region as long as the visual requirements are matched.

[AmeliaBR]

It might be useful to add a note in the "Filter primitive representation" section for blur() and drop-shadow(), pointing down to the "Filter region for shorthands" section. The SVG equivalents as given are not fully accurate for those shorthands, since there is currently no way to represent this automatic calculation in the longhand notation.

But beyond that, I'm fine with keeping this in prose for now. The exact calculation would depend on how far you extend the blur effect (it is theoretically infinite, like a Gaussian curve, but is clamped at a reasonable distance). The definition of <feGaussianBlur> gives some recommendations, but does not require a specific algorithm or degree of precision. I assume most implementations clamp the effect to max 3 standard deviations, some might clamp it to 2 standard deviations (aka 1 "blur radius").