Re: [csswg-drafts] [css-masking] Proposal: make CSS clip and clip-path respect the containing block hierarcy

> > Composited scrolling with complex clips like this is tricky to 
implement but possible. I'm doing it in bug 1298218 which is currently
 in review and has not landed on Nightly yet.
>
> Yeah, possible but tricky. I assume you're applying the clip 
differently on each frame in the GPU?

Yes. And making sure that we retain enough content to not reveal 
unpainted areas during scrolling.

> > The "no sane implementation" case you listed there is not a 
problem, because elements with filters (e.g. blur) are now containing 
blocks for position: fixed and position: absolute descendants.
>
> Wait, really? Firefox made this change?

Yes, in [bug 
1125767](https://bugzilla.mozilla.org/show_bug.cgi?id=1125767#c5). 

> When did this change to make it a containing block for all 
descendants happen? Chrome does not implement things that way, and I'm
 not aware of a spec that requires this, could you point me at it?

Here's the [action item recorded in February 
2015](https://www.w3.org/2015/02/10-fx-minutes.html#action02). I don't
 know if the spec was actually changed, but Firefox was.

> For opacity, yes you can rearrange things because it "commutes" with
 the clips, due to opacity not moving pixels. This doesn't apply for 
other effects in general though.

But all the effects for which it does not apply create stacking 
contexts for fixed / absolute descendants. Right?

> What I mean is that the complexity of having to deal with 
interleaving clipped and non-clipped paint subsequences. To deal with 
that requires extra clips, or cleverness to do with hoisting up 
opacity in some cases.

Ah. Well, it requires a mechanism that propagates the clip into the 
leaf layers, for example through opacity. It does not require 
splitting up the opacity.

> > In summary, I don't agree with the proposed change. It would take 
away abilities that have valid use cases. It is possible to implement 
the current behavior correctly and efficiently, it's just a bit of 
work.
>
> I agree that those use cases might be harder. I haven't looked 
through all of them, but would they be possible by using 
background-attachment: fixed?

Not if you want arbitrary interactive content in them. You can get 
partway there by using an SVG background-image with e.g. text in it, 
but then that text is not selectable, for example.

> However, I have a larger point of view regarding those examples that
 I haven't mentioned yet: I'm not convinced that those use cases are 
sufficiently common or universal that they justify extra complexity in
 painting and compositing. The tricks here are not general enough to 
implement parallax as far as I can see, for example.

You're right, these tricks are not very general. I still don't think 
that justifies removing these abilities.

-- 
GitHub Notification of comment by mstange
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/495#issuecomment-248206640 
using your GitHub account

Received on Tuesday, 20 September 2016 05:40:43 UTC