- From: Jake Archibald via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 May 2023 18:16:02 +0000
- To: public-css-archive@w3.org
> It's a simple boolean with "we might add more things to it in the future". I'm saying, let's use name-matching now instead of "boolean plus future unknown things". Media queries already exist, so they're not some magic future thing we don't know about. Also, I think a way to change transitions depending on the incoming and outgoing page should be part of the initial launch of the MPA feature. With SPA, we ask developers to use class names on the root. The MPA solution should be similar to that, or the MPA solution should be available to SPA too. Note that these media queries don't just enable opt-in/out, they also allow for different transitions to be defined depending on the source and destination. The name-matching part doesn't allow for that, and I don't see what use it would be when there are more extensible solutions on the table. Have you seen https://github.com/w3c/csswg-drafts/issues/8679? It seems similar to your name-matching proposal, but doesn't require a CSS property that only works on one element. > > Two problems with this: You have to do special hard-to-reason-about things to use the same transitions for both SPA and MPA > > I don't understand this problem. You have to give your whole transition a global name/namespace, and make sure both documents know about it. It's global as much as the rest of CSS is - you can use media queries to say when particular rules apply. > This is similar to giving elements that transition to each other matching names. Where is the "hard to reason" part? You're proposing a CSS property that will exist on every element, but only ever means something on one element. That seems confusing. Or, you're proposing that `view-transition-name` has an extra feature attached for the root element only, and for MPA transitions only, and means you need to do something special if you want to share transitions between your MPA and SPA (by forcing a name other than `root` for the root). This also seems confusing. > > it creates a CSS property that only works on one element (or a property that works very differently on one particular element). That's the whole reason a global switch was proposed rather than something per-element. > > It creates one element in the same way `::view-transition` is a pseudo-element of only one element. If in the future we enable several view transitions to work simultaneously, this can be more flexible. Maybe I'm misunderstanding what you're proposing, because that doesn't seem like a meaningful comparison. I thought you were proposing a CSS property, `page-transition-name`, that would exist on every element (because that's how CSS properties work), but only ever apply to the root element. `::view-transition` was designed from the start to be on other elements in future. It's one of the key reasons we went for pseudo-elements rather than shadow DOM. I don't think the simultaneous-transitions argument applies for page transitions, as there can only be one page transition at once due to the scope of navigations. > > This is already an issue with @Keyframes, @font-face, @Property etc etc, so we can follow the same rules. > > All of these are kind of "definitions" - having a named thing (font, animation, property) and declaring what it does. For example, you can't put those inside a media-query. Sure, but I don't think that difference matters in this context. We still have an order to apply the rules from those other features. > One thing I don't understand is - if this is not about maintaining author intention, why do we need an opt in for same-origin in the first place? What gave you the impression that author intention wasn't being maintained? That's the whole reason for the opt-in. With SPA, the developer opts in via `startViewTransition`. They can make this opt-in conditionally with the knowledge of the before 'page' and after 'page', along with user preference. They use class names to customise the transition for those specific states. With MPA, the developer opts in via the opt-in proposed in this issue. Via media queries they can make this opt-in conditionally. With https://github.com/w3c/csswg-drafts/issues/8683, they can make the before and after page part of this condition. The same feature allows them to customise the transition for specific states. Existing media queries let them react to user preference. If https://github.com/w3c/csswg-drafts/issues/8683 is enabled for SPA too, developers will be able to use the same animation styles for both SPA and MPA, which is one of the key goals. -- GitHub Notification of comment by jakearchibald Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1555057146 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 19 May 2023 18:16:04 UTC