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

On Thu, Jan 8, 2015 at 4:29 PM, Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

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

Hmm, I thought this was defined somewhere, but I can't find it now.

I think the "SVG bounding box" of non-SVG elements should be the union of
the CSS border-boxes of all boxes generated by descendant content. This
isn't exactly what Firefox does, but it's close and we can easily fix it.
It should match the "scrollable overflow area" (in Gecko terms) which
browsers already calculate to decide how far to scroll in an overflow:auto
element.

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

I don't really have a preference in this case. It's reasonably easy for us
to do either.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.