WICG / layout-instability

A proposal for a Layout Instability specification
https://wicg.github.io/layout-instability/
Other
158 stars 26 forks source link

Specify expected behavior for overflows and containment #60

Open wangxianzhu opened 4 years ago

wangxianzhu commented 4 years ago

The current spec seems to imply that overflowing contents should report their own shifts, but this requires that the browser to traverse the subtree whose root is shifted.

We could define how we should detect and report shifts for ancestors and descendants. For example, can we define that we don't need to report descendants' shifts if they don't shift in the ancestor? If yes, can we define that the ancestor should also report its overflow in its shift, to avoid tree walk into the subtree if possible?

This is particular important when we deal with css contain. We don't want to traverse the subtree of css contain in particular cases.

skobes-chromium commented 4 years ago

Generally speaking, if a descendant is visible, it will be fully enclosed by its ancestor. Therefore, if ancestor and descendant shift together, there is no additional contribution to the impact region from the descendant.

Did you mean something different? Perhaps you could share a test case?

wangxianzhu commented 4 years ago

I found I misunderstood the "box" concept. The "principle box" is defined as to contain its descendant boxes and generated content. Then the spec is precise about ancestors and descendants.

wangxianzhu commented 4 years ago

Note that currently Chromium doesn't conform to the spec about visible overflows from descendants.

wangxianzhu commented 3 years ago

I'm reopening this issue because there is still things to be clarified.

<div style="width: 1000px; height: 10px">
  <div stye="width: 10px; height: 1000px"></div>
</div>

When the parent moves, currently Chrome reports 1000x1000 area is moved, but the real covered area is 1000x10 + 10x990. For implementation, the former is more performance and complexity friendly.