ignoring transforms (spec issue)

[skobes-chromium]

Chrome's current implementation of layout stability generally ignores transform changes, which we think is desirable, because

• changing an element's transform doesn't affect layout of surrounding content, and
• sites that incorporate transform animations would otherwise be overly penalized.

However the spec as written doesn't technically permit this: its definition of "starting point" incorporates offsets from transformed ancestors, so the algorithm "identify an unstable element" will return true for a transform-changing container as well as its descendants.

Fixing the spec to match the implementation seems a bit tricky. For example, we still want to consider transforms in computing viewport intersection for the impact region. And, we don't want to ignore a real layout shift just because it may have a transformed ancestor.

It seems to me that we want the following properties:
(a) If an element's transform changes, but it would not otherwise be an unstable element, then it is not an unstable element
(b) If an element's nearest transformed ancestor is not an unstable element after applying (a), and its transform-relative starting point has not changed, then it is not an unstable element
(c) Otherwise, run the current algorithm

This introduces a new concept, "transform-relative starting point", which would be the flow-relative offset in the coordinate space of the nearest transformed ancestor.

@npm1 points out that "would not otherwise be an unstable element" in (a) is hard to reason about. I'm trying to find a good way to express this. Maybe we need some concept of position-without-transform just for (a).

Would like to hear others' thoughts, especially @tabatkins

[npm1]

If there are no suggestions on this, then let's add something that attempts to capture the intent and then improve it once we come up with a better way to express this.

[skobes-chromium]

#22