Proposal: make css clip and clip-path respect containing block

TL;DR:

 (a) *css clip would no longer clip fixed-position descendants* (these are
the only descendants that would not respect containing block because css
clip requires absolute position)

 (b) *clip-path would no longer clip descendants for whom the element with
clip-path is not on the containing block*. e.g. fixed or absolute-position
descendants would not be clipped by a clip-path element that is not
positioned or is relatively positioned.

Details:

Compatibility data for Chrome indicates this could be web-compatible. (a)
affects fewer than 0.018%
<https://www.chromestatus.com/metrics/feature/popularity#ClipCssOfPositionedElement>
of pages, and (b) fewer than 0.0069%
<https://www.chromestatus.com/metrics/feature/popularity#ClipPathOfPositionedElement>
(and this is with -webkit-clip-path). Note that the real numbers may be
significantly lower than this, since the counting counts all positioned
descendants, not those whose containing block differs.

In addition, while -webkit-clip-path is still prefixed in some browsers and
not commonly used, we have more opportunity to fix it.

Why:

1. Causes confusion for developers. For example:

 <div id=scroller style="overflow: scroll">
  <div id="clip-path" style="clip-path: ...">
    <div id="descendant" style="position: absolute">
  </div>
</div>

"clip-path" will clip "descendant", and is scrolled by "scrolle".
"descendant" is not scrolled. Thus as a scroll occurs, the "clip-path"
moves relative to "descendant". This is confusing and not really desirable.

2. Causes significant complexity for browsers. Chrome's research shows that
there are many bugs
<https://docs.google.com/document/d/1LFQ0J_c5RGIJ9g5iOOKQJL96uJZRVUMwQkppyXknI2Y/edit>
in the implementation of css clip and clip-path in various special cases
of Chrome's implementation and that of other browsers, especially in paths
that involve compositing. The bugs are directly due to the weirdness of
examples like #1 and even more exotic variants, because implementing it
correctly involves carefully separating out pieces of DOM subtrees that
need individual compositing and scrolling behavior. This also leads to
worse performance due to extra composited layers or tree traversals to
determine correct clipping relationships. In some cases it's not even clear
it's possible to implement "correctly", i.e. the spec is ill-defined.

These bugs and the resulting code complexity are pure overhead that we can
get rid of, since as far as I can see, web developers almost certainly
don't want these exotic cases to behave "according to the current spec".
The proposal in this email doesn't solve everything with containing block,
but is a step in the right direction.

Thanks,
Chris