search

WICG / layout-instability

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

Fix computed value computation #96

Closed npm1 closed 3 years ago

npm1 commented 3 years ago

When determining whether the node can be considered unstable, we need to consider not just the node but also its ancestors, since computed value does not account for inheritance. Fixes https://github.com/WICG/layout-instability/issues/61

Preview | Diff

skobes-chromium commented 3 years ago

It looks like visibility is inherited, and can be overridden. Should we do this for opacity only?

https://output.jsbin.com/cevoned/quiet

npm1 commented 3 years ago

Ahh interesting, done.

dholbert commented 3 years ago

The new spec text looks good -- but let me correct the motivation/reasoning a bit. The commit message said:

[..] since computed value does not account for inheritance.

In fact, the computed value does account for inheritance; and the scenario that we're addressing here doesn't have to do with opacity inheriting or not-inheriting.

The reason that we have to check ancestors (for opacity) is that opacity simply has its effect by changing the painting of the element's whole subtree (by e.g. creating a GPU layer for the element, and then configuring the opacity of that layer on the GPU). So this is why opacity:0 on any ancestor-box will trivially mean that we can be sure that our own box is guaranteed not to paint, regardless of our own box's opacity value.