Re: [csswg-drafts] [css-sizing] Auto-resize iframes based on content (#1771)

> Please make whatever property is necessary as opt-in in same-origin contained frames also implied for srcdoc content.

You don't need to have an `html` tag in the code to set a property on it; dropping a `<style>html { intrinsic-size: auto; }</style>` into the srcdoc string suffices, since the `html` element gets auto-created by the HTML parser.

> Looking at this again it struck me there's no success/failure indication for the caller of window.resizeTo(). Not sure if we can return a promise there that resolves with the new/unchanged dimensions, but that would probably be desirable I suspect.

It currently returns `undefined`, so there's a decent chance it's upgradeable, actually. 

However, I'm not certain that it would be useful vs just listening for "resize" on their own window. Fulfilling the promise when the event isn't canceled doesn't tell the iframe that it's been resized, it just indicates that its "from-element intrinsic size" has been updated; whether or not this actually results in a size change for the iframe depends on the containing page's layout. Similarly, rejecting it when the event is preventDefault()'d doesn't tell the iframe that it won't be resized, just that its "from-element intrinsic size" isn't going to be updated. I just can't think of anything that an iframe'd page can meaningfully do in response to this, regardless of whether it's fulfilled or rejected.

On the other hand, the "resize" event on `window` gives you actionable information at all times, regardless of how the resizing took place.

> Most cases I can think of will only want the height to change (the parent pages design tends to define the width). So maybe the CSS (min-|max-)?(width|height) might be relevant here?

Yeah, since this would only affect the "intrinsic size" of the iframe, which is a very weak size input into the layout algorithms, almost anything the author in the outer page does will override and let them have whatever level of control over sizing they wish.

> Also, do you consider the use of contain-intrinsic-size: from-element X Y to be required, considering allow=resize is granting permission to change the size? or is it just providing the default size?

Not *strictly* required, but without it, it's not clear what the intrinsic size should be before the first `resizeTo()` call. We could assume 300x150 (the current default), I suppose, but that's probably rarely a useful starting size anyway?

I think requiring it also plays slightly better into the generalized feature, where I want to allow `textarea` to resize based on its content; making the feature consistently activate with a particular property invocation might make it easier to learn and remember, rather than some elements having special ways of triggering the same behavior.

I could probably be convinced otherwise, tho.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-806180416 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 24 March 2021 20:57:39 UTC