- From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 May 2023 17:52:10 +0000
- To: public-css-archive@w3.org
> @noamr > > > > `@font-face` and `@property` are also global declarations in CSS. > > > > > > They give meaning to all kind of names, but they don't affect the style directly. > > The proposed opt-in doesn't affect style either. It opts into a view transition on navigation (like calling `startViewTransition`). > > > an issue of unintended visual effects by having e.g. an SPA transition in both documents lead to a spurious MPA transition between the two documents. > > Can you go into more detail about that? See #8677 - I don't think it'll be unusual for the same animation declarations to be used in both SPA and MPA transitions. Let's say `example.com/bank` and `example.com/insurance` both work on their SPA transitions independently, and then find that going from one to the other created an unintended MPA transition with random weird associations between elements that happen to have the same transition names. Let's say we go with a "boolean with future extensions" option. That would solve the initial problem if they're both SPAs. But what if they're MPAs? `example.com/bank/transaction` has a transition with `example.com/bank/summary`, and `example.com/insurance/view` has a transition with `example.com/insurance/home`. Suddenly the transitions from bank<->insurance would work or none would work. A boolean is an all-or-nothing for same-origin MPA transitions, which is sometimes what you want and sometimes it isn't. We can solve this either by a URL pattern, or by a namespace, which is the same thing in a way, but there's something more cleaner with names that's consistent with the existing view-transition-name. > > There's a doc internally that compares SPA transition features with MPA, where a lot of this is discussed (although it should be across various issues now), @khushalsagar can give you access. > > > IMO any kind of boolean opt-in doesn't solve this > > This proposal allows for more than a simple boolean [#8048 (comment)](https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1495777539). Also, the conditionals can be complex thanks to media queries (see the other issues on url matching). 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". > > > Instead, I propose something a bit more flexible and : the `:root` of both documents has to share some sort of name. It can be the `view-transition-name` (perhaps if it's not "root", but that might be a bit too implicit), or a new property like a `page-transition-name`. Only if the names match, the view transition would be enabled. > > 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. This is similar to giving elements that transition to each other matching names. Where is the "hard to reason" part? > 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. > > > * making sure that cross-document view transitions are intentional and the internal transition names match what the author has meant > > I think a key to this is ensuring that SPA and MPA transitions across the same two pages are as similar as possible. The difference being that one opts in with JS (by calling `startViewTransition`), and the other opts-in via some other simple means. > > > to solve this in CSS you'd have to coerce CSS to do several things that it's not used to doing... for example, you might have `@view-transition same-origin` in your inline css, and then include some cross-origin stylesheet that would override it with `@view-transition same-site` or `@view-transition urlpattern(...)`, which would require fiddling with cascading rules. > > 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. > > > I think we would have to solve (2) on the HTML level, or even CSP, and my main concern there would be that it would become a side-channel for cross-origin pages to pass privacy-related information to each other, which an opt-in wouldn't solve. > > Can you provide details of the attack you're trying to prevent? [Third party CSS isn't safe](https://jakearchibald.com/2018/third-party-css-is-not-safe/). The whole cross-origin problem has not been discussed yet so this is more of an initial thought. The problem space is of passing user information in a side-channel, like a make-shift same-site cookie that's not guarded by the regular cookie protections. My main point is that cross-origin is a different problem space than maintaining author intention when switching document. 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? -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1555030205 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 17:52:12 UTC