Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What should closed portals display? #251

Open
domenic opened this issue Sep 22, 2020 · 5 comments
Open

What should closed portals display? #251

domenic opened this issue Sep 22, 2020 · 5 comments
Labels
design work needed An acknowledged gap in the proposal that needs design work to resolve

Comments

@domenic
Copy link
Collaborator

domenic commented Sep 22, 2020

This should probably be specified.

Options I can think of:

  1. The fallback content, e.g. <portal src="data:text/foo,bar">This will be displayed</portal>.

  2. A transparent box of the same size as the portal.

  3. Generate no boxes, as-if display: none.

  4. A user-agent-defined error signifier, like a broken image or network-error iframe.

At first (1) felt natural, but I think it'd probably be more harmful to developers than helpful. In particular fallback content is mostly useful for "your browser does not support portals". Cases of "your browser does support portals, but there was an error displaying the content" seem different. So I lean toward one of the other options.

@domenic domenic added the design work needed An acknowledged gap in the proposal that needs design work to resolve label Sep 22, 2020
@jakearchibald
Copy link
Collaborator

2 means that layout doesn't change between activating and reportaling

@jeremyroman
Copy link
Collaborator

FWIW, at TPAC 2019 there were a number of folks who felt that fallback content was important if a portal wasn't loaded due to resource limits, which feels similar.

There's also, I guess, a 1.5, that it generates a block/inline-block of the same size and generate boxes inside it, which should often be the same layout size.

@kjmcnee
Copy link
Collaborator

kjmcnee commented Sep 24, 2020

I'd be worried about layout jank for options which change size based on whether something's loaded in a portal. Option 4 could make it harder to have nice UX for gracefully handling errors, plus there's little to distinguish a closed portal and a portal that hasn't loading anything yet. So I would lean towards option 2 or possibly jeremyroman's option 1.5.

@domenic
Copy link
Collaborator Author

domenic commented Sep 24, 2020

It sounds like people are generally in favor of not changing the layout size, which sounds good to me.

I don't really understand 1.5. What's the motivation there? Why would there be more than one box for a single <portal> element? Would the boxes be transparent, or...?

@jeremyroman
Copy link
Collaborator

I mean that the portal would render like an explicitly sized <div> would.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design work needed An acknowledged gap in the proposal that needs design work to resolve
Projects
None yet
Development

No branches or pull requests

4 participants