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?

> 
> I'm curious about the cases you mentioned which are not possible to 
implement correctly, or which are underdefined. Do you have examples?
> There are some examples in this document (which I also linked to the
 proposal).
> 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?

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? Chrome 
currently only allows SVG foreign object, transform, and iframe-root 
to be containers for position: fixed.

> 
> Thus in a situation like
> 
> <div id=clip style=”clip-path: …”>
>   <div style=”opacity: 0.5”>
>     <div id=regular style=”position: relative”></div>
>     <div id=notclipped style=”position: absolute”></div>
>   </div>
> </div>
> the opacity cannot be applied in a single operation if the children 
overlap, and instead must be broken up into one opacity for each 
contiguous group of descendants for which the clip does or does not 
apply.
> After thinking about this again, I don't think that's true. You just
 need to reorder the effects in such a way that the clips are applied 
in the leaf nodes, and the opacity operation happens after the clips 
have been applied. (However, if you're able to do that, you might as 
well clip everything.)

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.

> 
> Note that this complexity is already present for CSS clip.
> I don't think so. Is it? In Firefox, I'm pretty sure opacity will 
always be just one opacity operation, except in cases with 3d 
transforms and preserve-3d (unless this was changed recently).

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.

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

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.


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

Received on Monday, 19 September 2016 16:57:09 UTC