Re: [filter-effects] Filter primitive subregions and input clipping

Sorry, my bad: I had already modified the fiddle locally to remove the
feOffset which simulates input clipped to FPS.

Here's a forked version which shows the difference (feOffset removed):

(Grey feathered border in Safari, Chrome; red feathered border in Firefox.)


On Mon, Nov 3, 2014 at 6:57 PM, Stephen White <>

> I think Chrome and WebKit do clip the input to the filter primitive
> subregion. See my fiddle above: in Chrome and Safari, there's a soft grey
> edge, indicating that none of the red region has been blended in. In
> Firefox, the edge contains red, which indicates to me it's not clipping the
> input to FPS.
> I'm happy to remove the input clipping if the spec wording does change,
> though.
> Stephen
> On Mon, Nov 3, 2014 at 6:31 PM, Max Vujovic <> wrote:
>> Hi folks,
>> I’m wondering why the spec says that filter primitive subregions clip
>> their input.
>> Implementations don’t do it, and I’m struggling to find a benefit of it.
>> IMO, we should remove this requirement.
>> I agree with Stephen White’s statement last time this was discussed [1]:
>> "I suppose you could make the argument that if you had only output
>> clipping, you could always achieve input-and-output clipping by inserting a
>> no-op node (e.g., FEOffset) with the filter primitive subregion set to the
>> same values as the child node, e.g.
>> Whereas if you have input-and-input clipping, there's no easy way to
>> achieve output clipping only."
>> According to my tests (posted on a related spec bug [2]):
>> - Safari, Firefox, and Chrome do not clip the input to a filter primitive
>> to its primitive subregion. IE11 was inconclusive; I think I ran into a
>> different bug.
>> - Safari, Firefox, IE11, and Chrome all clip the input to a filter to its
>> filter region.
>> Thoughts?
>> Thanks!
>> Max
>> [1]:
>> [2]:

Received on Tuesday, 4 November 2014 00:02:02 UTC