- From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 May 2023 05:38:45 +0000
- To: public-css-archive@w3.org
> In general, I like this at-rule approach. > > A few remarks/questions: > > 1. What is the lifetime when these at-rules apply? In internal conversations I heard that the incoming one would only be alive at the very first frame _(to actually opt in + optionally set up different transition names)_ and outgoing one only at the very last frame of the page. Outgoing - I think it should be when a same-origin navigation fetch is initiated, but it can also be the last frame. Either would work, the first one is a bit easier to understand, and perhaps we can use it for other things, e.g. call it `navigating-away` rather than something VT-specific. Incoming - when the page is render-unblocked or reactivated, but before presenting. > 2. The nested example seems incorrect. I think it should be this, as `::view-transition` is a pseudo of the root : > ```css > @media (page-transition: outgoing) { > :root:has(body.disallow-outgoing-transitions)::view-transition { > display: none; > } > } > ``` > However, with `@media (page-transition) { ::view-transition { display: none } }` in the UA, in practice the logic would be flipped around, no? Like this: > ```css > @media (prefers-reduce-motion: no-preference) and (page-transition) { > ::view-transition { display: block; } > } > ``` > > Or, more selectively: > ```css > @media (prefers-reduce-motion: no-preference) and (page-transition) { > :root:has(body.allow-outgoing-transitions)::view-transition { > display: block; > } > } > ``` See below. unlike what I wrote in the OP, I am convinced that we should have a "hard" opt-in, probably in HTML, to avoid cases where someone accidentally enables cross-doc-VT with e.g. by putting `::view-transitions { display: block }` without anything in their CSS (media-queries don't add specificity). > 3. Would this replace the meta tag opt-in? If not, what happens when both are set with contradicting values? More specifically, what happens if the meta tag opts-in, but the the UA default styles (which is essentially an opt-out) is applied? Thinking about this again, I think we should actually keep the `meta` opt-in and not change the default style. The reason is that with only using default styles it's very easy to accidentally enable cross-document transition, as media-queries don't affect specificity. So I suggest to keep the opt-in, and make it very simple and binding. And use the media query for everything else: - last-frame/first-frame customizations - disabling/enabling the transition based on all kinds of conditions > 4. When the outgoing page does not opt-in but the incoming page does, do we then get a simple fade-in of the root or would all transitions get skipped? Put differently: it’s a double opt-in? It should be a double opt-in. Transitioning from blank is something that we should address separately, but in general view-transitions don't help you with that at all, and you can use regular `keyframes` as pages do today - the novelty of VT is by having detailed and separate "old" and "new" states and that doesn't apply to from-blank transitions. We should experiment with how VT interacts with pages that have non-VT entry animations, e.g. perhaps the keyframes can be reused. > 5. With the JS approach, one quickly can set up some classes on the root based on the directionality of the page hierarchy. For example, clicking from an overview page to a detail page should slide all stuff to the left, whereas then clicking the home icon should slide all stuff to the right as you’re going back from that detail page to the overview page. > Maybe there should be some way to pass this type of info from one page to another, which could then also be taken into account in the MQ on the new page? That way, an author can set up the appropriate vt-names and animations, based on that piece of data. In [[css-view-transitions-2] Declarative opt-in for cross-document navigations #8048](https://github.com/w3c/csswg-drafts/issues/8048), you proposed for the page URL to be that piece of data. Is this still considered? That was an attempt to think ahead, but I actually think we shouldn't do any of this at all. It leaks HTML/routing concerns into CSS. If a developer wants to achieve that kind of customization, they should put something in the DOM, like `<body data-prev-page=home>` based on the referrer or query variable or whatnot and cascade the CSS changes you want, such as enabling/disabling the transition altogether. -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8868#issuecomment-1560484768 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 May 2023 05:38:47 UTC