Re: Overflow-clipping of filters with fixed-pos/abs-pos descendants

Some related issues that should probably clarified at the same time:

A) Calculating filter effects region

When applying SVG filters to HTML content should the filter effects region
be calculated based on the official bounds of the element with the filter
property, or based on a bounding box for all child content?

Test case: http://fiddle.jshell.net/r8cya98f/

Currently Chrome and Firefox both create a bounding box for the combined
parent and child content.  (The yellow div isn't clipped, despite the fact
it extends more than 25% outside the bounds of the parent.)  I'm pretty
sure that this is a change in behavior for Firefox compared to earlier
implementations; I remember having problems with just this issue last year.

The filter effects spec doesn't currently define bounding box for non-SVG
content.  However, the masking spec uses it to mean border-box.  The
masking spec, however, is currently rather problematic when it comes to
applying SVG masks to HTML content, particularly in how it has re-written
the definition of objectBoundingBox units so that 1 user coordinate=1 CSS
px instead of 1 user coordinate=100%.
http://www.w3.org/TR/css3-transforms/#bounding-box
http://www.w3.org/TR/css-masking/#valuedef-objectboundingbox0

B) Overflow order of operations

Browsers are currently not consistent about whether `overflow:hidden`
should cause clipping before or after applying a filter if they are both
applied to the same element.

For SVG content, see this test case:  http://fiddle.jshell.net/qjfgwz0t/

Four nested <svg> elements, each containing a single rectangle.  The stroke
of the rectangle extends outside the bounds of the nested SVG region.  All
have a blur filter applied.  Left column has overflow: hidden on the nested
SVG, right column visible. Top row has the filter applied to the SVG
itself, bottom row has it applied to the child rectangle.

Results in browsers I tested:
Firefox and IE clip the content first, apply the filter second (second row
doesn't match the first -- the stroke has been clipped, but not the blur).
Chrome clips the overflow after applying the filter.

The SVG 1.1 rendering instructions do not specifically discuss `overflow:
hidden`, but in general they require filters to be applied *before*
clipping and masking.
http://www.w3.org/TR/SVG11/render.html#RenderingOrder

For HTML content, the results are much the same.

Test case, based on  Rob O'Callahan's test (I just removed one level of
nesting so that filter and overflow are set on the same div):
http://fiddle.jshell.net/mkud1Lnm/2/

Chrome blurs, then clips; Firefox clips, then blurs.  It doesn't change the
fact that the fixed position element is getting clipped to the parent
overflow region.
__________________

Finally, for those of you who like one-click to JSFiddle test cases, here
is Rob O'Callahan's original test for fixed positioning and overflow:
hidden  (Note, in this case the parent with hidden overflow is not the same
element as the one with the filter applied):

http://fiddle.jshell.net/mkud1Lnm/1/

I've added an SVG filter fallback since I don't have the latest developer
builds of Firefox that support the CSS filter functions.

Best,
Amelia BR

Received on Thursday, 8 January 2015 03:30:10 UTC