fix: enhance documentation on view transition names and styling for cross-document transitions

Author: martrapp

src/content/docs/tips/css.mdx

@@ -24,20 +24,26 @@ However, when you start adding more CSS to introduce additional view transition
 ## View Transition Names
 View transition names are tied to the DOM, whether they're set directly on elements or added via CSS rules. You must define the names for the old images on the old page and for the new images on the new page. This does not need to be static. You can use view transition types to add or remove view transition names via CSS, see the [Turn-Signal example](/tools/turn-signal/#switching-transition-names).
 
-The last chance to set these names on the old page using JavaScript is during the `pageswap` event, which occurs right before the screenshots for the old images are taken and navigation leaves the page.
+For cross-document view transitions, the last chance to set these names on the old page using JavaScript is during the `pageswap` event, which occurs right before the screenshots for the old images are taken and navigation leaves the page. 
 
 For the new images, your last opportunity to define names using JavaScript is the `pagereveal` event, triggered after the new page is loaded and just before screenshots of the new images are taken.
 
+For same-document view transitions, capture for old resp. new images happens in the next animation frame right after `startViewTransition()` was called, and right after the update callback resolves. 
+
+The moment the images are captured is also the moment when the `view-transition-group` property for [nested view transition groups](/basics/pseudos/#nested-view-transition-groups) is evaluated. For groups defined in the old state this CSS declaration must be present on the old page. Only groups that are exclusively defined in the new state will honour CSS `view-transition-group` declarations from the new state. 
+
+Things work the other way round for `view-transition-class` declarations: [they are overridden the moment the names are captured](/basics/styling/#class-names-come-mainly-from-the-new-state). Thus class names come from the styling in the new state, unless they names are only present in the old state.
+
 ## Animations
-This might come as a surprise, but it's simple to explain: Besides defining view transition names and taking screenshots of the old images, the old page has no control over how the view transition is styled. Any pseudo-element related CSS defined on the old page will be ignored — unless the old page is also the new one.
+This might come as a surprise, but it's simple to explain: Besides defining view transition names, classes, & groups, and taking snapshots of the old images, in cross-document view transitions, the old page has no control over how the view transition is styled. Any other pseudo-element related CSS defined on the old page will be ignored.
 
 The reason for this is that the animations are triggered by the appearance of the view transition pseudo-elements on the `:root` element of the new page. At that moment, only the styles from the new page are available.
 
-While it makes sense in theory, it still feels a bit counterintuitive that the CSS for an exit animation affecting an element that only exists on the old page has to be defined on the new page.
+While it makes sense in theory, it still feels a bit counter-intuitive that the CSS for an exit animation affecting an element that only exists on the old page has to be defined on the new page.
 
 This might help: Keep in mind that it is not the old element being animated but the _image_ of the old element, which is inserted as a pseudo-element on the new page.
 
-And the new page can be **any page** the user navigates to, including those accessed through a global navigation bar if your site has one. Even without a navigation bar, the user could select a page several entries back in the browser history. That could be just about anything.
+And as far as cross-document view transitions are concerned, the new page can be **any same-origin page** the user navigates to, including those accessed through a global navigation bar if your site has one. Even without a navigation bar, the user could select a page several entries back in the browser history. That could be just about anything.
 
 * So should I put the styles for all exit animations in a site-wide global CSS file? Most likely yes, so they are available on all pages.