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

[chrishtr]

TL;DR: the proposal is to make all types of clip apply to the same set of children that overflow clip does.

This document summarizes the proposal: https://docs.google.com/document/d/1ZBYyuCZVdv86WoGoYxGC6OxsV3FwuW71vlXGyQ2EzyM/edit#

[mstange]

I'm replying to your email and to the two documents.

On reflection, I think I overstated the performance impact. I think the main benefit in terms of performance is improved composited scrolling

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.

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. In fact, I'm pretty sure we made that change to filters because of the undefined clipping.

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.)

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).

Here are three examples of pages that rely on current behavior of clipping not agreeing with scrolling (courtesy of mstange@themasta.com):

http://www.flagofplanetearth.com/
http://www.bbc.co.uk/news/resources/idt-248d9ac7-9784-4769-936a-8d3b435857a8
http://dok.sonntagszeitung.ch/2016/ubsinnovation/

Here are three more:

• https://facebook.github.io/immutable-js/
• http://graphql.org/
• http://jsbin.com/hazufowovo/edit?html,css,output (jsbin seems to be down for me at the moment, but I'm pretty sure this is the right link - it should be a scroll frame with cats and a pure CSS pagination indicator at the bottom. I found it on Twitter a few months ago but didn't bookmark the tweet itself unfortunately, and I can't find the original tweet now.)

I'm pretty sure the first two were made by the same person.

There was also this post about use cases for fixed backgrounds in CSS on CSS-Tricks recently. Most of the examples there are just fixed images, so background-attachment: fixed is enough for those. But the last example uses text, so it requires position: fixed + clip.

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.

[mstange]

• http://jsbin.com/hazufowovo/edit?html,css,output (jsbin seems to be down for me at the moment, but I'm pretty sure this is the right link - it should be a scroll frame with cats and a pure CSS pagination indicator at the bottom. I found it on Twitter a few months ago but didn't bookmark the tweet itself unfortunately, and I can't find the original tweet now.)

Found it!

[dbaron]

Does this make clip and clip-path more or less consistent with mask, opacity, blend-mode, etc.?

[chrishtr]

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

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.

[chrishtr]

Does this make clip and clip-path more or less consistent with mask, opacity, blend-mode, etc.?

Less consistent. I think it would be ideal to make the same change for all of them, but I'm concerned about web compatibility, which led me to this proposal as a compromise.

[mstange]

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.

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. 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 containing blocks 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.

[dbaron]

Note that this issue actually belongs in the fxtf-drafts repository.

[mstange]

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. I don't know if the spec was actually changed, but Firefox was.

The spec issue about this is w3c/fxtf-drafts#11.

[fantasai]

This issue was moved to w3c/fxtf-drafts#131