Re: [csswg-drafts] [css-view-transitions-1] Capturing fragmented elements (#8339)

Summary for CSSWG:

When an element is captured as part of a view transition, we ignore all ancestor & element transforms when capturing the image, and apply a transform to the group that positions the element in the correct place in relation to the snapshot viewport. So, if the difference between the old & new view is that the element has been rotated 90 degrees, by itself or a parent, you'll get a rotating transition, rather than just a cross-fade.

Elements can become fragmented, eg across columns. When transforms are applied to fragmented elements, the transform is applied to each fragment individually. This isn't compatible with the view transition model that wants to capture the element as a single image + a single transform.

It's unclear whether view transitions are desirable on elements that fragment. Particularly if the amount of fragmentation is different between the old and new views. Eg, going from fragmented across 2 columns, to fragmented across 3.

Prior art: [The `element()` spec](https://w3c.github.io/csswg-drafts/css-images-4/#element-notation:~:text=If%20the%20referenced%20element%20has%20a%20transform%20applied%20to%20it%20or%20an%20ancestor%2C%20the%20transform%20must%20be%20ignored%20when%20rendering%20the%20element%20as%20an%20image.) says:

> If the referenced element is broken across pages, the element is displayed as if the page content areas were joined flush in the pagination direction, with pages' edges corresponding to the initial containing block’s start edge aligned. Elements broken across lines or columns are just rendered with their [decorated bounding box](https://w3c.github.io/csswg-drafts/css-images-4/#decorated-bounding-box).

I'm not 100% what that means. Firefox's implementation seems to capture the union of all fragment rects before transforms are applied, but captures the pixels with transforms applied ([demo](https://jsbin.com/pozumog/edit?html,css,output)).

## Option 1: Fragmentation breaks view transition constraints

Because it's complicated, and seemingly not desirable, make no-fragmentation a constraint.

When constraints are broken, transitions skip to the end ([previous resolution](https://github.com/w3c/csswg-drafts/issues/7882)).

**Sub-option**: Is the constraint broken if an element fragments, or if an element can fragment?

[Previous resolution](https://github.com/w3c/csswg-drafts/issues/8139): A `view-transition-name` value that isn't `none` gives an element stacking context, grouping element, backdrop root, similar to non-1 `opacity`, as view transitions need these constraints.

**Sub-option**: Should a non-none `view-transition-name` prevent an element being fragmented? This would be in line with a previous resolution.

## Option 2: The view transition only applies to the first fragment

This doesn't seem useful, but it's not-failing. It's also an easily-definable rule. You could argue that how transforms apply to fragments is similarly not-useful, but also not-failing.

## Option 3: Capture union of fragments with transforms baked-in

This is taking inspiration from what Firefox does with `element()`, which may not be in line with the spec.

We capture the transform for the transition group, for fragmented elements, by:

1. Remove any transform from the element.
2. The quad is a union of fragment quads.
3. Figure out the transform needed to place the quad in the snapshot root, equivalent to its current position.
4. Reapply the element's transform.
5. Capture the image. Anything overflowing the quad is ink overflow.

Again, it isn't clear if this is useful, but it's not-failing. It's much more complex than option 2, but involves all fragments.

-- 
GitHub Notification of comment by jakearchibald
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8339#issuecomment-1469891499 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 15 March 2023 12:09:46 UTC