Portals

Portals explainer

Jeremy: You want to put content in a page, and enable seamless transition when navigating to that page.
... the user goes from point A to point B without a full load cycle in-between.

[API Surface]

- <portal> element

scribe: would be similar to iframe in that enables inclusion, but it has an "activate" method
... it promotes the activation target to the top-level browsing context on activation
... e.g., zoom the portal to fill the screen
... the top-level page can embed the previous page as a portal, to enable going back and forth between documents without losing context (e.g., script context)
... the portalHost object allows communications with parent page that hosts the <portal> element
... that relationship is not reflected in the existing frame hierarchy.

[Use cases]

1) Multi-page web app

scribe: the app can orchestrate seamless transitions between docs without needing to rewrite as a single-page web app

2) Partial preloading

scribe: you can load a template in a portal, then flesh out with content that the user actually selected
... could work also in cross-origin pages

3) Pre-navigation preview.

scribe: eg., touch gesture on a mobile device
... as the user release content, it replaces the existing page.
... this allows content to existing in different documents and achieving these effects

4) Cross-origin

scribe: seamless navigation among origins to complete a journey

Draft spec

State machine

Jeremy: We need to specify interactions between these new browsing contexts and the various features that interact with iframe and nested browsing contexts
... e.g, respect cross-origin policy
... in Chromium this is implemented behind a flag
... targeting broader experimentation later this year or in early 2020.
... may start experiments with same-origin use cases, but we think the interesting use cases are really cross-origin since rewriting as a single-page app is not an option.

<Zakim> rouslan, you wanted to ask why only portals should have these wonderful experience as opposed to all existing transations and popups

rouslan: Love the UI
... can this type of UI be applied elsewhere.
... why not bring this new UI to existing APIs, e.g., transitions between pages or when you pop up a window
... I call window.open(); today it opens a window with a new URL. What if, instead of opening the window as we do to today, we open a window in a corner and the user needs to click on it to get it.

Jeremy: Need an API for any sort of animation.

Kenji: <portals> does not have anything to do with animation..it's like an iframe because it embeds things, but unlike an iframe you can navigate to it.
... the fancy UX you are describe may already be achievable with CSS today

rouslan: So <portals> basically is "breaking out the iframe"

Jeremy: If all your content is in a single page today you can get animations with CSS. The challenge today is when content is in multiple pages, or even moreso cross-origin. That's where you need portals.

Kenji: The UI is left to designers based on context; the API is lower level than that
... maybe at some point we can add a higher-level API for some UX patterns.
... All but one demo today are live (with features behind a flag)

slightlyoff: There are lots of debates about the shape of the API

Jeremy: You don't call "activate" until you've completed an animation

slightlyoff: What happens in case of problem inside of activate?

Jeremy: As we currently think about it, the activation occurs. If you do nothing or throw an exception, your predecessor browsing context is closed

Rick_Byers: We think that most of these use cases, especially on phones, may raise perf issues

[Debate about whether people use portals wisely taking into account performance implications]

Kenji: Performance is something everyone should take into account (for this API or others); some do and some do not

Rick_Byers: Does a page being hosted in a portal need to opt-in?

Jeremy: We will respect CSP - if you don't want to be framed you won't be portaled either.
... we'd like feedback on defaults

Romain: Coming back to the publication use case (Manga)...would you implement that as a link of pages, or could you implement this as a master page with a set of portals.

Jeremy: You probably would do this as a linked chain for performance reasons. But there may well be carousel use cases as well
... people will need to make tradeoffs (e.g., content common to documents that can be preloaded)
... e.g., for a table of contents, preload the intro which is common, then do something else for other sections

manu: Can you open windows with different sizes?

Jeremy: When activated portal gets the size of the top-level context. The browser is updated to show the portal origin.

Manu: In the shopping example where there's a preloaded template, what communication happens? Is there a comms protocol between contexts?

Jeremy: Post-message while embedded. You can also put data in the activate message.

Manu: Regarding security and privacy - what happen if people run bitcoin miners ...?

Jeremy: You can do bitcoin mining in an iframe; so same problem elsewhere.
... user agents would be encouraged to present info about resource consumption to users in a useful way

Manu: In the portal, content is loaded (including JavaScript) as soon as created?

<hober> ?

<hober> q

Jeremy: Correct. There are proposals elsewhere for pausing iframes in some situations, and that might be used with portals, but not currently part of the proposal.

deiu: What about threading?

Jeremy: In Chromium we have the flexibility of putting portal content in a separate process.
... portal spec gives us flexibility, and we expect in typical use cases to do so
... heuristics might lead us to do different things (e.g., due to resource constraints)

deiu: Is there any restriction from a service-worker perspective? Anything resource that you pull in from a service worker could be available to portal

Jeremy: I don't see why not.
... In current model portal cannot take input until activation.

@@: So with portal, resources are loaded in background?

Jeremy: Yes. You can render it onscreen or offscreen.
... similar to iframe..it begins to load when parent doc loads

dino: Suppose you are a news site with 50 articles on your home page
... you think the user might go to 20 of them
... it seems frightening that there's any easy win for developers to pre-load resources
... the scary thing is that this seems to incentivize developers to create an experience where the performance will likely deteriorate

Kenji: It is true that people say "we want this" and then they load a bunch of documents and they realize that it won't work for them

Dino: But it will...you get an experience where the most popular link is pre-loaded
... Why wouldn't google search results pre-load every amp page

Jeremy: This is true for many Web APIs..I don't think portals solves this issue nor does it do much new with respect to this issue

Dino: Can I choose to not load a portal?

Kenji: We hope that web site owners respect user settings in their browsers about resource usage
... it might not be that hard to track resource usage (e.g., what was preloaded but not used)

Jeremy: I think restricting the API to "one portal per domain" would make the proposal unpredictable

Dino: My main point is that this incentives people to use up user resources.

Jeremy: We should enable good user experiences. Many good user experiences could be abused.

Kenji: Maybe there is room for surfacing some information to web sites to incentivize them to do the right thing.

Jeremy: The UA could do some things to e.g., ensure CPU cycles are avilaable.

Rick_Byers: Google search has indicated intent to provide portal experiences to lightweight content
... though I share Dino's concern.
... one note is that the browser can intervene here on the user's behalf in light of CPU availability.

Dino: Can you detect that portal didn't load?

Jeremy: We don't have that today (e.g., "UA declined to load")

Rick_Byers: We have some ways, e.g., load event does not fire

ricea: Do portals obey xframe options?

Jeremy: Yes. That was subsumed by CSP.

koto: How about other security-based header policies such as @@, the request header that talks about mode of navigation
... how do you sync with that?
... there are also a set of recently introduced headers that isolate windows
... would those be respected as well?

Jeremy: I'm not familiar with the particular headers you mentioned. But in general our attitude is that we should respect the intent of these headers.
... so if someone expresses an intention wrt to an iframe, we would do that for a portal while in the background
... it sounds like we should be sending nested navigate, but I'm not aware....
... my general position is that "while embedded, looks a lot like an iframe"

dlibby: You mentioned that portals don't have input until active. How does that relate to accessibility (e.g., screen readers)?

Jeremy: We have bug's registered to look at this in more detail.
... insofar as portals are used as previews, we could use alt/title on portals
... we certainly think that if we are not accepting input we should not accept input from specific APIs.
... but agree we need to make accessible experience

ask dlib

adrianHB: Why not just use iframe?

Jeremy: One thing I would point out is that we are allowing some operations that are not allowed for ordinary iframe.
... activate would not make sense for some iframes, for example.
... similarly there are some operations allowed on embedded contexts that would not work when portal is top-level
... you would also have some funny edge cases
... related to the ability to modify or not modify parts of the DOM
... we thought that an element would be less confusing

deiu: Other than the resource usage concerns, there are also some UX concerns
... if a company wants to provide a specific user experience, they may want to describe or control how the experience looks as transitions to portals happen

Jeremy: We respect CSP so you can control which things are embedded.
... e.g., I will only load frames from these origins
... or I will only allow myself to be loaded if within certain origins.

deiu: Can you restrict recursive activation of portals?

Jeremy: No. Just like navigating away from any top-level origin

Kenji: You can also have out-of-band communications among parties

Jeremy: Don't link to sites your users don't want to go do. Navigation surrenders control.

mattwoodrow: Could you allow authors to request portals. And if UA says "No you cannot have one" and allow the author to manage a fallback

<dino> ian: isn;t noscript or noframe a variant

<dino> jeremy: that's a global vairant

mattwoodrow: Video doesn't have this and it sucks

Kenji: Could be interesting to consider

Jeremy: But I have some concerns about expressing this in the DOM
... you could imagine extending the API like saying "This one is deferrable" and then being able to ask "Did you load this one?"

AdrianHB: Could you render the HTML of the portal as a fallback?
... if the browser chooses not to fetch the portal, it could deliver what was in the mark-up

Jeremy: Not sure I necessarily agree; authors may not support the use cases
... I suspect authors will feature detect
... do you want to give the browser the right to make a decision?
... I expect sites will present one user experience if portals are supported, otherwise some other user experience. I would not expect fine-grained experience management.

Kenji: I think it's interesting to consider "regular nav" as a fallback

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/?//
Succeeded: s/figure/fire/
Present: prushforth hober rouslan
No ScribeNick specified.  Guessing ScribeNick: Ian
Inferring Scribes: Ian

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)