What should closed portals display? #251
Comments
|
2 means that layout doesn't change between activating and reportaling |
|
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. |
|
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. |
|
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 |
|
I mean that the portal would render like an explicitly sized |
This should probably be specified.
Options I can think of:
The fallback content, e.g.
<portal src="data:text/foo,bar">This will be displayed</portal>.A transparent box of the same size as the portal.
Generate no boxes, as-if
display: none.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.
The text was updated successfully, but these errors were encountered: