You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would really help adoption if a <portal> could re-size based on it's content - otherwise every system will need to make their own buggy postMessage() thing to do this.
From a security point of view, a cross-origin document would need to opt-in to having this bit of data exposed (w3c/webappsec-csp#391) - otherwise a malicious website could frame a website, and infer information such as the users logged in state.
From a rendering point of view, there is a risk of a circular styling issue. While Safari has got this to work via their "frame flattening" feature, I'd be happy to simply limit it to the height changing automatically (not width); and the browser only doing 1 automatic height update (when the CSS has loaded)... maybe with a JS method the child document could call to ask for it's height to be updated (e.g. when more content has loaded/changed), otherwise have it fallback to scroll bars.
I'm sure widget creators will be able to work with this setup, where the parent website would then be able to simply include one <portal> tag to implement the third party widget, and it would be safely isolated from the main page (rather than including some unsafe third party JavaScript to create all the content).
The text was updated successfully, but these errors were encountered:
Following on from #109.
And the discussions regarding
<iframe>
auto-resize (whatwg/html#555, w3c/csswg-drafts#1771)It would really help adoption if a
<portal>
could re-size based on it's content - otherwise every system will need to make their own buggypostMessage()
thing to do this.From a security point of view, a cross-origin document would need to opt-in to having this bit of data exposed (w3c/webappsec-csp#391) - otherwise a malicious website could frame a website, and infer information such as the users logged in state.
From a rendering point of view, there is a risk of a circular styling issue. While Safari has got this to work via their "frame flattening" feature, I'd be happy to simply limit it to the height changing automatically (not width); and the browser only doing 1 automatic height update (when the CSS has loaded)... maybe with a JS method the child document could call to ask for it's height to be updated (e.g. when more content has loaded/changed), otherwise have it fallback to scroll bars.
I'm sure widget creators will be able to work with this setup, where the parent website would then be able to simply include one
<portal>
tag to implement the third party widget, and it would be safely isolated from the main page (rather than including some unsafe third party JavaScript to create all the content).The text was updated successfully, but these errors were encountered: