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

On Jan 7, 2015, at 6:12 PM, Robert O'Callahan <robert@ocallahan.org> wrote:

> Testcase:
> <!DOCTYPE HTML> 
> <body style="height:3000px">
> <div style="overflow:hidden; width:300px; height:100px;">
>   <div style="filter:blur(10px); -webkit-filter:blur(10px);">
>     <div style="margin:30px; width:200px; height:200px; background:blue;"></div>
>     <div style="position:fixed; left:100px; top:50px; width:200px; height:200px; background:yellow;"></div>
> Making the fixed-pos DIV "position:absolute" shows basically the same problem.
> 
> Currently Gecko and Blink both clip the yellow div to the overflow:hidden element. Technically, per spec, they should not, since an overflow:hidden element should only clip descendants for which it is a containing block ancestor, which it is not in this case.
> 
> However, if we were to try to follow the spec and not clip the yellow div, it's totally unclear what should actually be rendered in this case:
> a) It seems pretty clear that the blur of the blue div should be clipped.
> b) It seems pretty clear that the blur of the yellow div should not be clipped.
> c) But there are pixels in the blurred image that would receive contributions from both the blue and yellow divs.
> 
> A similar issue would arise if we used a filter that draws black in the border-box of the filtered element. Which area, if any, outside the overflow:hidden element would be drawn black?
> 
> I see two plausible options:
> 1) Specify that 'filter' is a containing block for all positioned descendants (like 'transform' already is).
> 2) Specify that 'filter' only filters descendants that have the filtered element as a containing block ancestor.
> I prefer #1. Anyone got any better suggestions?
> 
> This issue does not arise for 'opacity' or any other effect where rendering is inherently restricted to the clipped bounds of the effect's descendants.

But Firefox and WebKit do clip the blue and yellow boxes if you replace the filter with opacity. Chrome does not.

Simon

Received on Tuesday, 13 January 2015 04:21:50 UTC