Re: [csswg-drafts] [css-view-transitions-1] Clarify rendering constraints for elements participating in a transition (#8139)

I really want to keep this simple rule for developers: When you give an element a `view-transition-name`, it, and its descendants, are captured separately as an image.

Given that, I'm not convinced that option 1 breaks developer expectations. Or, if it isn't initially what they expect, a quick look at the `old` and `new` images should make it clear.

Even with forcing a containment block, you can achieve the same effect by counter-transforming the child element (it's how [the demo was made](https://static-misc-3.glitch.me/vt-containment-demos/allow.html)). It looks weird, sure, but it's following the rule of capturing the element as an image, which seems easy to understand.

Option 2 is a smart workaround, but it breaks the simple rule. The rule becomes: When you give an element a `view-transition-name`, it, and its descendants that use a containing block that is not an ancestor of element, are captured separately as an image.

I think that's much harder to understand, and lead to more unexpected behaviour. Also, when developers encounter this unexpected behaviour, I don't think they're going to easily figure out what's happening.

Option 3 maintains the simple rule, but adds an additional rule: `view-transition-name` causes a containing block. Although, this is a rule that also comes with setting transforms, so maybe it isn't a big deal.

Option 4 lefts the restrictions of option 3, but it seems like a new bit of layout to learn.

My preference is option 1. It does what it says, without introducing new rules to learn. If it creates an effect the developer doesn't want, it's easy to figure out and resolve.

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


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

Received on Thursday, 26 January 2023 12:45:54 UTC