- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 07 Jan 2026 18:03:53 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-sizing] Auto-resize iframes based on content`. <details><summary>The full IRC log of that discussion</summary> <JoshT> koji: as you can see from Chris's comment, there is a draft based on resolutions four years ago<br> <JoshT> ... are there any concerns?<br> <JoshT> ... and in discussion 4 years ago, mentioned that contain: size is required for ???? property<br> <astearns> s/????/contain-intrinsic-size/<br> <JoshT> ... requiring may not be needed for the throw element keyword<br> <JoshT> ... I want us to decide whether it's required or not<br> <oriol> q+<br> <astearns> ack oriol<br> <astearns> q+<br> <JoshT> ... another comment says introducing a new mutable value for meta isn't great, so we're learning towards immutable<br> <JoshT> oriol: for size container, it seems to do opposite of size containment<br> <JoshT> ... normally it ignores natural size and looks at size you provide<br> <JoshT> ... but this makes it depend on content<br> <JoshT> ... so if anything we should not allow contain: size for this to work<br> <JoshT> koji: it's not really opposite. we don't get the natural size, but introducing/calculating the size<br> <JoshT> ... for iframe, natural size is 300x150<br> <JoshT> ... this property makes that intrinsic size from the content<br> <emilio> q+<br> <JoshT> oriol: I was saying if you have an image, natural height depends on resource. but if you add size containment, you break dependency<br> <JoshT> ... for iframes, it's the opposite.<br> <JoshT> ... by default, we don't check the content of iframe<br> <JoshT> ... now this keyword takes the content into account. but if you do that, that's a contradiction<br> <JoshT> ... so I think this is only happen when we do not have size containment<br> <florian> +1 to oriol, if I understand corectly<br> <emilio> q- oriol explained it pretty great<br> <kizu> +1<br> <JoshT> astearns: I agree with oriol<br> <emilio> q-<br> <emilio> q+<br> <JoshT> ... I think for both, whether we require contain: size and whether it should be mutable, I think no unless we have to<br> <JoshT> koji: that is great to me<br> <JoshT> astearns: we could take a resolution if people are comfortable. or should we take back to issue<br> <astearns> ack astearns<br> <astearns> ack emilio<br> <JoshT> emilio: I agree contain: size is not what we want. but how do we prevent things like cycles?<br> <JoshT> ... let's say page has element with 101vh. we do need something to prevent it from repeatedly growing<br> <JoshT> ... for sizing, we need to break the cycle when the iframe reacts to the content size<br> <JoshT> ... when something is bigger than its size<br> <JoshT> koji: we only update the natural size after certain events and not every time size changes to prevent cycle<br> <JoshT> emilio: that is interesting. what triggers it I don't care, but what prevents it from growing and growing<br> <JoshT> koji: the draft says only update at content load and load events<br> <JoshT> ... and authors can use script to request resize<br> <JoshT> emilio: so you need to--<br> <JoshT> astearns: we are out of time. take back to issue. emilio please open separate issue on cycle issues if concerned<br> <JoshT> ... maybe we can do async resolution to give people time to read<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-3720090820 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 7 January 2026 18:03:54 UTC