Right now, if an element is to be captured for a view transition, we require the developer to set either layout or paint containment. There's no longer a technical reason for this, but it may still catch some unexpected behaviour.

For example, take this sidebar.

.sidebar {
  view-transition-name: sidebar;
  position: absolute;
  inset: 0 auto 0 0;
}

Imagine, due to some hacky layout, a logo overlay was within the sidebar:

.sidebar > .logo {
  position: fixed;
  right: 0;
  top: 0;
}

In CSS terms, the sidebar and the logo are independently positioned, since the logos containing block is some ancestor of the sidebar.

However, with view transitions, if we create a transition where the sidebar moves horizontally, we'll also be moving the logo, since it's part of the same capture. If the sidebar transitions to left by 100px, the old view of the logo (as part of the sidebar view) will slide to the left by 100px and fade out, and the new view of the logo will slide in from the right by 100px and fade in.

contain: layout ensures children of the sidebar will not use a parent as a containing block. It won't 'fix' the issue above, but it will make it obvious that it won't work, before the transition starts.

My thoughts on this:

• Helping developers identify issues early is good. But how common is the above gotcha?
• Even as someone involved in the spec, I frequently forget to add contain: paint and my transition fails. I then roll my eyes & add contain: paint. This might be a net negative on developer experience.
• Adding contain: paint has never saved me from the gotcha above, but my demos have been simple, so they're unlikely to have weird layouts like above.
• Removing the contain: paint requirement is a backwards compatible change, so we can do it later.