Re: [csswg-drafts] [css-view-transitions-2] Media query alternative to cross-document opt-in (#8868)

@noamr 

> * It's totally different from the way you disable of same-document transitions (`::view-transitions { display: none }`)

I think the above might be the source of the confusion. The above isn't an opt-out, it isn't a way of 'disabling' view transitions, it's just _hiding_ them. All the events relating to the view transition still happen. It's like saying `iframe { display: none }` disables iframes - it doesn't, all the loading of the iframe still happens, you just don't see the result.

There isn't an opt-out for SPA transitions, because they're opt-in by calling `startViewTransition`. If you don't want a view transition, you simply do not call `startViewTransition`. 

Maybe the [example in the article](https://developer.chrome.com/docs/web-platform/view-transitions/#reacting-to-the-reduced-motion-preference) is misleading. It should really be a condition around calling `startViewTransition`, like how the `skipTransition` option works in the [helper function](https://developer.chrome.com/docs/web-platform/view-transitions/#not-a-polyfill).

Cross-document transitions should work in a similar way, by having an opt-in that you can make conditionally. I don't think we should have a system where the opt-in is big and dumb, and you have to hack around its big-and-dumbness by hiding loads of unintended transitions it creates.

> * Its limited to opting in/out, it requires extensions or JS

I think you're getting too hung up on it being a boolean. The intention is for it to be conditional using existing features like media queries. And, like I pointed out in the other thread, its boolean form is just a shorthand for a block form.

> to allow, for example, different names for cross-document transition.

The primary goal should be to allow for cross-document transitions to work exactly like SPA transitions. That's the feedback we got from Mozilla and developers. If you're going to take things in a different direction than that, it should come with good justification.

Right now, with SPA transitions, you can easily add a class name to the root for the duration of the SPA transition. This allows the SPA transition to use particular names for that SPA transition. So, if there's a case where the SPA transition needs to use different names to cross-document transitions, that use-case is already catered for.

> ```css
> #my-element { view-transition-name: some-name }
> 
> @media (page-transition) {
>    #my-element { view-transition-name: some-other-name }
> }
> ```

Fwiw, you could also do this with the option 2 at https://github.com/w3c/csswg-drafts/issues/8683, by using wildcard URLs. I'm not convinced it's useful, but being able to do it based on particular URLs is definitely useful.

> we would have to enable the `::view-transition` pseudo-element when navigating to a page that can potentially trigger a page transition.

That's a pretty bad smell around this proposal. You're having to create a `::view-transition` for a reason other than its designed purpose - you want to use its computed rendered state as a boolean signal. What happens if the developer has specified styles or animations on `::view-transition`? Will they see these animations play twice, once on the outgoing page and once on the new page? Will they see a flash of style when `::view-transition` is painted on the old page?

> I think we should actually keep the `meta` opt-in and not change the default style.

The meta tag was intended as a temporary hack. If you're wanting to keep it, you need to justify why it's a good part of the design. Since view transitions are a visual design feature, I really think the opt-in should be via CSS. The reason they're not opt-in via CSS for SPA transitions is the timing for the DOM change is already performed by JS, so `startViewTransition` acts as both an opt-in and indicating the timing of the change.

I'm really worried this API is heading in a hacky direction to get something out the door quicker.

-- 
GitHub Notification of comment by jakearchibald
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8868#issuecomment-1560622117 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 07:51:16 UTC