Lea: First time we look at this.

• Mozilla is positive, no response from WebKit.
• Requires both opt-in from both pages, AND same-origin.
• Opt-in is HTML, for a CSS feature, which seems suboptimal. CSS proposal may be better, though not colloquial to CSS as is.
• Opt-in might be too general, aren't there use cases where you only want to opt-in more conditionally? [they said this is still fleshed out]
• +1 for Declarative API!
• A bit unclear what happens if both documents opt in, but there is no JS to customize the transition.
• A bit worried about the user experience on slow networks. Does the transition abort at some point?
• sticky transition bugs: if some JS code sets the transition params, and a different part of the code calls event.preventDefault()?

<blockquote>

We were happy to see cross-stakeholder support, though we'd like to see WebKit’s position as well. We also liked the secure-first design, with two-way opt-in and a same-origin restriction. Is cross-origin a non-goal because there are few use cases for it, or because you are not confident in the security of a cross-origin opt-in?

It seems a little inflexible to have the opt-in be HTML (as you point out); A CSS mechanism would indeed be preferable, though the proposed syntax is not idiomatic to CSS, since there is no precedent of @-rules that take values (this does not necessarily mean this is a bad idea, but when something creates a new precedent, we should spend extra effort to make sure there is no alternative design that is more consistent with the existing Web Platform without sacrificing usability.

Props for a declarative-first API too!

We had a few questions, that we didn't find the answers to in the explainer:

• What happens when both documents opt in, but there is no JS to customize the transition?
• What is the user experience on a very slow connection? We see there is an implementation-defined timeout, we do worry that clicking on a link, then nothing happening, then suddenly a transition could result in jarring user experience.
• What is the user experience if one part of the code customizes the transition parameters, and another calls event.preventDefault() so the navigation never actually happens?

</blockquote>

Rossen: comment looks great. concern with slow connection - how does it differ?

Lea: transition need to wait... how long does it wait... what happens? From user's pov?

Rossen: looks at spec. In section 7.4 - a quick algo - 4 main steps -

Rossen: proceed with the comment - lea's point about the slow connectiom might be answered by the timeout... which cancels the transition.

[long reply to Lea, plus an ED is out]

bump to plenary

Dan: Looking at new draft spec

Lea: Cross-fade? what happens?

Lea: "the transition happens" - what happens? [see comment(https://github.com/w3ctag/design-reviews/issues/851#issuecomment-1618916752)

Lea: what happens in slow connection... timeouts... not an ideal user experience. Response is "because it's same origin it shouldn't take that long" - not a given that it's tested for slow connections and wifi...

Dan: +1

Rossen: i think most of the questions are answered OK... Even for the slow connection.. I think it's a valid point. You control the to and from experience - you can have whatever logic you want as a developer... You can do all of this because it's the same origin...

Lea: still unclear - how do you prevent a pause after clicking on a link? Are you able to detect if the user is on a slow connection? Proposed media query...

Rossen: maybe start a timer and...? would the browser UX be engaged in this case? so the browser has a spinner... That's not gonna be engaged at all...

Lea: I would expect the browser spinner would start when you click on the link. Maybe that's enough signal that something's happening. Just want to make sure users on slow connections don't sit there with no feedback.

Rossen: I think that wouldn't happen.

Dan: agree this should be in the spec - right now it doesn't mention "slow"...

lea to leave feedback

Rossen: a section on security considerations -- "concern around safety of 3rd party css - however as a general rule 3rd party css should come from trusted sources" -- that's ... nothing happens as a general rule on the web. We need a threat model to understand timing-related attack vectors that weren't previously exposed.

Dan: could we ask them to do a more rigorous security review?

Rossen: same origin nav could happen between a 3rd party re-direct... This can cause a (minor) situation... unexpected transition... I think this section needs to be ... strengthened ... Same origin without cross-origin re-directs.. that's fine. Other 2 places this is spelled out - in the algo for setting up cross origin view transition...

Rossen: I'm luke-warm. They did spell it out and call it out.

Propose close. draft text:

`Looking at the issue @hober during our virtual f2f and following all threads, we agree with @LeaVerou and are happy to resolve it. Looking forward to seeing this feature adopted and in use. Thank you for flying TAG.

@LeaVerou please close once you have a chance to confirm your concerns are addressed.`