KC: nothing much has happened since f2f.

Dan: who are we waiting for feedback from?

KC: we got them to to back to the drawing board and consider if it could be based in iframes.

David: we had comments on their explainer.

David: has the explainer been updated?

Lukasz: the document is unfinished in my opinion - i am seriously concerned with the privacy [discussion] in the github thread. data leaks between the origins. not clatified in thread.

Dan: maybe bump and come back to it?

Peter: bump and wait?

KC: lot of feedback from Alex Russell here.

KC: I can monitor it.

Peter: kicked it 3 weeks

Ken: David summarized a bit.

GOTO JUMPBACK;

PORTALS:

Ken: Two big issues, why is this not an iframe, tried on Chrome but didn't work out well. FP didn't work well for Portals. The explainer needs to be clarified why it can't be an iframe, also there was the part about double keyed cookies. Some comments on the

Sangwhan: When you jump into the portal by throwing out the existing state it won't work..

Ken: kind of the point...

Sangwhan: i don't know about others but I feel like this is rather inellegant. We've done so much work - one weird element iFrame that we've spent a lot of time making it work.

Ken: they are trying to work around restrictions with iframe but ... really really good explanation of why this is not an iframe. and how they are going to solve these points of different specs refering to iFrames.

Sangwhan: Wonder if there will be other cases aside from AMP that would benefit from this.

Kenneth: Commerce might, Denmark has a bunch of third party payment handlers running on different origins.

Sangwhan: That feels like web payments would be the solution, doesn't feel like the right tool for this.

Dan: Parenthetically: there is an advisory council about AMP which some signers of the AMP letter have been a part of. If anyone is interested I can explain later.

Kenneth: Explainer could use a bit more detail on use cases. Should ask for a update.

Alice: There is a key scenarios link from the original request.

Ken: "nice transition" [as a key feature]

Alice: use case down at the bottom is interesting - making a multi-page application look like a single-page application.

Ken: you might not need all these things for same originl - so you could make a simnpler solution that works for same origin.

Dan: The provenance of the content has been a constant issue, and a smooth transition could actually obstruct that there is a change of the origin.

Hadley: It feels like a feature to work around SOP.

Peter: If you embed a third party origin as yourself, and then switching over without a transition doesn't seem right.

ylafon: https://github.com/jakearchibald/navigation-transitions

Dan: We have provided feedback, whether or not that is enough and whether this is addressable is something we should follow up on.

Alice: there was a talk about it at I/O

Tess: how should we handle cases where we generated questions during our review and they go awol? Seems like we shouldn't leave the issue open indefinitely.

Dan: I think we at least need some additional labels to show when TAG feedback isn't acted on...

Alice: we need a time-out state

Tess: follow-up question which is a blink question... is the expectation that raising the question to the tag satisfies the blink process requirement or are they expected to take the feedback into account.

Alice: that's an active question. It suffices to file a review - the gate is a "lgtm" - link to the review - at the intent-to-ship stage you should already have a review. if in between those things the TAG review hasn't happened, it is up to the API owners to make a judgement call. If they look at the TAG review thread and see that the requester hasn't taken the feedback onboard then they might not progress it.

Alice: what is the user-facing [end user facing] problem that this solves, what is the proposed solution, worked excamples showing how the solution solves the problem...

Hadley: this solves a frustration I have where we are getting specs that are for developer needs as opposed to user needs.

Alice: yeah, though there are many dev-focused specs that have an end user benefit e.g. Intersection Observer.

Dan: I'd like to cover a lot of this in the f2f - including how we can be more effective / responsive to review requesters....

Alice: the last 2 comments are from us - we haven't heard from blink since feb 14.

[...discussion on closing it...]

David: there's a bunch of stuff we don't udnerstand about the design.. feels like this feature has moved forward [in blink]

Alice: we could say "we have had this feedback - no responses..."

Dan: is this overtaken by events?

Tess: I have concern - minting a new element that is a way of embedding other content. Is adding new things like this something we should be doing instead of adding these features to iFrame. I feel like adding a feature like this has to pass a pretty high bar. Yes it's been overtaken by events in the sense that [blink] has proceeded full teams. I'm concerned about closing it "overtaken by events" and they look at this as tacit approval.

Alice: seems like there are valid concerns - listing them out succintly...

Tess: [takes an action to summarize state on the issue] Peter and Dan can you try to figure out set of new labels to use for this.

Dan: I'll do some research and propose something on slack.

Hadley: we could use something like "unresolved"

Tess: where we close issues and are not satisfied - in TC39 and WHATWG they have "needs x" labels. We could have "needs explainer"

Dan: I'll add it