W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2015

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

From: Robert O'Callahan <robert@ocallahan.org>
Date: Thu, 8 Jan 2015 15:12:04 +1300
Message-ID: <CAOp6jLY96=1H3L-gqbRd-RHRSr7XUuOO37Xzms6nrMCz_6_B9w@mail.gmail.com>
To: "public-fx@w3.org" <public-fx@w3.org>
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.

I don't know any real-life examples of this problem, but how we resolve it
has architectural implications and possibly Web compatibility implications
down the road, so I'd like to resolve it.

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.
Received on Thursday, 8 January 2015 02:12:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:53 UTC