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

I'm replying to [your 
email](https://lists.w3.org/Archives/Public/www-style/2016Sep/0062.html)
 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](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 
examples?
> 
> There are some examples in [this 
document](https://docs.google.com/document/d/1LFQ0J_c5RGIJ9g5iOOKQJL96uJZRVUMwQkppyXknI2Y/edit)
 (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 
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](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 
https://github.com/w3c/csswg-drafts/issues/495#issuecomment-247887348 
using your GitHub account

Received on Sunday, 18 September 2016 23:05:31 UTC