W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2016

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

From: Markus Stange via GitHub <sysbot+gh@w3.org>
Date: Sun, 18 Sep 2016 23:05:24 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-247887348-1474239921-sysbot+gh@w3.org>
I'm replying to [your 
 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 

Composited scrolling with complex clips like this is tricky to 
implement but possible. I'm doing it in [bug 
1298218](https://bugzilla.mozilla.org/show_bug.cgi?id=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 
> There are some examples in [this 
 (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
> ```html
> <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 

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 
> http://www.flagofplanetearth.com/
> 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](https://css-tricks.com/use-cases-fixed-backgrounds-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.

GitHub Notification of comment by mstange
Please view or discuss this issue at 
using your GitHub account
Received on Sunday, 18 September 2016 23:05:31 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:03 UTC