- From: Domenic Denicola via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Sep 2021 21:00:13 +0000
- To: public-css-archive@w3.org
Heya, @chrishtr asked me to take a look at the proposal here to give my thoughts. Based on https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-805117925 and some subsequent ones here is what comes to mind: - Using `resizeTo()`, instead of e.g. a HTTP header, is a nice trick and should make this more usable for people. - It seems like there are two opt-ins on the outer side: first, you have to set `allow="resize"`, and second, you have to actually use the `from-element` keyword. I don't know if we need both of these. I would probably cut the `allow="resize"` since the CSS `from-element` seems nice and versatile. - The dance where the parent is allowed to cancel the event seems potentially tricky to implement and could cause slowness, for out-of-process iframes. You would need to send an IPC to the parent frame to fire the resize event, which would then send an IPC to the child frame telling it the result, before any resizing actually happens. It seems doable, but maybe worth considering whether or not running a full JS function here is really needed. The alternative is basically trusting any iframe that you set `contain-intrinsic-size: from-element` on, plus you could impose declarative constraints (e.g. `max-width`/`max-height`). - However, I'll note that `window.resizeTo()` is already async ([test](http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=9599)). So there's at least some precedent for resizes not taking effect synchronously. It just might be bad for users if resizes are slower than they need to be. - +1 to the promise return value not making too much sense, because the resize only had an effect if the outer page uses `from-element`. - This whole feature needs to not work for situations like [fenced frames](https://github.com/shivanigithub/fenced-frame/) or [portals](https://github.com/WICG/portals) where we also censor postMessage(). That seems fine. - I would not auto-inject into srcdoc; that seems strange. - +1 for strong event loop/ResizeObserver integration at the spec level. I don't think this should be too hard. - I can't quite tell from the minutes but it seemed like people might be saying there's precedent for not requiring an embedee opt-in, and thus we should consider not requiring it for this feature? That'd be a very bad cross-origin information leak so please don't do that. I hope this helps, and would look forward to working on this feature with you all! -- GitHub Notification of comment by domenic Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-912052715 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 September 2021 21:00:15 UTC