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

On Tue, Jan 13, 2015 at 7:10 PM, Simon Fraser <smfr@me.com> wrote:

> On Jan 12, 2015, at 9:40 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
> On Tue, Jan 13, 2015 at 5:21 PM, Simon Fraser <smfr@me.com> wrote:
>
>> But Firefox and WebKit do clip the blue and yellow boxes if you replace
>> the filter with opacity. Chrome does not.
>>
>
> The Web compat constraints around 'opacity' are probably a lot tighter
> than around 'filter', since the former has been around a lot longer. So it
> might make sense to treat them differently. In particular, I'd be quite
> afraid to implement option #1 or option #2 for opacity.
>
>
> Agreed; both options would have serious compat risk, but it would be a
> shame to have different behaviors for two properties (opacity and filters)
> that are essentially the same.
>
> What is the nature of the fix you made in Firefox? How, conceptually, can
> you render a group of two translucent elements with different clips, other
> than by building a complex clip region?
>

Conceptually, we avoid clipping the translucency group, and instead push
all clipping down to its descendants, which allows us to apply different
clips to different descendants.

We can't take the same approach for 'filter', for the reasons described at
the beginning of this thread. Although 'filter' and 'opacity' are
"essentially the same" in some sense, 'opacity' is an important special
case because the above approach works.

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.