4 ms·
Looks cool. Some random thoughts that may or may not be of any use to anyone: - It looks like postMessage is the communications channel to use between host and
by mstade 6y ago
Looks cool. Some random thoughts that may or may not be of any use to anyone:
- It looks like postMessage is the communications channel to use between host and portals and vice versa, which makes sense to me.
– Looks like it'd be trivial to use portals to create an SPA-like experience without having to give up on multiple independent pages. The SPA-part would be aggregator pages that use postMessage to communicate and coordinate, but it's unclear what the performance implications of this would be. Are portals meant to be lighter weight than iframes or are they entirely new browsing contexts and therefore just as heavy?
- Can hosts inform the styling of portal pages, beyond the portal page recognizing that it has a host and therefore switching style sheets? I guess you could do this with postMessage, but I mean are there plans to formalize styling and style boundaries in some way, perhaps not unlike web components?
- domenicd 6y agoNote that postMessage is only allowed same-origin, for privacy reasons (to avoid cross-site tracking). Portals are entirely new browsing contexts, so just as "heavy" as iframes. Iframes are generally not that heavy though (especially compared to modern JS frameworks); I'd encourage you to experiment to see how well portals might work for your use cases. Allowing hosts to inform the styling of portaled pages is a communications channel, so we don't want to allow that directly (since it makes cross-site tracking easier). That said, a page can tell via JavaScript (by testing `window.portalHost`) whether it's being portaled, and we think it's probably a good idea to extend this to CSS. See https://github.com/WICG/portals/issues/3 https://github.com/WICG/portals/issues/3 . This is one noisy bit, so it shouldn't cause tracking concerns.